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
