Implementing Encrypted Messaging over ActivityPub
Social Web Foundation
4
Posts
4
Posters
20
Views
-
One of the project areas of the Social Web Foundation for the last year has been end-to-end encrypted messaging. ActivityPub, the standard protocol that powers the Social Web, has privacy controls, but they do not protect the content of messages from server operators. Encrypted messaging has become a standard feature on most social networks since ActivityPub was created, and its lack has inhibited Social Web adoption and public trust in the network.
ActivityPub is extensible, though. As part of our E2EE program, Mallory, Tom and I adapted the Messaging Layer Security (MLS) standard as an extension of ActivityPub to make the MLS over ActivityPub specification. The protocol fits the great MLS E2EE system onto the ActivityPub API and federation protocol.
But a protocol specification is not enough; it must be implemented. That’s why we’re so happy to announce that the Sovereign Tech Fund has commissioned work with the Social Web Foundation to coordinate two new interoperable implementations of MLS over ActivityPub. This investment by the Sovereign Tech Fund will help move the Fediverse towards more privacy for social web users, no matter what server they use.
We decided to partner with two different projects in order to make sure that we’re making an open standard that can work between implementations. With two implementers, we’ll need to communicate clearly about architectural and implementation decisions, and make sure that those decisions end up in the final version of the spec — not in a
TODOcomment in the source code of a single project.The first project is Emissary, the great social web application platform behind projects like Atlas and Bandwagon. Ben Pate, Emissary founder, says, “The Emissary Project is deeply committed to the Fediverse, where we are building a free and trustworthy Internet for all 8 billion humans. Delivering on that promise, Emissary is excited to team up with the Social Web Foundation to bring End-to-End-Encryption (E2EE) to the Fediverse. We are eternally grateful for the SWF’s leadership and support, without which this project could not have happened. Our work is already underway, and in 2026 anyone will be able to build E2EE applications on the Emissary platform.”
The second project is Bonfire. Bonfire is a modular framework for building federated apps, with its first app (Bonfire Social) offering a social networking experience enhanced with tools for privacy, trust, and collaboration (such as circles and boundaries).
The maintainers of Bonfire, Ivan Minutillo and Mayel de Borniol, said: “We think that end-to-end encryption should simply be the default for any private communication online. Working with the Social Web Foundation to bring E2EE to ActivityPub marks a crucial step in fostering privacy and trust, and especially in enabling the fediverse to become a safe space for activists and communities to organise, coordinate, and collaborate meaningfully. By making secure, user-friendly messaging a core part of the fediverse, we’re helping lay the groundwork for decentralised networks where people can go beyond talking in the mythical ‘global town square’ and actually organise and accomplish things together.”
This work will happen best if the Fediverse community tracks it closely. We’ll be making updates here on the SWF blog as progress continues. Developers and active users may also be interested in the ActivityPub E2EE Messaging Task Force at the W3C, where the specification is being developed into a report for the Social Web Community group. Finally, we’ll be using the #JustBetweenUs hashtag to share progress and ideas, so you can follow it to see what’s been happening.
-
One of the project areas of the Social Web Foundation for the last year has been end-to-end encrypted messaging. ActivityPub, the standard protocol that powers the Social Web, has privacy controls, but they do not protect the content of messages from server operators. Encrypted messaging has become a standard feature on most social networks since ActivityPub was created, and its lack has inhibited Social Web adoption and public trust in the network.
ActivityPub is extensible, though. As part of our E2EE program, Mallory, Tom and I adapted the Messaging Layer Security (MLS) standard as an extension of ActivityPub to make the MLS over ActivityPub specification. The protocol fits the great MLS E2EE system onto the ActivityPub API and federation protocol.
But a protocol specification is not enough; it must be implemented. That’s why we’re so happy to announce that the Sovereign Tech Fund has commissioned work with the Social Web Foundation to coordinate two new interoperable implementations of MLS over ActivityPub. This investment by the Sovereign Tech Fund will help move the Fediverse towards more privacy for social web users, no matter what server they use.
We decided to partner with two different projects in order to make sure that we’re making an open standard that can work between implementations. With two implementers, we’ll need to communicate clearly about architectural and implementation decisions, and make sure that those decisions end up in the final version of the spec — not in a
TODOcomment in the source code of a single project.The first project is Emissary, the great social web application platform behind projects like Atlas and Bandwagon. Ben Pate, Emissary founder, says, “The Emissary Project is deeply committed to the Fediverse, where we are building a free and trustworthy Internet for all 8 billion humans. Delivering on that promise, Emissary is excited to team up with the Social Web Foundation to bring End-to-End-Encryption (E2EE) to the Fediverse. We are eternally grateful for the SWF’s leadership and support, without which this project could not have happened. Our work is already underway, and in 2026 anyone will be able to build E2EE applications on the Emissary platform.”
The second project is Bonfire. Bonfire is a modular framework for building federated apps, with its first app (Bonfire Social) offering a social networking experience enhanced with tools for privacy, trust, and collaboration (such as circles and boundaries).
The maintainers of Bonfire, Ivan Minutillo and Mayel de Borniol, said: “We think that end-to-end encryption should simply be the default for any private communication online. Working with the Social Web Foundation to bring E2EE to ActivityPub marks a crucial step in fostering privacy and trust, and especially in enabling the fediverse to become a safe space for activists and communities to organise, coordinate, and collaborate meaningfully. By making secure, user-friendly messaging a core part of the fediverse, we’re helping lay the groundwork for decentralised networks where people can go beyond talking in the mythical ‘global town square’ and actually organise and accomplish things together.”
This work will happen best if the Fediverse community tracks it closely. We’ll be making updates here on the SWF blog as progress continues. Developers and active users may also be interested in the ActivityPub E2EE Messaging Task Force at the W3C, where the specification is being developed into a report for the Social Web Community group. Finally, we’ll be using the #JustBetweenUs hashtag to share progress and ideas, so you can follow it to see what’s been happening.
@evanprodromou is this overlapping or alongside the work done by @soatok ?
https://soatok.blog/2025/12/15/announcing-key-transparency-fediverse/
-
undefined evan@cosocial.ca shared this topic on
-
One of the project areas of the Social Web Foundation for the last year has been end-to-end encrypted messaging. ActivityPub, the standard protocol that powers the Social Web, has privacy controls, but they do not protect the content of messages from server operators. Encrypted messaging has become a standard feature on most social networks since ActivityPub was created, and its lack has inhibited Social Web adoption and public trust in the network.
ActivityPub is extensible, though. As part of our E2EE program, Mallory, Tom and I adapted the Messaging Layer Security (MLS) standard as an extension of ActivityPub to make the MLS over ActivityPub specification. The protocol fits the great MLS E2EE system onto the ActivityPub API and federation protocol.
But a protocol specification is not enough; it must be implemented. That’s why we’re so happy to announce that the Sovereign Tech Fund has commissioned work with the Social Web Foundation to coordinate two new interoperable implementations of MLS over ActivityPub. This investment by the Sovereign Tech Fund will help move the Fediverse towards more privacy for social web users, no matter what server they use.
We decided to partner with two different projects in order to make sure that we’re making an open standard that can work between implementations. With two implementers, we’ll need to communicate clearly about architectural and implementation decisions, and make sure that those decisions end up in the final version of the spec — not in a
TODOcomment in the source code of a single project.The first project is Emissary, the great social web application platform behind projects like Atlas and Bandwagon. Ben Pate, Emissary founder, says, “The Emissary Project is deeply committed to the Fediverse, where we are building a free and trustworthy Internet for all 8 billion humans. Delivering on that promise, Emissary is excited to team up with the Social Web Foundation to bring End-to-End-Encryption (E2EE) to the Fediverse. We are eternally grateful for the SWF’s leadership and support, without which this project could not have happened. Our work is already underway, and in 2026 anyone will be able to build E2EE applications on the Emissary platform.”
The second project is Bonfire. Bonfire is a modular framework for building federated apps, with its first app (Bonfire Social) offering a social networking experience enhanced with tools for privacy, trust, and collaboration (such as circles and boundaries).
The maintainers of Bonfire, Ivan Minutillo and Mayel de Borniol, said: “We think that end-to-end encryption should simply be the default for any private communication online. Working with the Social Web Foundation to bring E2EE to ActivityPub marks a crucial step in fostering privacy and trust, and especially in enabling the fediverse to become a safe space for activists and communities to organise, coordinate, and collaborate meaningfully. By making secure, user-friendly messaging a core part of the fediverse, we’re helping lay the groundwork for decentralised networks where people can go beyond talking in the mythical ‘global town square’ and actually organise and accomplish things together.”
This work will happen best if the Fediverse community tracks it closely. We’ll be making updates here on the SWF blog as progress continues. Developers and active users may also be interested in the ActivityPub E2EE Messaging Task Force at the W3C, where the specification is being developed into a report for the Social Web Community group. Finally, we’ll be using the #JustBetweenUs hashtag to share progress and ideas, so you can follow it to see what’s been happening.
-
@smallcircles @evanprodromou thanks!
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@julian @blag another option is muting the hashtag users. That should prevent notifications by those users. Unfortunately, you have to do it for each user, but if you use the same hashtag a lot, it should help.
-
@julian "I don't want notifications from particular users/domains/whatever" is a client issue.
-
@julian it might be possible but it prevents the server from tracking shares. I'm not going to implement that.
-
@evan@cosocial.ca I'm assuming @blag@typo.social still wants the boost but not to be notified about it?
It can be done if the recipient boostee isn't explicitly addressed, I think.
-
-
@blag sure; put hashtag NoTagsPub in your bio. Or, block tags.pub domain.
-
@evan Quick follow-up: is there any way to *not* have the boosts by these bots appear in notifications? I don't get a lot of boosts, so now they're getting in the way of 'genuine' human boosters...
-
I think there's an issue with the follows, at least with NodeBB. Followback didn't follow me back, and the relay won't establish 😅
It's probably just NodeBB being overly strict.
