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 .

Async

Asynchronous programming is a neat tool, until you work with a foreign project in a foreign language using it. As a messenger, Dino uses lots of asynchronous code, not always though. Usually my progress wasn’t interfered by such instances, but sometimes I had to work around it.

Async in Vala

No surprises here. Functions are annotated with async , and yield expressions that are asynchronous themselves. And you can’t easily call async methods directly in non- async functions.

Creating problems

I had a async function I wanted to call in a synchronous context. For quick prototyping, I wanted to call that function and get the result directly by blocking. However, the furthest I got there was a variable in a function that is only initialized if you access it late enough (wouldn’t recommend). At that point I restructured the code so that the async call would actually be in an async context with a simple yield .

Here a proper introduction to Vala async .

MetadataProvider

With the introduction of the metadata element, more metadata can be extracted from files and attached to file transfers. You wouldn’t have guessed, but there are actually a rather big variety of file types. So not only do different files use different metadata fields, but they can also use the fields in different ways.

To accommodate that relation, the FileManager module now keeps a list of FileMetadataProviders, which will be extended over time. When a file is sent, each provider is asked if it is compatible with the file. If yes, it is called. The first provider is a generic one which is called for every file and fills in name, last-edit-date, size, mime-type and hashes.

Thumbnail creation

A special new field is a list of thumbnails. They are intended for small previews of whichever file it is attached to, be it a image, video or pdf. So far, I have implemented thumbnails for images, which introduced two design decisions.

Size : Which dimensions should the preview have? When it is displayed, it should be stretched to the format of the original image, so the aspect ratio should sort of match. My mentor, larma , suggested that we create very small thumbnails for now, about 8 or 9 pixels. Which dimensions would that allow? 1x8, 2x4, 3x3, 4x2, 8x1. Well, that sounds pretty diverse, no? Those are the dimensions that we use for now, and I select the dimension with the closest aspect ratio.

Scaling : Now that we have the size, how do we scale the image? Luckily, Gtk (which Vala is closely integrated with), has scaling methods for images. So far, I used bilinear scaling, which is usually the suggested method according to the docs. However, scaling to such a small size results in a lot of gray. While you could probably come up with a fancy custom-made algorithm, I’ll stick with the Gtk built-in methods. Maybe nearest-neighbor could be a better choice, because it would show a ’true’ color from the original image.

UI

I tried to hold off on UI work until the last weeks of the projects. While this could’ve easily been due to procrastination (I don’t enjoy UI coding a lot), I actually have a good excuse here. The Dino codebase is being migrated to Gtk4 from Gtk3 this year. Due to this, a lot of UI code is being rewritten, and it would’ve been wasted work to implement new UI elements in the old codebase. The new UI element I introduced is the FilePreviewWidget , which holds a thumbnail of files which are so large that they aren’t immediately downloaded (currently >5 MB). Luckily, the user interaction and graphical components are really close to the FileImageWidget and FileDefaultWidget , so the implementation wasn’t that difficult.

Progress

We are nearly finished. The one thing left is source attaching , which the next (and last) progress post will cover. Like always, you can track my progress on the stateless-file-sharing branch. I also created a pre-gtk4-rebase branch stateless-file-sharing-pre-gtk4 .

This is my next progress post about my Google Summer of Code project of implementing Stateless File Sharing (sfs)

Storing sfs sources in a database

Like everything else we receive, we need to store the sfs sources in a database. In this case, we are in a unique position: Not only are there different kinds of sources, but even http sources on their own are not trivial. For now, we only use the url, but later we need to store much more to receive all kinds of http files. Whether it’s cookies, necessary headers or authentication data, it would be a hassle to store everything in their own column or extra table.

Instead, we decided it would be easier and better with forward compatibility if we use some kind of serialization to be able to store any such data. For that we create a table SfsSources with file_id , source type and data . The idea is that we store the sources we obtain in a serialized data field. This way we can store elements we don’t use yet and have a unified table for everything. However, this also means that data can’t be searched properly with database queries.

