On 05/06/24 14:56, cri via LibreMesh wrote: > On 04/06/24 18:39, Hiure via LibreMesh wrote:
>> Hi Ilario, Thanks for sharing.
>>
>> Tomorrow at 13UTC we're going to have another meeting to discuss some
>> things that were raised in this log, talk about Battlemesh and try to
>> get some direction on the gsoc projects.
>>
>> see you.
>
> here:
>
> https://jitsi.unp.edu.ar/LibreMesh
we are in the fallback room:
fallback https://meet.guifi.net/LibreMesh >
> hugs
>
> Cristina
>>
>>
>> Hiure
>>
>> On 01/06/2024 12:35, Ilario via LibreMesh wrote:
>>> Hi all!
>>> Here you are the meeting minute of today's reunion :)
>>>
>>> # Saturday the 1st of June 2024 at 13:00 UTC (15:00 CEST, 10:00 ART).
>>>
>>> ## People
>>> Cri, Nemael, Henrique, Ilario, Gothos, Andrea
>>>
>>> ## Topics
>>>
>>> * Introductions
>>> * Updated PicoPeer agreement
>>> * GSoC New Pirania release
>>> * GSoC Cable purpose autodetection
>>> * Reports from BattleMesh
>>> * Updates on the testing grant?
>>> * When to make the release
>>> * Next meetings
>>> * Extra news
>>>
>>> ### Introductions
>>>
>>> ### Updated PicoPeer agreement
>>>
>>> Cri: Most of the mesh networks in the world are using a Picopeer
>>> agreement.
>>> Started from a community in London (London Mesh Network) and from
>>> another in Catalonia (Guifinet)
>>> 4 points to a Picopeer agreement:
>>> - Build a network between peers
>>> - Give/keep net neutrality
>>> - Give free transit on the network
>>> - Every mesh network can have local agreements
>>>
>>> Cri: Freifunk asked to discuss about adding:
>>> - copyleft to contents shared freely in the network, so that
>>> members will agree to have copyleft content passing over their nodes.
>>> - No need to share a personal contact, someone can be have
>>> community being the contact
>>>
>>> https://antennine.noblogs.org/post/2024/06/01/report-nuova-release-del-pico-peer-agreement/ >>>
>>> ### GSoC New Pirania release
>>>
>>> https://blog.freifunk.net/2024/05/31/gsoc-2024-new-release-for-project-libremesh-pirania/ >>>
>>> HMohr: Cri and Gothos, are you using any captive portal?
>>> Gothos: Not yet
>>> HMohr: I will speak to Luandro
>>>
>>> Vouchers are needed for the economic sustainability of the network. In
>>> Brasil it is legal to share the connectivity but you cannot make
>>> profit (income has to be equal or less than the ISP fees).
>>> Start: virtualizing with qemu, then with physical routers
>>>
>>> Main problem: OpenWrt 19 (and the current Pirania code works on
>>> OpenWrt 19) uses iptables, OpenWrt 23 uses nftables
>>>
>>> https://github.com/freifunk/projects/blob/f602dd6da862040854e78d6f9585bfa81da01738/_projects/libremeshpiranianewrelease.md >>>
>>> Splash page without need of vouchers is not implemented (???), even if
>>> it is mentioned in some parts of the documentation.
>>> Splash page is like a captive portal also for communities that does
>>> not use vouchers. Just for welcoming users and informing them about
>>> the network they are using.
>>>
>>> Cri: Beware! AP (e.g. ESSID LibreMesh.org) is showing the portal, but
>>> APNAME (e.g. ESSID LibreMesh.org/12345678) is not. Maybe this is ok?
>>> Communities can put a password to the APNAME or disable it.
>>>
>>> Cri: Problem with lime-app & Pirania: you can activate the voucher and
>>> deactivate the captive portal, that makes no sense.
>>>
>>> we have a meeting next wednesday 5 june to do deeper in the topic
>>>
>>> next tasks
>>>
>>> 1) undestand what Pirania do and what not do
>>> 2) build workflow to have the package builded
>>> 3)
>>>
>>> ### GSoC Cable purpose autodetection
>>>
>>> Nemael:
>>> how to apply configuration/s that works out of the box.. or have a
>>> button to push?
>>>
>>> 4 main situations to detect:
>>>
>>> https://blog.freifunk.net/2024/05/31/gsoc-2024-libremesh-cable-purpose-autodetection/ >>>
>>> If we want to have the realtime detection and instantaneous
>>> configuration, we should warn the user that the change happened. Or
>>> one time configuration (first boot wizard)? but maybe this is
>>> out-of-scope of the project.
>>>
>>> Ilario: It seems very risky to have the runtime autodetection, if
>>> things go wrong, the debugging will be very complicated.
>>>
>>> Nemael: Let's start from the autoconfiguration triggered by the user,
>>> then we can see how difficult it is to have the runtime
>>> autoconfiguration (do we want it?).
>>>
>>> FOR NEXT YEAR'S GSOC: we could buy routers spending LibreMesh
>>> donations money on OpenCollective. Right now, most of the money we
>>> have are destinated for the testing grant.
>>> https://opencollective.com/libremesh >>> but we can keep next money from mentors from GSoC24 for buy hardware
>>> in the future.
>>>
>>> Cri: From Italy, here some description of the hardware that we are
>>> using: https://antennine.noblogs.org/?s=antenne >>>
>>> ### Reports from BattleMesh
>>>
>>> Nobody in this meeting has been to BattleMesh
>>> -> Reported to next meeting
>>>
>>> ### Updates on the testing grant?
>>>
>>> Pony reported and also received the payment
>>>
>>> Hiure is still working on the details
>>>
>>> both improved a lot the next release quality
>>>
>>> ### When to make the release
>>>
>>> Until now, the release candidates has only two commits of difference
>>> from the head of the release branch.
>>> A new release candidate now is not very different to the current
>>> release.
>>> Should a release candidate be before or after release candidate?
>>> -> If before gsoc, maybe it could ease the work of GSoC?
>>> -> If after gsoc, there would be more time to squash the bugs and the
>>> possibility to add the code written during the GSoC itself
>>>
>>> The second option has been preferred.
>>>
>>> ### Next meetings
>>>
>>> https://libremesh.org/communication.html >>>
>>> Wednesday the 5th of June 13:00 UTC (15:00 CEST, 10:00 ART)
>>> -> probably there will be Hiure (coolab) and Gio (altermundi)
>>>
>>> Monday the 24th of June 13:00 UTC (15:00 CEST, 10:00 ART)
>>>
>>> ### Extra news
>>>
>>> Ilario: Tomorrow in Barcelona there will be an experimental deploy:
>>> libremesh devices connected with other OpenWrt devices. to make a Mesh
>>> with Libremesh used to connect the Openwrt devices that need to be
>>> flashed/configured for experimenting.
>>> LibreMesh routers will be used for managing the experimental network
>>> constituted by OpenWrt routers.
>>> This is useful for testing experimental mesh networks also for
>>> BattleMesh event. This has been
>>> organized by Pedro from eXO (https://exo.cat/, an
>>> association born from Guifinet) and Bruno from Coolab.
>>>
>>> https://comunitat.canodrom.barcelona/assemblies/comunitat/f/1651/meetings/2812?locale=en >>>
