Jacki's Developer Blog

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

Hi again, to decrease complexity in the account system and key management I decided against separating identity keys from chat accounts and epoch keys for forward secrecy will instead be stored locally using GNS . The keys will be encrypted additionally using a key derived from the private identity key. So only the ownert of this key with storage access will be able to access those epoch and group keys to further access encrypted messages of certain epochs in the message graph. With those changes I could get rid of bigger API changes in the Messenger service . Key management is completely automatized now, once you provide a private key to the client API. So that makes further implementation a lot easier and it shouldn’t hurt confidentiality. As next step I want to improve the key exchange in regard to implement perfect forward secrecy. So that in case your long-term identity key gets into hands of an attacker, it’s still impossible to retrieve old epoch keys and access messages exch...

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

Hi again, My progress on the forward secrecy in the Messenger service of GNUnet is coming to a state where I have proper testing and results. You can find the current state of tests and benchmarks in a development branch of libgnunetchat which utilize a new ping tool for the Messenger service. The tool sends a TEXT message into a selected chat room and waits for other clients using the same tool but acting as receiver to send a TAG message back choosing the TEXT message as target. As a result the sender will measure and print out the delay between sending and receiving the response. Like that it’s possible to measure latency added via the implemented forward secrecy as well as its key exchange mechanism. The results so far are a mixed bag to be honest. Good news is that latency and general cost by symmetric encryption is negligible once the key for an epoch is exchanged. However bad news is that the amount of messages required for a proper key exchange as well as group formation...

Hello there, so I got some news for you again regarding my progress on the GNUnet Messenger service as well as the applications. Because there has been a GNUnet release last month which made libgnunetchat and the messenger applications using it incompatible, I needed to implement some changes, fixes and announced a new release . The forward secrecy I’m implementing in the Messenger service of GNUnet is still on development branch though. It will take some time until those changes are ready for release. But I got quite a bit of progress. The members of a chat actually start building groups, exchanging keys to form a tree structure as suggested in my last post from December . If any member of such a group is missing an epoch key, they will delay depending on their position inside their group the appeal for the missing key to then authorize the whole group after gaining access. This way ideally just one member will send an appeal, receive access, send an authorization and the rest of ...

Hey everyone, welcome to my yearly recap of the year 2024. What happened? What did I work on? Well, quite a lot actually. So let’s start with the biggest project and continue from there. The GNUnet Messenger got funding from NLnet again as I mentioned in the end of last year. The new goal was to improve usability and add new features. What features are we talking about exactly? My concept was to achieve feature parity with most popular messaging apps but sticking to a decentralized context. For example I wanted to add profile pictures. But we can’t simply upload image files to a profile picture server/provider and poll from there for any new contact we get. So the solution required a bit of hacking around in the back-end. I used reclaimID from GNUnet to allow users sharing personal information with selected contacts of their choice and profile pictures may be such personal information for example. That means we can upload encrypted image files to a decentralized file sharing ser...

Hello, last month I’ve started to mention that I began to implement forward secrecy into the Messenger service of GNUnet . The fallback for key exchange in an epoch of messages is already working. Senders of messages will generate a new key just in time and announce it. Other members of that chat epoch will appeal the new key if missing and potentially gain access if allowed. As a way to improve key exchange further I’ve utilized a key derivation function to generate new epoch keys from ones of the previous epoch if and only if all members of the previous epoch are members of the new epoch (for example in case a new member has joined the chat). Otherwise a full exchange of a new and independent key is required to avoid access leakage to previous members that already left the chat. The last remaining step to improve efficiency further requires the setup of groups (or subgroups) inside an epoch. Those groups will either be formed by two members of an epoch or two groups of the same...

Hey again, It has been a few months since I last posted here since I finished my major project of the video and audio chat in the GNUnet Messenger application . I took a short break and now I’m working on a completely different part in the service again. So not a lot of visual progress but technical details to brag about. The plan is to finally implement proper forward secrecy into the Messenger service in GNUnet . So a theoretical attacker can not access or read messages posted prior to their event joining a group chat. This is ensured by encrypting the content of messages with a key that changes every time, a client joins or leaves a chat. Additionally because chains of events can diverge in the Messenger service a merge event of two message chains that use different keys will also cause a new key generation and exchange. The big problem I’m trying to solve is how to make this most efficient without relying or trusting a central entity. Because the whole service is designed from ...

Hi again, as mentioned last time when talking about the user interface for discourses, I was looking into the implementation of video streaming this time. For this task I wasn’t really able to workaround using RTP or something comparable. So I tried looking into it again with success. The problem I had with it previously was actually related to me overlooking the structure GstRTPBuffer in the documentation of GStreamer . With that I was able to calculate the actual durations of each buffer. I could simplify the code handling video and audio streams into one with only some variables like datarate which differ. But overall it worked for RTP via both rtpL16pay and rtph264pay nodes. So I could transfer H.264 encoded video via GStreamer now without major issues. However one thing I needed to solve was getting encoding done on many different platforms and form factors. Because not every SoC or device offers hardware encoding and decoding which is preferable though reducing power cost ...

Hi there, so this month I can show you the UI of the voice chat in current state. It might still not be perfect for all cases. But I think it’s a good compromise for desktop, mobile and overall consistency with other features. The discourse of any chat room can be opened as dialog above the main chat window to open and close a discourse. So this dialog will prevent texting to some degree. However it can be closed without leaving the discourse. So users can go back to chat texting and sending files, while being in active discourse over voice chat. picture of dialog open in front of chat messages It is possible to mute yourself via a button in the dialog. It is possible to adjust the overall volume of all audio. Also I have added some other buttons which are disabled for now for future functionality. All active members of a discourse are visually represented in the center grid of the dialog. All members of a chat room are visually listed in a sidebar. Maybe I will add some options ...

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