Vala interfaces

This paragraph will compare elements of the programming languages Vala and Rust .

Being kinda new to vala, I struggled to map sfs sources into a class. The main issue is that it needs to support multiple variants.

In Rust, I would immediately go with a Rust enum , which allows you to store different data in each variant. For this, I was told that I should use a Vala interface . This confused me, because reading the documentation, they seemed to me a lot more like Rust traits : They define shared behavior that other classes can implement and then be passed generically as the interface type.

The big difference between Rust traits and Vala interfaces, however, is that you can easily cast the generic interface type back into its original class. Using this, they can also be used similar to Rust enums.

ALL the compatibility

I guess we are adding a new file transfer method. Well then, let’s maybe try to not lose compatibility with all the other clients?

Fallback body

When we send a sfs file transfer with a http source, we want to allow the receiver to see Out of Band Data . Exactly to support backwards compatibility, sfs can be attached to any other message, simply as another subnode. All we have to do here, is to create a normal message stanza with Out-of-Band-Data, and send the sfs along with it.

Double Receive

Well darn, now we receive that file transfer twice, because two modules registered an incoming file transfer. Who could’ve guessed.

Dino has about 4 entry points for message listeners

1. A Signal that listeners can connect to. Owned by MessageModule (module xmpp_vala )
2. A Pipeline of listeners owned by MessageModule (module xmpp_vala )
3. A Signal that listeners can connect to. Owned by MessageProcessor (module libdino )
4. A Pipeline of listeners owned by MessageProcessor (module libdino )

As we can see, there are two types of listeners, and each type is present in each xmpp_vala and libdino .

• Signal: listeners are called in an arbitrary order
• Pipeline: listeners are called in specified order, used when listeners depend on each other. Listeners can also drop messages so that they don’t get processed further
• xmpp-vala : Lower level, access to raw xml elements
• libdino : For text messages, called after messages are stored in the database

Out-of-Band-Data is retrieved via a ReceivedMessageListener that connects to MessageModule ’s signal and sfs via MessageProcessor ’s signal. To avoid the double-receive, we create a sfs MessageFlag , that gets attached when we successfully received sfs from a message. The Out-of-Band-Data listener first checks whether that flag is set, before parsing the message itself.

Unifying http file transfers

We of course still expect to receive Out-of-Band-Data messages. However, it is not very nice to need to handle two variants of http file transfer differently in databases and other code. The answer is rather simple here: When we receive Out-of-Band-Data, we convert it into an incoming sfs and handle it as such.

Next up

The next To-do I will approach is image and video specific metadata. As always, you can track my progress on my stateless-file-sharing branch

The last few weeks were quite busy for me, but there was also a lot of progress. I’m happy to say that the base of stateless file sharing is implemented and working. Let’s explore some of the more interesting topics.

File Hashes

File hashes have some practical applications, such as file validation and duplication detection. As such, they are part of the metadata element that stateless file sharing introduces. The hash values are stored as the base64 encoded raw byte representation of the hashes result. Multiple hashes can be added, and it is not specified which algorithm should be used. Instead, XEP-0414 has a maintained list of the recommended hash algorithms.

The idea behind not specifying which algorithm should be used is to keep flexibility and to stay future-proof. However, this does make implementations more complicated because you somehow have to handle multiple hashes, and perhaps from algorithms your code is unaware of. As of now, I intend to only send the sha256 in the metadata.

File Sources

As you might recall, the big idea behind stateless file sharing is that it is not bound to a specific method for file transfer. Same as with the hashes, multiple sources can be provided. For this project, the goal is just to have HTTP file transfers working (the base of which already works) in an extendable way. This is mostly because the type of jingle (peer-to-peer) file transfer that exists in Dino is not suitable for this: Dino currently only allows users to start a file transfer as the sending party (‘push’). Suitable would be if a sender could signal an available file and have the receiver signal that they now want to receive it (‘pull’).

New file transfer method in Dino

