Wow, it’s been 4 years since my last article. A lot of things have happened: the pandemic, the AI-bubble-sloppy-shit. But recently I thought about re-opening this blog. I’ve been using Obsidian for a long time now, and I have a lot of notes, ideas for articles, and projects I want to work on. And a friend recently started to write weekly articles on his blog, so now I know it’s my turn to make this part of the Internet live again.

I’m a Core Developer for https://jami.net since several years now. During those years, I gave some talks and wrote a lot of articles that I’ll link of that page:

Articles

• “Improving the call experience in Jami” - 2022, Aug 31 - https://jami.net/improving-call-experience-in-jami/
• “Swarm file transfers” - 2022, Aug 09 - https://jami.net/swarm-file-transfers/
• “Synchronizing conversation history with Swarm” - 2022, Feb 16 - https://jami.net/synchronizing-conversation-history-with-swarm/
• “Swarm: a new generation of group conversations” - 2021, Jan 15 - https://jami.net/swarm-introducing-a-new-generation-of-group-conversations/
• “Improving performance and security with TLS 1.3” - 2019, Sep 6 - https://jami.net/improving-performance-and-security-with-tls-1-3/
• “Peer-to-peer file sharing support in Jami” - 2019, Jun 14 - https://jami.net/peer-to-peer-file-sharing-support-in-jami/
• “Establishing peer-to-peer connections with Jami” - 2017, Jun 9 - https://jami.net/establishing-peer-to-peer-connections-with-jami/

And probably helped to lot of other things (like https://docs.jami.net/)

Long time no see! I have a looooooot of projects in mind and a lot far too big (+40h of work & personal community stuff & life). However, I got a list of projects I can do in one week-end(ish) (e.g. a Gartic Phone with DALL-E, play with open push, etc) and because I answer to a lot of tickets every-day, I was wondering how this can be automatized nowadays with all the new AI projects (for the fun, to be honest, I think a good FAQ should answer to all common questions and a good documentation should complete this. So, you just have to fix bugs and redirect to the FAQ/doc).

It’s been a long time since my previous post, but let’s continue this serie about distributed systems with a tool that a lot of people use every day: git.

Git is a versioning tool. Unlike some systems like subversion, you don’t need to have a server to use git. Every member of the project own a (partial or not) copy of the project and can directly send data to another member. So, even if today a lot of people use platforms like Gitea, GitLab, GitHub, etc. it’s possible to work without any of them (can be useful when the platform is down).

This blog is also available via the Tor Browser. And have a .onion address.onion

You can support the Tor project there: https://support.torproject.org/

Or run your own hidden service via https://2019.www.torproject.org/docs/tor-onion-service.html.en

In the previous articles we talked about how to create a peer to peer connection and what issues we can encounter. These problems are generally due to the NAT which needs methods to pass through it (e.g. TURN servers) or some new protocols (like ICE).

It is now time to talk about distributed applications and structures created on top of a p2p network.

For a lot of distributed applications, all the nodes in the system can’t be stable. In fact, nodes continuously join and leave the network for a lot of reasons. So, we need to use a structure which connects all the nodes of the network to maximize the coverage of that network (we don’t want to have nodes in a sub-net) and to get the best response time.

In the first article of this series, we saw how to make an application (DEL) which is able to transfer a file from one peer to one another by successfully bypassing the NAT thanks to a TURN server. However, this technique is not really effective, because, in a lot of cases, a TURN server is completely useless. Indeed, if both peers are on the same network or both peers has an IPv6 address, the TURN server is not mandatory. Now, Alice wants to improve DEL to only use the TURN server as a fallback.

Some time ago, I had to run a script to test an application by sending dbus calls. The script was working great, until I moved it on a server with no graphical session. I ran the script as a System V init script, but you can encounter the same problem in a terminal or in a cron. The thing is that a dbus session is generally managed by KDE, Gnome or your graphical session.

I love distributed systems for a various of reasons. But these systems are complex and require interactions with many layers. Even if a lot of distributed systems and software exists, such systems can be difficult to use for several reasons. Today, our operating systems tend to avoid doing as many calculations as possible (i.e. mobile devices need to save battery and avoid data consumption). Also, IPv4 is still massively used so NATs are still needed, interfaces are mainly created to interact with servers, etc. This is why I want to explain some common problems we can encounter when creating a peer to peer system and to describe existing solutions.

For the local future CHATONS (Chatons is a french word which means kitten), I am currently helping to host a new Jitsi-meet instance. This instance will be available at this address: https://conference.facil.services/ and this is a little post about how we did it and what problems we encountered.

First step - The manual installation

For the story, the first attempt for hosting the instance worked during several weeks. But, after a migration to our final server, we started to see a lot of problems with that instance (due to the migration or the installation of the back-up system or the monitoring tools). Anyway, even the logs were odds.