XMPP and Metadata

Summary

I had the pleasure of giving a talk on "XMPP and Metadata" during the last Chaos Communication Congress, in the Critical Decentralization Cluster area. It was my first public presentation in a very long while (also in english), so the talk went okay-ish at best. The end of the year was also hectic and I did not manage to prepare or rehearse as much as I would have liked to. This blog post will be a longer, more complete version of the talk. You can nonetheless find the talk slides on the CDC pretalx. Thanks a lot to the people who proofread the blog post to fix stuff or suggest additional content. This was about metadata, but also generally data retention and what the server sees in general. Obvious message workflow This might be too obvious for most people, but for clarity’s sake, I want to assert that to send a message to another entity, you need: a sender a message a receiver This is not technical, this is baked into the concept of sending a message. Those elements will always be present somewhere in the workflow. Assuming a working encryption system, the message data itself will not be considered. There are, however, some technical tricks that can hide a lot of things from the infrastructure layer. XMPP I cannot really make this an introduction to XMPP but to summarize, XMPP is an extensible federated protocol for messaging and presence. It is using XML for the most part but nobody should care (except trolls, I guess). It started in 1999 as Jabber, and grew to be an IETF standard under the name XMPP after Jabber got bought by Cisco (we can still use the Jabber name in many ways). The protocol started server-heavy with light clients - and in fact, you will read as much in the "XMPP, the definitive guide" book -, but the trend got reversed in the last decade due to the rise of mobile clients which can be updated very often and other circumstances. There are clients and servers, and it is therefore a protocol made of client-to-server interactions and server-to-serv...