Turns out, you need to edit multiple components of a messenger when adding something that sends and parses certain messages. Figuring out which parts of Dino’s code I will need to touch wasn’t exactly clear to me. Dino is written in Vala , which was also a new language for me.

The components I had to touch are:

• xmpp-vala : low level XMPP code
• libdino : Code that can be used to build a messenger UI
• plugins : Messenger components that can be disabled

So, which parts of my code goes where?

• xmpp-vala : Stanza definitions, serializing, parsing, methods for the stanzas
• libdino : File management, storing data in the correct database, attaching to the correct XMPP streams
• plugins : To have libsoup as an optional dependency, HTTP file transfer stuff is a plugin

By adding the different components, I had to both edit and add new tables to the database.

• The FileTransfer table received more fields to accommodate the additional metadata
• FileHashes is a new table to store the triple file_id , hash_algorithm , and hash_value
• SfsHttpSources stores the tuple file_id , url . New columns can be added later for more complicated HTTP requests

Writing Vala and Debugging

Having not programmed in Vala before, I must say that I was very positively surprised at how little debugging I had to do. Most smaller things simply worked out of the box.

There were of course also instances where debugging wasn’t trivial. Especially database code and connecting to networking didn’t work out of the box for me. While trial-and-error with printf-debugging sometimes did the trick, sometimes I figured that outside help would cut down the time I would need drastically. For many things I contacted my mentor, Marvin who could usually point me in the right direction very quickly, which made work on the project quite pleasant.

Also helpful was of course debugging with gdb. In particular when critical warnings are already output, setting the environment variable G_DEBUG=fatal-criticals helps a lot. This will simply break on every such warning, which allows you to easily inspect what went wrong.

Next Steps

While there was a lot of progress, there are also a good amount of loose ends to tie up. The reusage of the HTTP send and receive code is a bit hacky, and some parts of the code should be written more extendable. Next up is cleaning up the code that was introduced. After that, there is still obtaining the image- and video-specific metadata and some UI work.

As always, progress can be tracked on my stateless-file-sharing branch

Hey, this is my first development update! As some of you might already know from my last blog post, my Google Summer of Code project is implementing Stateless File Sharing for Dino. This is my first XMPP project and as such, I had to learn very basic things about it. In my blog posts I’ll try to document the things I learned, with the idea that it might help someone else in the future. I won’t refrain from explaining terms you might take for granted in the XMPP world.

The idea behind Stateless File Sharing

Currently there are mutiple ways to send files via XMPP. Some of those methods initiate the file transfers in very different ways. This makes it difficult to add shiny new features like blurred previews of images, because we would need to implement that for each file transfer individually.

What we want is a unified initiation for file transfers. In that initiation, “sources” should be specified that tell the receiver how they can access that file.

Relevant XEPs

The core of the XMPP protocol is very slim, defining only general ways of communicating data. It is build to be extensible, and XEP are exactly that: XMPP Extension Protocols.

Stateless File Sharing is XEP-0447 . It depends on XEP-0446 , which defines the metadata that should be sent alongside a file. XEP-0446 in turn depends on XEP-0300 , where the integration of hashes is specified, and XEP-0264 , which defines the usage of thumbnails.

Stanzas

This is a term that comes up everywhere if you dive into XMPP technical information. Since it confused be for a while, here a quick rundown.

Stanzas are the basic form of communication between XMPP clients and servers. There are different types of them, but they are all encoded with XML. As such, they inherit XML’s structure.

An XML element can be viewed as a tree. See for instance the format example for the file metadata element ( XEP-0446 ):

<file xmlns='urn:xmpp:file:metadata:0'>
    <media-type>text/plain</media-type>
    <name>test.txt</name>
    <date>2015-07-26T21:46:00+01:00</date>
    <size>6144</size>
    <hash xmlns='urn:xmpp:hashes:2'
          algo='sha-1'>w0mcJylzCn+AfvuGdqkty2+KP48=</hash>
</file>

The root element is called ‘file’, and has only one attribute “xmlns”. Each attribute has a value assigned, in this case its ‘urn:xmpp:file:metadata:0’. The ‘file’ element also has child elements, all containing a text body. Only the “hash” child element has an additional attribute.

