Draupnir is a unified platform to grow, manage, and sustain communities on Matrix. Over the last 3 years we have learned many lessons to share with the community on building trust and safety tooling in an open federation.
We will discuss just a few of the many problems we have faced, and our experience solving them
https://github.com/the-draupnir-project/Draupnir
Policy servers (MSC4284) are a new tool available to communities on Matrix to help reduce spam and other unwelcome content, but they aren't the only option. Communities have a whole suite of tools available to them to keep their users safe, such as moderation bots and in-client safety features.
In this talk, we'll cover the layers of Trust & Safety (T&S) tooling available to communities, how they work, and what harms they are typically best at mitigating. We'll also demonstrate how to set up a policy server in your community, and discuss what they might be able to do in the future.
As protocols and platforms grow, so do the demands of policy enforcement, human review workflows, and cross-platform incident response. Trust and safety tools form this critical layer of Internet infrastructure, yet most solutions remain closed, proprietary, and reinvented in isolation. Further, they’re typically out of reach for smaller and decentralized platforms.
Robust Open Online Safety Tools (ROOST) is building a different future: one where these trust and safety tools are open, transparent, community-governed, and usable by platforms and organizations of all sizes. In this talk, you’ll get a refresher on what “trust and safety” means; hear how ROOST is succeeding with a non-profit and open source approach; learn about the newly-released Osprey rules engine and investigation tool—already in production across platforms like Bluesky and Discord; see a demo of Osprey in action; and finally, learn how to adopt and contribute to Osprey and other open source trust and safety tools with ROOST.
An overview of all that's been happening with the Matrix protocol in the last year, including: * Project Hydra (state resolution improvements) * Trust & Safety improvements * Matrix 2.0 MSCs (OIDC, Simplified Sliding Sync, Matrix RTC and Invisible Crypto) * P2P Matrix progress * Encryption advances with MLS, post quantum * Updates on the scores of public sector Matrix deployments we're seeing emerge as countries seek digital sovereignty... ...and more!
Element Web is the oldest and most widely deployed Matrix client, and could well be the most widely deployed decentralised comms client in active service, especially when considering its many forks (Tchap, openDesk Chat, BundesMessenger, SchildiChat, LuxChat, etc.)
Over the last 11 years it has accumulated a very significant amount of technical debt, and we believe that one of the main ways to accelerate the uptake of decentralised communication would be to be radically improve the codebase. This means not doing a rewrite, and instead figuring out how to carefully switch the engine mid-flight from matrix-js-sdk to matrix-rust-sdk running in WASM, ensuring Element Web benefits from all the improvements which have landed in the Element X mobile apps, while simultaneously stopping reinventing the wheel between the two stacks. We'll demonstrate experiments with Aurora as our playground for running Element Web's react components on top of matrix-rust-sdk, and explain how we hope to bring decentralised comms to a wider audience by making Element Web as performant and snappy as Element X.
This talk should be of extreme interest to anyone who has ever complained about Element Web being slow or RAM hungry, and who wants to see a world where decentralised comms can outrun the centralised alternatives!
Discover how MatrixRTC transforms into a "backendless" multiplayer game server and join us for a live Godot game session inside a Matrix widget.
The VOIP team at Element will present their progress on abstracting an RTC SDK from the Element Call stack. We want to share the current state as we try to use it to build a multi-player game.
If you are familiar with Godot, you will learn how to potentially use Matrix as a free, encrypted backend that handles account creation and persistent storage.
At the end, there will be a gaming session with the devroom! Prepare to battle!
Element is the most widely deployed Matrix client, built by the team who created Matrix in order to bootstrap the ecosystem. The last few years have been quite a rollercoaster in terms of figuring out how to ensure Element can contribute to Matrix sustainably long-term - a problem faced by many open source projects whose core team works on the project as their day job.
The good news is we think we've now found a sustainable model that works, having moved from Apache to AGPL and having finally released an official Matrix distribution from Element in the form of Element Server Suite (ESS) Community under the AGPL. In this talk we'll give a super quick tour of the journey that we've been on and the learnings encountered along the way, in the hope that other decentralised comms projects can learn from our mistakes and successes. We'll look at the work Element's been doing to sustainably progress Matrix - be that driving forwards Matrix 2.0 spec work, maintaining Synapse, or ensuring that matrix-rust-sdk provides a foundational client SDK suitable for Element X, Fractal, iamb and more.
Finally, we'll take a quick look at how Element has ended up bringing decentralised communication to the heart of public sector open source collaboration suites such as Germany's openDesk from ZenDiS, France's La Suite from DINUM, and The Netherlands' MijnBureau from MinBZK - and take a look at what the future may bring!
Messaging Layer Security (MLS) is an IETF standard (RFC9420) for end-to-end encryption in messaging systems. However, it requires a delivery service that determines an ordering of handshake messages, which does not fit with certain messaging architectures. In this talk, we will explore some of the work that has been done to make MLS work in a distributed/decentralized environment, and look at some of the remaining issues.
Building open federated communication systems requires more than publishing specifications. It demands a living ecosystem of independent implementations that actually work together. The XMPP Standards Foundation (XSF) is a standards body, but is also the center of a development ecosystem that encompasses 5+ major servers and 20+ clients, all developed by different individuals and organizations, all highly interoperable and shipping new features at an accelerating pace.
This talk will share how all this can work at this scale and will be co-presented by a server developer and a client developer, showing how they work together to fine-tune their implementations.
We will first explain how the XSF works on its specifications, how its process has improved over the years, with proven engineering patterns that enable independent projects to build interoperable features without tight coupling (and without central coordination).
We will illustrate the talk by showing real-life collaboration examples that came to life in 2025, sharing the points of view of an ejabberd server developer and the Movim client developer.
As a conclusion, we will tease new features currently in design for 2026 and give you a glimpse at messaging federation, the XMPP way.
This talk is for people who are interested in contributing to a truly decentralized protocol design initiative or who would like to understand what they can expect from XMPP in the future, based on examples of what has been achieved in 2025.
What if you could have chat, video conferencing, blogging, and social communities all in one place without giving up your data to a centralized platform? Movim is a web-based application that brings the full power of XMPP to end users, combining instant messaging, group chats, video calls, and a complete publishing platform into a unified experience.
In this talk, I'll present how Movim leverages the XMPP standard and its extensions (Pubsub, MUC, Jingle) to deliver features users expect from modern social platforms while remaining fully federated, interoperable with other XMPP clients like Conversations and Dino, and capable of bridging to centralized platforms like Discord, Telegram, and WhatsApp!
I'll discuss the technical challenges of building a rich web frontend on top of XMPP, showcase the exciting features recently added to the project, and introduce the upcoming planned ones.
Whether you're an XMPP enthusiast or curious about decentralized alternatives to mainstream social media, come discover how Movim is bridging the gap between protocol power and user experience.
Official website: https://movim.eu/
Do you remember the "Now Playing" feature in MSN Messenger? It was a feature that make you able to see which song are your friends listening at the moment back in 2000s, but unfortunately it is mostly forgotten now.
In this talk, I will share the journey on my research on implementing this feature in modern XMPP clients, the protocols of certain operating systems to read the currently playing media, the current status of the support of XEP-0118[^1] and the PoC of a modern "Now Playing" feature.
[^1]: XEP-0118: User Tune
Bonfire is a next-generation, open-source platform for building trustful communities and federated networks. It reimagines social communication by allowing communities to enable, disable, or adapt features and even protocols, putting community governance, and autonomy combined with consentful interconnection at its core. Bonfire federates with ActivityPub, with bridging available to ATproto (and hopefully more to come). Bonfire’s federated groups, thread-centric discussions, and modular architecture make it easy to experiment with new forms of moderation, identity, and trust that reach beyond single servers, single platforms, or single protocols.
This talk will cover:
Our ongoing work and demo of fully end-to-end encrypted messaging (MLS-based) over ActivityPub, one the first two implementations of its kind
ActivityPub C2S API use: how apps can easily integrate with the fediverse (including MLS messaging) via Bonfire
Interoperability: extending ActivityPub for advanced user stories, moderation, as well as bridging with ATproto and potential future integrations with Matrix, XMPP, etc.
Consentful communication flows and privacy-preserving tools for trust and safety (such as circles and boundaries)
Bonfire’s modular architecture: designing “app flavours” with custom governance, moderation, and communication tools for different community needs
Attendees will see a live demo and leave with ideas and tools for composing their own modular, federated, and privacy-focused social communication spaces.
Links:
Links:
- Project
- Docs
- Code
- Interop & FEP/Protocol extensions
DASL (Data-Addressed Structures & Links, https://dasl.ing/) is a suite of small and simple specs that provide a proven, reliable, interoperable toolbox for content-addressing that can be used in other protocols. It has quality implementations in multiple languages, has multiple components used by the AT Protocol, and has some parts also documented in an IETF draft. For the most part, it is a subset of IPFS ruthlessly aimed at interoperability and ease of use. This talk offers a tour and introduction to the core concepts, and provides pointers for reuse in other protocols.
Decentralized Key Management / Self Sovereign Identity holds the promise of a truly decentralized, self-verifying PKI. Approaches like KERI, the Key Event Receipt Infrastructure, balance privacy, verifiability, and the protection from duplicity. But their promises have remained largely academic thus far. In 2026, the Swiss Healthcare System will be the first large-scale deployment of this kind of infrastructure, using it to upgrade the trust, security and privacy levels of its aging email infrastructure. The result will be a production ready technology stack that can be utilised for a large number of use cases around communication.
Georg Greve is centrally involved in that transition, and will share the road travelled so far, the current state, and the next steps for this transformation.
Background: https://www.hin.ch/de/blog/2025/vom-mailgateway-zum-data-mesh.cfm
Social graphs are a well-understood technology. Using infrastructure and standardized protocols that are usually de facto controlled by large, commercial platforms, they provide a way of structuring and querying data about individual nodes (often users) in a network and the relationships (edges) between these nodes. They are theoretically extensible, and social graph data can typically also be represented using open standards like RDF which can be published and consumed by other authorities participating in a network. However, trying to enable participation or federation this way is frequently wishful thinking, and does not really facilitate scaling that social graph beyond a particular API representation of rows in one organization’s database.
The Atmosphere — built on AT — presents a different approach. When you write data using Atmosphere APIs, such as by posting to Bluesky, that data is associated with your personal data repository. These personal data repositories can be hosted or migrated anywhere across the Atmosphere. Each Atmosphere app declares its own schema (Lexicon), and reads and writes its own set of fields. These fields can be read by any other app built on the Atmosphere, allowing users to both a) own and b) span their graphs across the network.
This enables several in-demand use cases. Building “big world” social apps with AT is only a matter of creating new lexicons to support additional data models, designing app views which serve this data (along with any other data that may already be available to a user’s graph from other AT apps), and self-hosting the necessary infrastructure.
We provide implementation patterns, along with primitives and tools that are of interest to almost all implementers — like OAuth Scopes and moderation tools. We also provide a social networking app (Bluesky Social) that serves as both a reference implementation for the protocol, and a critical-mass opportunity to populate users’ social graphs so that other application developers can benefit from shared data. Regardless of which application is using this data, all of it is open, public, and associated with individual users’ data repositories, which can be migrated across the network at will.
This talk will provide a demonstration of some fundamental AT technologies, including: "Sipping the Firehose" - working with the stream, a demo of creating records and have them pop right out “Getting backlinks with Constellation” - querying social interactions in real time, and building that data into different interfaces “Lexicon Authoring” - a discussion of best practices for creating additional schemas, with examples from other apps in the Atmosphere
I had a few talks at conferences, entitled "Disobay: FOSS tools to fight back," where I explained what tools exist for us to protect our communication and why we should use them. I covered several decentralized tools and protocols, and then I asked, "Are there any questions?" One person asked, "How do I convince my friends to move to those tools"? And the audience nodded in agreement.
Then I took this topic seriously. With this talk, I aim to cover the subject of their adoption - we all build great tools, but what approaches can we use to encourage people to join the right side? The majority of the cases I would showcase are from real people on my fediverse, Hacker News, and other networks I'm a part of.