GNUnet Messenger API: July 2025

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. Also you will now see whether you get invited to a group chat or a private chat by smaller visual differences between those invitations.

There’s still a need for tuning small bits and pieces like warning a user to not send messages into private chats without receipients. Since I have changed this to be allowed from GUI but those messages will be encrypted to them if sent before the other person joining the chat.

But besides the still open issues and some fixed issues, there have been performance improvements regarding message requests and updating already received message content on application level. So the next releases should perform quite a bit better in some situations.

screenshot of messenger-cli showing a chat in color

I’ve also added colors to the terminal interface messenger-cli which makes it easier to differentiate between other users in chat rooms. Also every dialog got hints about their expected user input and I’ve created as well as published a snap package for the application. This might come in handy to some people who prefer using a more minimal interface for simple text messaging.

All of the efforts improving the Messenger service and libgnunetchat will translate to the progress of GNUnet on Android and its port of the Messenger application. So it looks like the current state is likely to get merged upstream soon for one of the next GNUnet releases if there’s not major bug anymore that needs to be addressed upfront.

If you want to test the current state already, it’s a bit cumbersome. You need to build GNUnet from source code using my development branch, build libgnunetchat from source code from its development branch on top and the application using latest changes from upstream repository source code on top of that (either messenger-cli or messenger-gtk).

Kind regards,
Jacki

Read original article

Popular posts from this blog

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

Image
Hi there, At the beginning of the month I didn’t think to make that much progress. But now I get the feeling that the GUI client could come to an end next month. Why do I have this feeling? It’s looking really good already, not gonna lie. So as stated in my last update in January, loading older messages needs to be implemented as well as switching accounts during runtime. Now it is. Getting older messages still needs some tweaking to not load all older messages but it’s good enough for now. image of messenger-gtk account selection Switching accounts was more difficult to implement because I had to go back looking into the Messenger service of GNUnet itself, fixing that the service will run as user to make use of the same EGOs as the client side library in multi-user setups. The client side library ( libgnunetchat ) now exposes each of your EGOs as account with name and own directory to store the files and configurations used by the applications. Another benefit of this is tha...
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