Progress (as of 29/06/2022)

I’m now familiar with how Dino represents Stanzas. I’ve created the base struct for the file metadata element ( XEP-0446 ) and serialize, send, and deserialize it. So far I simply integrate the code into the http file transfer code, detaching from it will come later.

You can track my progress on my stateless-file-sharing branch !

Hey!

I’m Patiga, a computer science student from Germany and a new contributor to Dino. The yearly Google Summer of Code has started, and I’m glad to be part of it. This time, you can look forward to a modernized file transfer called “Stateless File Sharing”.

End users can look forward to blurred previews of large images and other metadata alongside file transfers. You might already know this from other messengers, now it’s coming to Dino/XMPP.

There are some more technicalities, which we will dive into deeper in upcoming blog posts. If you want to have a peek at some technical information already, see the relevant XEP-0447 .

Dino is a secure and privacy-friendly messaging application. It uses the XMPP (Jabber) protocol for decentralized communication. We aim to provide an intuitive, clean and modern user interface.

The 0.3 release is all about calls. Dino now supports calls between two or more people!

Calls are end-to-end encrypted and use a direct connection between the peers whenever possible, but fallbacks are also in place.

As always, we put lots of love into the user interface and hope that you will enjoy using it. To call a friend, just open a conversation with them and select whether you want to start an audio-only or a video call.

Groupcalls

You also can start a call in a private group or invite additional contacts to an existing call. Using a peer-to-peer approach for groupcalls means that no additional server support is required, besides conference rooms.

Peer-to-peer calls require more bandwidth than calls routed through a server and are thus not suited for a large number of participants. In the future, we plan to also develop calls via a forwarding server to solve resource issues on the client side and to allow for calls with more participants.

Encrypted

Calls are end-to-end encrypted with the best encryption supported by both you and your contact. The encryption keys for a call are exchanged using DTLS and the call is then encrypted with SRTP. You can see the DTLS keys used for the current call in the UI and compare them with the ones your contact sees.

Additionally, the DTLS keys are authenticated using OMEMO. If you verified the OMEMO key beforehand, you can be sure that you have an end-to-end encrypted call with a device that you trust.

Interoperabilility & Open Protocols

Calls are established and conducted using openly standardized protocols. Call intents are sent ( XEP-0353 ) and connection methods exchanged via XMPP ( RFC 6120 ) in a standardized way ( XEP-0167 ), the data is encrypted ( RFC 5763 ) and transferred ( RFC 3550 ) all via standardized and documented means.

You can establish calls between Dino and every other application that follows these standards. Encrypted video calls can be made between Dino and for example Conversations or Movim. With clients like Gajim that don’t support encryption, making unencrypted calls is also possible. If a client doesn’t support video, audio-only calls can still be made.

Theikenmeer

Peat bogs are unique ecosystems that mitigate the effects of climate change if they’re in a natural state, but worsen climate change when they are drained. We named this Dino release “Theikenmeer” after a bog nature reserve in Germany to help spread the word about these important yet endangered ecosystems.

Peat bogs are wetlands that accumulate peat, a deposit of dead moss and other plant material. Due to low oxygen levels, moss below the water surface does not decay and thus accumulates bit by bit. By accumulating plant material, bogs store carbon. Although they only make up 3% of the world’s land surface, bogs store twice as much carbon as all forests together! [ 1 ]

Besides capturing carbon, a bog also provides other benefits to its surroundings. A bog acts like a sponge: It absorbs water when it’s abundant and releases it back into the surrounding when it’s dry. Thus, it reduces the severity of floods and droughts. Bogs also lower the temperatures in the surroundings, filter the groundwater and are home to endangered and specialized plants and animals.

During the last centuries, peat bogs have been increasingly drained in order to make use of the land or to extract the peat. When a bog is dry, the accumulated plant material starts to decay, releasing the stored carbon into the atmosphere.

