Posts

GNUnet Messenger API: March 2024

Image
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

GNUnet Messenger API: February 2024

Image
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

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 messenge

Development in 2023

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

GNUnet Messenger API: December 2023

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

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

Nreal Air support in Monado

Over the last months (from April to September) I tinkered around with an Nreal Air. It’s an augmented reality device, essentially a pair of glasses with displays projecting a virtual content into your view. You can connect it to your phone, console or PC via a USB-C cable. Then in theory you can have 360° virtual monitors. But the whole package had a slight flaw. The manufacturer only targets Android, iOS, macOS and Windows with an own proprietary SDK and an app. So even the community on those platforms wasn’t entirely happy with that. Why did I get such a device then? Well, I’ve seen a review of it and it was mentioned to support the Steam Deck. So naturally I thought if any device running GNU/Linux is supported in any way at all, I could likely get it to work with every device running GNU/Linux. Then I received the actual hardware and I had no officially supported device other than my Steam Deck. But with that it worked, right? Well some functionality worked great out of the box. I