Re: [lime] LibreMesh meeting log 2024-06-01

このメッセージを削除

このメッセージに返信
著者: cri
日付:  
To: libremesh
題目: Re: [lime] LibreMesh meeting log 2024-06-01
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

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
>>