GNUnet Messenger API: November 2023

Hi there,

I’m actively working on the GNUnet Messenger service again and I wanted to share some of my progress over the last month. Actually it has been a bit longer than a month since I started implementing this part but because I was kind of busy with other projects at the same time, I couldn’t complete much. Therefore I didn’t had a lot to talk about before today.

So what change was I working on? It’s about this issue here. The idea is that you could run GNUnet on a device which might not offer a lot of processing capabilities or it might be limited regarding power draw (for example a mobile device running from battery). So in that case you don’t want to handle routing for chat rooms in the Messenger service if not necessary. But that’s the problem. Sometimes it is necessary.

For example when you are in a private chat with only one contact and they only have such a restricted device running their peer as well. So some of you has to enable routing functionality or in other words “open the room” regarding the API allowing the other peer to establish a connection via its peer identity.

However this has caused an issue in the current version of the protocol because sending a peer message and enabling routing functionality for others was a one-way option with the only way to revert it leaving the chat room. That’s not ideal when devices could have very dynamic contexts. For example you could charge your device, connect via cable to network or wirelessly. Connections might not be reliable all the time and your device might be able to manage routing messages sometimes even though it could be too much most of the time.

So the solution as mentioned in the issue was to allow different kinds of signatures for messages depending on the kind of message. This changes the protocol drastically in terms of complexity but it provides a lot of advantages. First of all the service can now send some messages without any client forwarding their private key for signatures. In current state a service needed to run on user level to get access to a user’s identity keys for signing messages. That’s not the case anymore. Private keys stay on the client side with user level. So the service could now run as gnunet user system wide, being shared between different users without the potential of private keys getting compromised.

The second advantage is that the service now controls sending PEER and MISS messages. This allows the service to manage enabling and disabling routing functionality on its own. Rules for this aren’t implemented yet but there will be an option for configuration soon. The service will also handle MERGE messages automatically. Additionally INFO messages get signed via peer identity. Overall the peers are now able to communicate the underlying routing structure without one member to sign the required messages for the service and members are much more independant of the actual service.

Another bit of progress happened independant from my own doing. GNUnet moved from using GNU Automake as build system towards using Meson which is a good thing in my opinion. Builds are pretty fast now and the directories in the repository have been reorganized. Also the transport layer has seen a huge update with a new implementation (TNG). I assume all of these changes should apply for the next release.

Also I should note that I’ve already implemented the necessary changes to make libgnunetchat compatible with upstream GNUnet. Maybe someone has noticed the latest release of libgnunetchat (0.1.3) has not been compatible with the latest release of GNUnet (+0.20.0). Depending on the amount of time until the next release of GNUnet, I might address this with some release of the chat library in between. There’s already a patch upstream. I think the most issue was that I didn’t check the issue before updating GNUnet in the flatpak manifest. Sorry about that! At least I noticed because of this the flatpak was actually using the debug build, enabling my asserts. So I might address that as well.

I’ve planned implementing a ton of new features in the upcoming months. So keep an eye out for more blog posts like this. I’ve started to read into the MLS protocol considering it for solving some issue in the Messenger service. But I’m not sure yet whether that can be implemented efficiently without centralized infrastructure.

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

Image
Hey, this is the last post under the topic “GNUnet Messenger API”. As mentioned last time I only had a few remaining things to implement in the messenger-cli application. So that is pretty much what I did with some small caveats. The only thing not working as planned is file sharing. Let me explain this: You can already write a file path to your text input and it will send the file. When a file gets received, you can select the message, hit ENTER and download the file. However depending on your GNUnet setup uploading a file might not work. This seems to depend on user access permissions of your selected files. The best work-around I know is to use a single-user installation for GNUnet. But I hope that this can be solved properly, so users don’t have to mess with configurations. More information about this issue can be found here . The second missing part is that you can technically download the file and progress of that will be visualized. However there’s still no opt
Read more

GNUnet Messenger API: December

Image
Hello again, Here is a little update to the GNUnet Messenger API from December. This time I’ve added a short video to show how it works at the moment on a local machine with multiple clients. I’ve now added most dialogs to invite contacts to groups, open custom private groups, open chats directly to your contacts and open public platforms (public chat rooms). Filtering the contacts in those dialogs using a search field will be implemented soon (this is visual only for now). Sending files should work in theory already but I haven’t hooked up visually representing those file messages. But it will likely be very similar to the implementation of it used in cadet-gtk . Chats will now allow renaming for contacts and update each widget using it. Also it is now possible to have persistent chats between closing and opening the application which will be necessary for ease of use. Many bugs got sorted out in libgnunetchat but there’s still a lack of thread safety which needs to be addres
Read more