GNUnet Messenger API: January 2024

Hello there,

hopefully you have arrived happily in the new year. There’s already some progress I want to share with you.

First of all there’s new functionality in the GNUnet messenger service. The service allows sending tickets now which originally come from the RECLAIM service in GNUnet. Those tickets allow sharing selected attributes from your identity with another contact in a secure and private way:

  • Only your selected contact can use the ticket because it requires their own identity key.
  • Your contacts can rely on the attributes coming from you because it depends cryptographically on your identity key.
  • You can adjust the values of those attributes and your contact will be able to receive its updated state.
  • You can revoke an issued ticket at any time, making your contact loose the ability to read current values from the shared attributes.

So what is all of this for? Couldn’t we already share information privately with a selected contact via PRIVATE messages in the messenger service? Yes - but we could not easily withdraw access to information. Sure, theoretically it was possible to delete a message afterwards but on application level this would require tracking PRIVATE messages and their content to know what to delete which isn’t implemented yet.

My first idea was to use those tickets for invitations which currently work through PRIVATE messages containing an encrypted INVITE message. However that still requires an added RECLAIM attribute type for such invitations. Also this would mean the service ends up having two implementations of the same feature which I personally dislike.

There’s also still an issue with missing functionality in the RECLAIM service to list attributes from own issued tickets. But that would be necessary to properly manage invitations and other tickets in general on application level. So I have rethought my idea and figured it would be much better first implementing deletion and representing PRIVATE messages.

Because it should be quite easy to delete an invitation on a revoke function call when the regarding message would be known to the client as INVITE message rather than unknown PRIVATE message. Also it would help if every client using the same account/identity has access to this information. All that leads to a new concept which is similar to functionality from other messengers: The content of a PRIVATE message will be always sent encrypted with your own key as well. But it will be a separate message with information about the receiver as well as the original PRIVATE message. So deletions can pick up both easily.

Additionally to this idea I have thought about implementation details regarding other features like threads, replies/comments and ratings (or even polls). I think it should be possible to implement such things with only two new kinds of messages but I need to look at the edge cases more.

Now unfortunately I have thought a lot about implementations in the service but not much is implemented yet, right? What about those tickets we have now. I will very likely use them for another feature, I was looking forward to: Profile pictures. Because profile pictures should only be shared with selected contacts of a users choice. They don’t need to be stored locally that way and a user could select to ignore it even though they might have permission to access it.

So that will be on of the next things, I’m going to implement since it shouldn’t require many changes in the service anymore.

I have to say though that I still made some progress on the graphical client (meaning messenger-gtk here). I’ve fixed multiple visual issues, adjusted some UI elements like the emoji picker and started to implement the functionality to block contacts. You can now block and unblock contacts temporarily which will cause messages to be dropped/ignored by the client. It still needs some work to be permanent. But on the client itself there’s little to be added for this feature now.

That was all for this monthly overview.

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