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