GNUnet Messenger API: September 2025

Hey,

a few days ago GNUnet 0.25.0 got released with the latest changes to the CORE layer and containing the new PILS service reducing the risk of being tracked while using GNUnet over a wider area. The MESSENGER service might still have some issues working properly with these changes but I will let you know here when I implemented necessary changes to utilize the new PILS service.

This will be necessary because the MESSENGER service actually requires to track peers collaborating in message exchange to some degree. It won’t be necessary to link peer identities to individual chat room members. At the same time switching networks on abstract level like walking around with your mobile device or switching from physical connection to WiFi shouldn’t cause issues, message loss or heavy disconnections. So it will be fun to tackle this!

However I’m very optimistic GNUnet is going in the right direction with all this work on its fundamental layers. There are still issues underlying in the TRANSPORT layer, it seems. But with the newer testing system that should be solvable.

There has been some deprecation with gnunet-gtk which has become a burden of maintenance. Maybe I can find some time to update this since I’m already working a lot with GTK+ including libhandy. But I’m also busy with some other projects currently.

Anyway the messenger-cli and messenger-gtk applications have been updated to stay compatible with latest changes in the MESSENGER service from GNUnet 0.25.0. These include the ability to open private chats with only one member that allow writing notes to yourself as a user. Also this release finally brings my previous work on the forward secrecy (not yet perfect forward secrecy though - see previous posts for details).

So this will bring the MESSENGER service much closer in being comparable to other messaging services in terms of feature set. You can easily test the applications yourself on any Linux distribution via convenient snap or flatpak packages. These are already updated as well to the latest releases.

Kind regards,
Jacki

Read original article

Popular posts from this blog

GNUnet Messenger API: July 2025

Image
Hi there, unfortunately I didn’t make it to write a blog post last month. I was quite busy closing open ends of other projects while there were quite some bugs and issues to be solved in the Messenger service of GNUnet . On the bright side this means I have a lot to talk about this month. Most critical issues could be solved already, test cases of libgnunetchat pass again with all latest changes and the end-to-end encrypted chats seem to work as intended. I am still encountering some issues that messages do not get received immediately from chats or the chats can behave somewhat inconsistent. However it’s likely some condition caused by parallel events or a very specific order of events that’s difficult to reproduce. But these issues only seem to appear on reopening old chats from a previous session. The current sessions simply seem to work properly. Invitations do now respond to input feedback all the time and chat types get visualized depending on actual bits in a chat room’s key....
Read more

GNUnet Messenger API: March

Image
Hi again, Last time I had big hopes to make enough progress for a first release. But I think I’m gonna delay that a bit (maybe still this month but we will see) even though I could actually complete the things, I anticipated. However here is finally the long promised video of it running on the Pinephone Pro because there’s still much to show. The back-end of the messenger-gtk application called libgnunetchat now uses the GNUnet Name Store service to manage your chats instead of using a local directory and some configuration files for each chat as before. This means that it is now possible to start the application from any directory and it will properly sync the chats depending on the account/identity selected. Next big feature is that it is possible to generate so called lobbies. Lobbies are empty chat rooms which will be shared in form of a GNS record under a newly generated zone instead of your own identity zone. This has multiple reasons: Technically your own key could ...
Read more

GNUnet Messenger API: March 2025

Hello again, since last month I tried to optimize the mechanism of forward secrecy further and indeed I was able to reduce the amount of messages required for a whole key exchange in a new epoch. So rather than scaling N scare if N is the amount of epoch members, it seems to scale linear now. That is quite an improvement but there’s still room for more adjustments. For example I realized recently that the current implementation is not providing perfect forward secrecy yet. That means if your long-term private key (the identity key to sign messages) gets compromised, an attacker might still be able to access messages from older epochs by request its keys from others. So to mitigate this, it will require changes that restrict requests of older epoch keys much more. Additionally deriving epoch keys via KDF could be adjusted to make it much more difficult to brute-force any epoch key from messages with HMAC using keys from the KDF. Once that’s done, there’s still work to do for allow...
Read more