Theikenmeer is a nature reserve in the north-west of Germany containing a peat bog and a lake. The peat bog has been drained to extract peat and due to nearby farming until the peat bog and the lake were completely dried out by 1977. It has been calculated that the Theikenmeer peat bog would release 2250 tons of CO₂ into the atmosphere every year while it’s dry [ 2 ]. Fortunately, volunteers started closing the drainage channels in the early 1980s. Today, the bog is wet again and bog plants and wildlife started returning into the area, allowing the bog to capture CO₂ instead of releasing it.

Theikenmeer’s peat bog belongs to a small percentage of natural peat bogs in Germany. However, over 90% of all peat bogs in Germany are still drained, causing almost 7% of Germany’s yearly greenhouse gas emissions [ 3 ]. Drained peat bogs only make up 0.3% of the world’s land surface, yet they emmit 5% of all anthropogenic greenhouse gases [ 1 ].

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

The 0.2 release adds message correction, improves the file upload functionality and provides more information about message encryption. Besides other smaller changes it also fixes a number of bugs.

Message correction

It is now possible to correct the last message you sent. You can access the function by hovering the message that you want to correct and then click the edit button that appears. If you’re a fan of shortcuts, you can also press the UP key. Last message correction has been the most frequently requested feature addition so far. We are happy about how it turned out and hope you are, too!

File sharing

You can now send files via drag and drop! Furthermore, you can now send Images by pasting them from your clipboard. As before, there is also still the option to press the “Send a File”-button.

Especially with those new ways of sending a file it is important to know that you are sending the right file to the right person. That’s why Dino now presents a confirmation dialog with a file preview and some file details.

Encryption

It has already been possible to accept, verify or reject OMEMO keys. Now you can see the relevant information alongside each message: A small lock or seal symbol above a message indicates whether the message was encrypted by an accepted or a verified device, respectively. A red, open lock warns you in case your contact sends unencrypted messages in an encrypted conversation.

Unread, pending and more…

Dino now displays the number of unread messages in the conversation list. The color of the circle tells you whether the new messages triggered a notification (e.g. direct messages, mentions in channels).

Furthermore, Dino lets you know in case your message has not been sent yet by displaying “pending…” alongside the message.

In moderated channels, Dino will inform you if you don’t have the permission to write messages and offer the possibility to request that permission from a moderator.

Coral Reefs

Coral reefs are diverse and important ecosystems. Climate change and local human influences endanger coral reefs around the world. We named this Dino release “Mexican Caribbean Coral Reefs” to help spread the word about what needs to be done to preserve these unique ecosystems.

While coral reefs only occupy 0.1% of the ocean area, they are home to 25% of all marine species. Those reefs are made up of the calcium carbonate skeletons of corals. Corals grow very slowly and thus reefs require thousands of years to form. Many tropical corals live in symbiosis with tiny algae, which provide the corals with nutrients in exchange for shelter.

Climate change harms corals in two ways: First, it raises the ocean temperatures. Corals lose their algae in high water temperatures, which is called “bleaching”. Without the algae the corals starve. Secondly, the ocean absorbs parts of the increasing carbon dioxide amounts from the atmosphere. In water, CO₂ reacts to carbonic acid, which dissolves coral skeletons.

Many coral reefs are located in the shallow water near coasts and are thus highly affected by local human activities: Sediments and nutrients are washed into the ocean and deprive the corals of light; Overfishing can negatively affect the whole ecosystem; Destructive fishing using poisons or explosives harms the corals.

For example, the coral cover in the Mexican Caribbean Coral Reefs decreased by 60% between 1980 and 2016. This was caused by mass bleaching events due to increased water temperature, hurricane impacts, and an increased amount of sediment due to deforestation [ 1 ].

Various programs aim to protect individual coral reefs from local dangers. However, the ecosystem coral reef can only be preserved by also eliminating the global threat: Climate change. According to multiple studies, coral reefs only have a chance of survival if the global temperature increase is limited to 1.5°C [ 2 , 3 ]. Your actions have an impact.