This week I still have some new things to explain about PlanEat.

Bad News - Android sucks

So, I guess it’ll probably be the end of PlanEat. And probably a time to try other OSes again on my phone. (I have a PinePhone for a few years, but there is a lot to explore). Google is trying to kill Android once again. So, I encourage you to read https://keepandroidopen.org/ For me, I still don’t know what I’ll do with PlanEat. Probably kill it. That was fun, but I have other ideas. Anyway, this week I wanted to share about how I classify recipes in PlanEat. Here is a screenshot of the app:

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.