GNUnet Messenger API: June 2024

Hey,

this month I’ve started working on the implementation of a voice chat feature. So far my local tests are looking good, transferring raw audio data from one client to another, essentially streaming it. Latency of all the cryptographic overhead does not seem to be an issue. It’s still possible there are optimizations needed but for a first implementation it’s looking good.

I’m still waiting for further practical multi-device tests on either NAT traversal or improved peer perception in local networks using GNUnet. Also there’s still ongoing work on the testing system to create local multi-device test cases using network namespaces. Until one of those options is solid, it’s difficult to verify whether latency or bandwidth need further improvements.

So I’ve continued implementing the required API in libgnunetchat and I’am already working on the graphical interface for it in the GTK client. Because those parts don’t need to wait for the back-end anyway and it makes practical tests easier. For most simplistic tests I’ve added a functionality to the gnunet-messenger CLI tool which comes with GNUnet. So it can be run in streaming mode piping all input straight through the Messenger service using the new discourses.

That’s probably the point I should explain what discourses are inside the GNUnet Messenger. A discourse is a live channel for data exchange inside a chat room. Users of that chat room can subscribe to or unsubscribe from such discourses to receive or send data to other subscribed members. Essentially it’s a multicast functionality inside of the end-to-end encrypted chat rooms.

For that it uses two different kinds of messages at the moment. Clients can send a SUBSCRIBE message inside a chat to adjust their own subscription or send a TALK message to exchange binary data. Both new messages differ in one regard from all other messages so far in the regard that they won’t get stored. So it’s not possible to request and receive them at a later point in time from other peers (except they run a different implementation of the service). Clients which haven’t subscribed to a given discourse won’t receive any TALK messages from their service linked to that discourse. Potentially this could even be optimized further that even their peers don’t receive this data saving bandwidth. But something like this isn’t implemented yet.

Subscriptions to discourses expire automatically after a custom delay set by the client. If they want to quit their subscription earlier it’s possible to send a SUBSCRIBE message with immediate action to unsubscribe via custom flag. Sending any data via TALK messages is optional for any subscribed member of a discourse.

A chat room can have multiple discourses in parallel. They identify via a custom 256bit hash. The idea behind this is utilizing such a hash as equivalent to ports in IP traffic to make it easier for applications to handle data from such discourses. For example one discourse could be used to exchange live audio for a voice chat while a second discourse is used to exchange live video for a video chat. So users could select via subscriptions what they want to receive or send more precisely.

How does that look in practice? The idea is to have a graphical interface that acts very similar as other popular applications with a voice chat feature. You have buttons to enable or disable microphone, speakers, camera or screen sharing while being in a voice call with others. Ending the call will drop all required subscriptions. The buttons will only control selective features.

It’s planned to have a voice call open while being still able to send and receive text messages via chat. But it’s difficult getting all of this in a handy window size. I believe it’s doable but at the moment I don’t want to share my current design ideas yet because it might still change quite a bit. It’s definitely the goal to have a functional interface for Linux devices of all form factors. But more about that next time.

Small addition: There’s been a new release of the GNUnet Messenger application (version 0.10.0). It’s already available as flatpak on Flathub while the snap package on snapcraft is still at 0.8.0 because building requires core24 as base which isn’t compatible with the gnome extension for snaps yet. Another big issue is the compatibility of pipewire with snaps. As soon as that works I will release an update. But if you are on Linux distributions which favor snaps and you want to try the latest versions, you either need to wait, build the application from source or try setting up flatpak for now.

Also smaller addition: I could actually try to run the snap package on a Pinephone running Ubuntu Touch. It runs the application but it’s not really usable because of wrong UI scaling. I will look into solving this as soon as the core issues with the snap package are resolved.

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