Open Collective
Open Collective
P2P Access-Point #1: Intro & Proof-of-Concept
Published on August 26, 2021 by Luandro Vieira


Peers from Coolab and Alter Mundi come from the lived experience of rural wireless community networks, where communities build their own telecommunication infrastructure in order to widen their connections and access to information.

We want to nurture digital spaces where we can feel safe and find ourselves with the choice of whom we connect and whom keeps our data, wether it happens within our local networks or within the internet.

To contribute to this, we want to improve one key element on the network: the home access point.

The home access point is essential in any network as it gives good quality access to the network to those that live under the same roof. It is pretty common that these devices sit in our houses doing pretty much nothing… but they could do so much more.

This device could support community members in using the network to build local connections with their peers, leveraging their new network paths, to make them more resilient and strengthen their communal bonds.

This could be accomplished by designing a web portal, that could provide user-experiences aiming to build solideraty and community, such as providing locally curated and created content (Rádio PSP) or displaying information that’s relevant to the community (Moinho market and newspaper).

And also by running local services, that could go from standard self-hosted services, federated services that could discover each other within the network, or even Peer-to-Peer applications, that better distributed load amongst clients and work even if offline.

Web portal

During the month of July Luandro and Hiure worked on a web portal based on a sketch by Karla Velasco, which was based on her experience with networks in Mexico.

We decided to use NuxtJS framework because of it's great developer-experience, and of server-side-rendering, which is important in order to give a good user-experience for lower-end devices, which are common in rural areas.
The code was written mostly by Hiure and can be found on 
Gitlab; a hosted version is at Users can edit content via an installed code server, incentivizing people in the communities to mess with the code in order to desmistify software a bit.

Ideally each user-device could act as a ssb-node using ssb-browser-core. But since we're aiming at low-end phones we decided to build a progressive experience, where the user can choose between being a node or just connecting to a trusted server. For this we've been experimenting with adding ssb-browser to our NuxtJS app as well as building an api based on ssb-db2 and publishAs.

P2P Access-point
The hotspot/server device will be a single-board-computer yet to be chosen, based on needs defined in meetings held with a selected group of technologists from our networks.

For a proof-of-concept we decided to use the Raspberry Pi 4 (8Gb), because it would easily be able to run the multiple services required for the Tukano Project. Such a powerful device was an overkill, and the only problem was the interference between USB 3 and Wifi and overheating (amazon heat).

The stack of services we ran are in constant update on Gitlab, but we haven't focused on P2P yet, since this wasn't a priority for these specific communities and we had little time to prepare. But that's where we'll shifting our attention next.

The first experiment happened on three remote indigenous villages in the Amazon and was a big success. The communities were able to appropriate the portal and edit it based on their cultural identities as well as use the apps/services which were provided. We were able to get valuable early feedback which will reflect on next iterations.

Next Steps

We'll be working on the SSB stack both on the server as well as in the web portal. The objective is to have a portal where users can use to chat, browse local content or whatever the community is interested in, using the SSB protocol as a database.

We also want to make an auto-discovery system in networks using Libremesh, so that services that are in the network are published in the “apps” page of the portal automagically.

Finally we'll be holding meetings with our network of technologists to define the hardware and software needs for the access point device. We'll then purchase and experiment with different options until we find the best match.

You can find more info at the project presentation thread and we hope to organize a dev-diary soon.