GNUnet Messenger API: February 2026

Hello again,

this month has been a bit different. Originally I thought to be done with my previous changes, ready for release but there were still some issues open in other services marked for the next release of GNUnet. So I waited at first for others to solve them until I asked myself whether I should take use of that time to integrate the newer PILS service functionality into the MESSENGER service.

Then I started testing the current state of connectivity using TRANSPORT and CORE with the new PILS service and I noticed a few problems. So naturally I reported it, adding another issue to the list of things being solved before the next release. Sigh. Eventually I became too impatient deciding to at least go for fixing the new issue, I reported. Because it was stopping me from properly testing the MESSENGER service.

That is how I ended up changing some parts around many different services to utilize the PILS service more consistently. The service supplies other services, clients or communicators with the current peer identity while it may change depending on addresses regarding possible connections. However some services wouldn’t use the same peer identity, partially caused by still using older code with a static peer identity key.

After my rudimentary changes were mostly complete I was able to test around more using two different peers, one being a VM. But I noticed the needs for some tool to properly verify the REGEX service was working. Because in the messenger application the public chat rooms are actually using this service to notify other peers being active members of a certain room. In theory you simply enter a public chat room, it automatically searches for other matching peers using that room and connects with them. So for ease of use I needed the REGEX service to work.

Therefore I implemented a new simple tool to announce a regular expression as well as search for peers having a regular expression that matches a given search term. So I could test the service a bit further and make it work reliable enough between my two peers.

Now everything was in line to test the MESSENGER service and make it work. Surprisingly in some cases it already kind of did. But some service in the whole stack was failing at some point because of assertions being violated or actual errors. So more debugging followed and more changes.

Finally I wanted to complete all this work by making the MESSENGER service utilize the PILS service properly which needed quite some adjustments. Because using the PILS service you can’t access the private key of the peer identity anymore but only request it being used for signatures. However that is an asynchronous callback which implied I had to change multiple functions internally from a synchronous to an asynchronous design. But that is done now and it seems to work as expected, I’d say.

There are still issues and I think I’m not happy yet with all of my changes in other services. So maybe I need to make some more adjustments next month. Also I haven’t requested it being merged yet and don’t get me wrong. I’m not saying next release will finally be the moment, the messenger application becomes ready for practical usage. But during my testing period this month, I have become more optimistic that this day might come earlier as expected.

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: 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 TR...
Read more

GNUnet Messenger API: October 2025

Image
Hi there, this month I started to port the messenger application from GTK3 and libhandy to GTK4 and libadwaita . So far the progress looks pretty good. I still need to adjust some widgets to avoid usage of some deprecated ones. There is some logic missing to upload files because file dialogs and widgets from GTK3 using those haven’t been ported exactly. So things need to change. Screenshot of the main window ported to GTK4 If you are interested in testing the changes so far, I have pushed all commits to a separate branch so far. While porting I have also noticed some bugs in the application and libgnunetchat API which might cause crashes or freezes. I will try to solve them before any release but I’m very confident that the next release will contain all the changes towards GTK4. Hopefully this will help long-term with reducing CPU load in case of image file previews and video streams. Also I’d like to add in-place video previews for shared files instead of relying on the vide...
Read more