Dino is a secure and open-source messaging application. It uses the XMPP (Jabber) protocol for decentralized communication. We aim to provide an intuitive and enjoyable user interface.

The 0.4 release adds support for message reactions and replies. We also switched from GTK3 to GTK4 and make use of libadwaita now.

Reactions and Replies

Reactions give you a quick and light-weight way to respond to a message with an emoji. They can be used to express agreement or disagreement 👍️👎️, for voting, to express a feeling 🥳🤯, and much more 🦕. You can react with any emoji you want and with as many as you want!

The new Dino release also adds another way for you to interact with messages: Replies. The original message is displayed alongside the reply, and you can click on it to jump up to the original message.

You can add a reaction or reply to a message via the message menu. To access the message menu, hover the message or tap it on touch-screens.

Reactions and replies are always possible in direct conversations. In group chats and channels, the admin decides whether to support the features.

GTK4 and libadwaita

Dino now uses GTK4 instead of GTK3 to display its user interface. To the outside there are no big UI changes. However, we can now make use of new or improved GTK features.

Furthermore, we started using libadwaita, which contains specialized Widgets and provides tools to build mobile-friendly UIs. We already adjusted Dino’s main view for usage on mobile devices.

Ilulissat

Glaciers are fascinating landscapes of flowing ice. We named this Dino release “Ilulissat” after a glacier in Greenland to help spread information on the effects of global warming on glaciers.

Glaciers are created over a span of centuries from fallen snow that compacts and transforms into glacial ice. When the ice reaches a certain thickness, it starts to behave like a liquid. Thus, glaciers are in constant movement, driven downhill by gravity under their own weight.

Satellite view of the Ilulissat glacier and icefjord

Very large glaciers, also known as ice sheets, exist on Antarctica and Greenland. Greenland’s ice sheet covers about 80% of the island and has an average thickness of 1,5 km.

The Greenland Ice Sheet, like all glaciers, is constantly in motion. It accumulates ice in the interior of the island and flows outwards, eventually reaching the ocean through so-called outlet glaciers. One such outlet glacier is the Ilulissat glacier in West Greenland, the fastest draining outlet of the Greenland Ice Sheet with a flow speed of over 20 meters per day.

Unfortunately, the Greenland Ice Sheet has been shrinking for past 26 years [ 1 ]. Rising water and air temperatures are causing outlet glaciers to melt at an accelerating pace, draining the ice sheet more quickly and resulting in increased sea levels [ 2 ]. Between 1992 and 2020, meltwater from the Greenland Ice Sheet alone increased global sea levels by over 1,3 cm, where every centimeter of sea level rise is estimated to expose 6 Million people to coastal flooding [ 3 ].

Recap

Stateless file sharing (sfs) is a generic file sharing message which, alongside metadata, sends a list of sources where the file can be retrieved from. It is generic in the sense, that sources can be from different kinds of file transfer methods. HTTP, Jingle and any other file transfers can be encapsulated with it. The big idea is that functionality can be implemented for all file transfer methods at once, thanks to this wrapper.

Source Attaching

The idea is simple: Once somebody started sfs, anybody can contribute more sources to the list of sources. A sfs-attachment consists of the message id of the original sfs, as well as a list of sources that should be attached.

You might ask: “But why? I have used many messengers and never heard of such a feature, why should somebody else in the chat be able to do that?”

I was surprised as well, but there actually are some reasonable use cases.

1. Peer-to-Peer file sharing in groups
2. Reviving dead download links
3. Announcing file uploads before the upload is finished

Security Considerations

We obviously have to prevent the possibility of other members attaching wrong files to other people’s sfs. To prevent this, sources can only be attached to sfs, which have checksums in their metadata.

Clients need to dismiss source attachments,

1. if the sfs didn’t provide a checksum
2. if the checksum algorithm is not trusted or unknown
3. if the checksum of the downloaded file doesn’t match

Google Summer of Code Retrospect

This was the first time with Google Summer of Code and honestly, it’s been a nice ride. I’ve come to enjoy my stay and take pride in finishing the different components.

When I started earlier this year, I had developed a bit of an Imposter syndrome . For one I wasn’t sure if I understood the full scope of the project, but I was also uncertain if I had the skill to work on it.

Confidence came over time, when I managed to get an overview of everything that needed to be done. Everything suddenly looks much more manageable, when you understand the purpose and inner workings of each subcomponent that will be required over the way. Of course, it’s not completely straight forward. I often had to realize that I will need another component somewhere, but one thing at a time is manageable. Since I had my mentor to back me up whenever I got stuck, working on the project didn’t get frustrating.

Blog posts

Parallel to working on the project, we were expected to publish blog posts. Originally I was going for a weekly interval, but yea…

I don’t think writing the blog posts helped me in any meaningful way. However, I do think writing blogs is a good habit and hope that

1. I improved my blog writing skills
2. The blogs will someday help someone

Progress

The GSoC period has already finished. See my pull request .