Hi again, there have been a lot of changes again this month. The issue (I mentioned last time ) in the reclaim subsystem from GNUnet was solved. So I adjusted libgnunetchat and the Messenger service regarding the changes in the API. Sharing attributes using tickets works properly and I implemented a way to share profile pictures through it. picture showing current contact info and views to deal with attributes The implementation works like this: You select an image file which gets published via FS subsystem in GNUnet. Then its URI to request and download the file from FS gets shared as attribute under a spcified name. If a user then decides to share that attribute with one of their contacts, they receive the URI and automatically download and display the profile picture as expected. picture showing the contact info for the current account to set a profile picture There’s still room for improvement. For example I might add a setting to automatically share a profile pi...

Hi there, another month of development is over. A lot of improvements, fixes and adjustments have been made. I started by fixing remaining issues in libgnunetchat from the last month and published a minor release to solve it for builds. Then I continued tweaking the GTK user interface of the GNUnet Messenger . It’s now possible to filter messages in chats by tags. There’s also a dialog to add tags to a selected message. In the chat details side bar there will be a list of media previews as well as a list of all shared files from the chat. Additionally I got rid of a memory leak I noticed from the media previews. Now those will even take less memory as footprint during runtime and you can switch between different accounts fluidly without consuming too much space on low-powered devices. Another quality of life improvement is the added localization. I only did translations from default English to German. But additional translations of any labels in the UI can easily be added now. So ...

Hello again, this month we finally got the release of GNUnet 0.21.0 and in addition we released a new release of libgnunetchat and both messenger front-ends . I tried to make sure the flatpak and snap packages work. However there were some difficulties. For example the flatpak runtime, the application uses, did not contain libportal for some reason. I needed to include that. The release of libgnunetchat caused a build issue because it required a dependency from the new meson build of GNUnet . The usage of Pipewire caused an immediate crash because of missing permissions. At the same time I worked on the flatpak manifest to make it update its dependencies automatically in the future via the external data checker that Flathub provides. public relation picture of the messenger application In the end the flatpak seems to work now. Only camera access is still not fully cooked yet. On my Librem 5 it gives a format error and fails to show an image. If no camera is connected at ...

Hi again, As mentioned last time I’ve implemented so called transcripts now. When a user sends a PRIVATE message to another contact inside a chat, they will receive a transcript containing the information of the encrypted message but encrypted for themselves. Deletions and other actions which target the transcript message will be forwarded to target the original private message as well. chat in messenger-gtk showing a sent invitation So users can now read their own written private messages like invitations and delete them. Additionally I’ve implemented rejections of invitations using the new TAG message using an empty tag. This message can target any previous message via its hash and communicate tagging of messages or contacts (if applied to the last JOIN message of another contact in a chat). This will allow blocking of contacts service wide. Because the same way a user can reject invitations, they can reject other contacts now to block them. Unblocking them will simply dele...

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 messenge...

Hey everyone, welcome to my second (maybe this will become yearly now) overview of what projects I contributed to over the last year. You might remember that I already had enough projects for a filled up schedule but I can ensure you, I found something to derail my focus even more. But let’s call it another little gift to unwrap instead. The graphical Messenger application only got a few fixes, mostly to patch package configurations. I also changed the build system from GNU Autotools to Meson . Hopefully that’s the last time I change the build system. The service in GNUnet got some more contributions from me lately. Partially because I got financial support from NLnet again which I’m thankfully for. Also because I want to bring my studies to an end and it’s a great topic for research. But honestly I want this project to become a practical option for messaging. So you can expect more contributions on this project in the next months as well as my monthly blog posts about its progres...

Hey again, I’ve completed the necessary steps to solve the issue I talked last time. There are now three options for service configuration on each peer to specify how many peers need to manage message exchange actively at minimum ( MESSENGER_MIN_ROUTERS ), whether the own peer takes part in this functionality temporarily when required to achieve this minimum ( MESSENGER_AUTO_ROUTING ) and whether the own peer automatically reconnects to other peers keeping at least one external connection ( MESSENGER_AUTO_CONNECTING ). More details can be read in the bugtracker. This should improve the reliability of connections for applications quite a bit. Because those changes adjust defaults to always have at least three peers managing message exchange in a chat room. The exception is when less peers are connected to a chat room at all which should only be valid for private or direct chats with only one other person. One remaining aspect of this issue is that I still need proper testing whet...

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

Hey everyone, you have probably noticed that I didn’t provide the monthly updates about the GNUnet Messenger API since September . The reason for this is that my first goals completed and while I continued working on it, I contributed to other projects as well. So my time was limited. For example I did a lot of refactoring source code in the VkCV Vulkan framework and recently pushed a new release with a lot of features for developing graphics and rendering applications. There’s now also a blog to learn developing first graphics applications with this framework to utilize Vulkan (a cross compatible API for GPU acceleration). I’m currently one of the biggest contributors to this framework. So if anything might not work, feel free to contact me. Testing is very welcome and it’s fully open-source. That means contributions are welcome as well. Next thing I’m always trying to improve if I find the time is Manuskript . It’s a great tool for writers but it needs some work cleaning up its...