If you want to, I can send you my Dockerfile adding pdsadmin to the pds docker image (yeah because it’s not included by default) and the compose file I use to run it all.
October 17, 2025 at 10:49 AM
If you want to, I can send you my Dockerfile adding pdsadmin to the pds docker image (yeah because it’s not included by default) and the compose file I use to run it all.
You can find this talk (and all the conference talks) on PeerTube (link in this post preview), directly on the official conference streaming platform (media.ccc.de/b/conference...) or on youtube (www.youtube.com/playlist?lis...) :)
E2EE Direct Messaging in Bluesky with Matrix
https://media.ccc.de/v/matrix-conf-2025-82204-e2ee-direct-messaging-in-bluesky-with-matrix See a demo of E2EE encrypted DMs in Bluesky powered by Matrix. We will highlight the simple user experienc...
video.innovationhub-act.org
October 16, 2025 at 8:07 PM
You can find this talk (and all the conference talks) on PeerTube (link in this post preview), directly on the official conference streaming platform (media.ccc.de/b/conference...) or on youtube (www.youtube.com/playlist?lis...) :)
Yeah I feel you, there used to be a time (not a long time ago I have to admit) where that was one of the big issues with Matrix but today everything should be working smoothly if you use the latest synapse and element versions.
A lot of work was done to avoid these messages.
A lot of work was done to avoid these messages.
October 14, 2025 at 1:12 PM
Yeah I feel you, there used to be a time (not a long time ago I have to admit) where that was one of the big issues with Matrix but today everything should be working smoothly if you use the latest synapse and element versions.
A lot of work was done to avoid these messages.
A lot of work was done to avoid these messages.
There are already several MSCs tackling account decentralization... I’m unsure how the Matrix community would feel about tying its identity to did:plc, and even less about relying on the AT Protocol, even if it enabled firehose-based matrix id keys revocation.
Still, a fun thought experiment.
Still, a fun thought experiment.
October 13, 2025 at 3:44 PM
There are already several MSCs tackling account decentralization... I’m unsure how the Matrix community would feel about tying its identity to did:plc, and even less about relying on the AT Protocol, even if it enabled firehose-based matrix id keys revocation.
Still, a fun thought experiment.
Still, a fun thought experiment.
Sure, that's why what I'm talking about is a hypothetical version of the matrix protocol based on several fundamental changes...
In the model I'm talking about the DID would be the source of identity and the matrix id key only a mean to achieve routing. That's pretty far from where matrix is now.
In the model I'm talking about the DID would be the source of identity and the matrix id key only a mean to achieve routing. That's pretty far from where matrix is now.
October 13, 2025 at 3:38 PM
Sure, that's why what I'm talking about is a hypothetical version of the matrix protocol based on several fundamental changes...
In the model I'm talking about the DID would be the source of identity and the matrix id key only a mean to achieve routing. That's pretty far from where matrix is now.
In the model I'm talking about the DID would be the source of identity and the matrix id key only a mean to achieve routing. That's pretty far from where matrix is now.
But yeah I think I get what you mean.
MSC4243 alone isn’t sufficient to allow Matrix-AT compatibility: the Matrix user ID should serve as a routing identifier and the DIDs should be the stable anchor of identity.
While a Matrix ID or homeserver may change, events remains bound to at least one DID.
MSC4243 alone isn’t sufficient to allow Matrix-AT compatibility: the Matrix user ID should serve as a routing identifier and the DIDs should be the stable anchor of identity.
While a Matrix ID or homeserver may change, events remains bound to at least one DID.
October 13, 2025 at 2:49 PM
But yeah I think I get what you mean.
MSC4243 alone isn’t sufficient to allow Matrix-AT compatibility: the Matrix user ID should serve as a routing identifier and the DIDs should be the stable anchor of identity.
While a Matrix ID or homeserver may change, events remains bound to at least one DID.
MSC4243 alone isn’t sufficient to allow Matrix-AT compatibility: the Matrix user ID should serve as a routing identifier and the DIDs should be the stable anchor of identity.
While a Matrix ID or homeserver may change, events remains bound to at least one DID.
You could design a protocol without homeservers or PDSs, but you’d lose message remote recovery and have to expose your IP for direct delivery.
Most users prefer having intermediaries for reliability and simplicity over pure P2P models.
Most users prefer having intermediaries for reliability and simplicity over pure P2P models.
October 13, 2025 at 2:22 PM
You could design a protocol without homeservers or PDSs, but you’d lose message remote recovery and have to expose your IP for direct delivery.
Most users prefer having intermediaries for reliability and simplicity over pure P2P models.
Most users prefer having intermediaries for reliability and simplicity over pure P2P models.
Even with the AT Protocol intermediaries persist: PDS, relays, AppViews… Can you use BlueSky or Leaflet without a PDS?
As you said, the goal is to keep identity user-controlled and revocable.
With MSC4243, homeservers act as routing proxies, not identity authorities.
As you said, the goal is to keep identity user-controlled and revocable.
With MSC4243, homeservers act as routing proxies, not identity authorities.
October 13, 2025 at 2:21 PM
Even with the AT Protocol intermediaries persist: PDS, relays, AppViews… Can you use BlueSky or Leaflet without a PDS?
As you said, the goal is to keep identity user-controlled and revocable.
With MSC4243, homeservers act as routing proxies, not identity authorities.
As you said, the goal is to keep identity user-controlled and revocable.
With MSC4243, homeservers act as routing proxies, not identity authorities.
That’s why MSC4243 is well designed: it replaces homeserver-signed events with client-signed events. The user ID acts as the public key, while the private key remains with the client and is not shared with the homeserver.
October 13, 2025 at 12:46 PM
That’s why MSC4243 is well designed: it replaces homeserver-signed events with client-signed events. The user ID acts as the public key, while the private key remains with the client and is not shared with the homeserver.
If Bob initiates the conversation, the AT handle resolves as for Alice.
For cryptographic certainty (using the still-unstable MSC 4243), their account IDs include a public key and domain, and each event is signed with their private ed25519 key, thus allowing cryptographic certainty.
For cryptographic certainty (using the still-unstable MSC 4243), their account IDs include a public key and domain, and each event is signed with their private ed25519 key, thus allowing cryptographic certainty.
October 13, 2025 at 12:41 PM
If Bob initiates the conversation, the AT handle resolves as for Alice.
For cryptographic certainty (using the still-unstable MSC 4243), their account IDs include a public key and domain, and each event is signed with their private ed25519 key, thus allowing cryptographic certainty.
For cryptographic certainty (using the still-unstable MSC 4243), their account IDs include a public key and domain, and each event is signed with their private ed25519 key, thus allowing cryptographic certainty.
Linearized Matrix differs from standard Matrix by relying on a single “hub” server for message delivery, much like Bluesky DMs.
It doesn’t cover AT Protocol handle resolution though; that’s a new idea that needs to be explored further to evaluate its viability.
It doesn’t cover AT Protocol handle resolution though; that’s a new idea that needs to be explored further to evaluate its viability.
October 13, 2025 at 8:12 AM
Linearized Matrix differs from standard Matrix by relying on a single “hub” server for message delivery, much like Bluesky DMs.
It doesn’t cover AT Protocol handle resolution though; that’s a new idea that needs to be explored further to evaluate its viability.
It doesn’t cover AT Protocol handle resolution though; that’s a new idea that needs to be explored further to evaluate its viability.
Of course, expecting Bluesky to adopt the full Matrix protocol specification from day one would be unrealistic. That’s why some folks at the Matrix Foundation proposed a simplified, partially compatible variant called linearized matrix for the IETF MIMI project:
turt2live.github.io/ietf-mimi-li...
turt2live.github.io/ietf-mimi-li...
Linearized Matrix
This document specifies Linearized Matrix (LM). LM is an extensible protocol for interoperability
between messaging providers, using Matrix's ( matrix.org ) decentralized room
model. LM simplifies the...
turt2live.github.io
October 13, 2025 at 8:04 AM
Of course, expecting Bluesky to adopt the full Matrix protocol specification from day one would be unrealistic. That’s why some folks at the Matrix Foundation proposed a simplified, partially compatible variant called linearized matrix for the IETF MIMI project:
turt2live.github.io/ietf-mimi-li...
turt2live.github.io/ietf-mimi-li...
Bob’s homeserver cached Alice’s DID→Matrix ID mapping upon initial resolution. Clients can either rely on the homeserver’s cached mapping when displaying the sender handle, or independently re-resolve the DID to verify the current Matrix homeserver and ensure the mapping remains valid.
October 13, 2025 at 7:59 AM
Bob’s homeserver cached Alice’s DID→Matrix ID mapping upon initial resolution. Clients can either rely on the homeserver’s cached mapping when displaying the sender handle, or independently re-resolve the DID to verify the current Matrix homeserver and ensure the mapping remains valid.
But instead of an app.matrix.actor.mxid, we could just in fact add the mxid to the DID document… I didn’t think a lot about that solution even if it crossed my mind, I’ll try to think about it, thanks a lot!
October 13, 2025 at 12:56 AM
But instead of an app.matrix.actor.mxid, we could just in fact add the mxid to the DID document… I didn’t think a lot about that solution even if it crossed my mind, I’ll try to think about it, thanks a lot!
The main reason was revocability.
By hosting a collection app.matrix.actor.revoked in the PDS, homeservers can subscribe to its firehose to be notified if a user’s DID-to-Matrix mapping changes, ensuring cached homeserver info stays up to date.
By hosting a collection app.matrix.actor.revoked in the PDS, homeservers can subscribe to its firehose to be notified if a user’s DID-to-Matrix mapping changes, ensuring cached homeserver info stays up to date.
October 13, 2025 at 12:54 AM
The main reason was revocability.
By hosting a collection app.matrix.actor.revoked in the PDS, homeservers can subscribe to its firehose to be notified if a user’s DID-to-Matrix mapping changes, ensuring cached homeserver info stays up to date.
By hosting a collection app.matrix.actor.revoked in the PDS, homeservers can subscribe to its firehose to be notified if a user’s DID-to-Matrix mapping changes, ensuring cached homeserver info stays up to date.
I did this diagram so that one can understand the idea, I'm sorry if it's not up to tech standards, I'm not very used to it...
If you have recommendations or questions I would be glad to answer!
If you have recommendations or questions I would be glad to answer!
October 12, 2025 at 7:22 PM
I did this diagram so that one can understand the idea, I'm sorry if it's not up to tech standards, I'm not very used to it...
If you have recommendations or questions I would be glad to answer!
If you have recommendations or questions I would be glad to answer!
If this unstable MSC (github.com/matrix-org/m...) is one day implemented. We could identify users via ed25519 keys, and PDS could simply publish a mapping to the state key, allowing an homeserver to send and receive messages for the user.
MSC4243: User ID localparts as Account Keys by kegsay · Pull Request #4243 · matrix-org/matrix-spec-proposals
Rendered
github.com
October 12, 2025 at 4:31 PM
If this unstable MSC (github.com/matrix-org/m...) is one day implemented. We could identify users via ed25519 keys, and PDS could simply publish a mapping to the state key, allowing an homeserver to send and receive messages for the user.
Knowing someone’s handle allow to resolve the user DID. You can set up handles by DNS as you mentioned but also by using the /.well-know/ method (please refer to the official documentation).
Homeservers could act as PDS but they could also allow users with their own PDS to use matrix.
Homeservers could act as PDS but they could also allow users with their own PDS to use matrix.
October 12, 2025 at 4:07 PM
Knowing someone’s handle allow to resolve the user DID. You can set up handles by DNS as you mentioned but also by using the /.well-know/ method (please refer to the official documentation).
Homeservers could act as PDS but they could also allow users with their own PDS to use matrix.
Homeservers could act as PDS but they could also allow users with their own PDS to use matrix.
I think I gave answer to your thinking in the replies of my post. I think AtProto could at the opposite allow decentralized accounts in matrix.
atproto.com/specs/handle
atproto.com/specs/handle
Handle - AT Protocol
A specification for human-friendly account identifiers.
atproto.com
October 12, 2025 at 4:07 PM
I think I gave answer to your thinking in the replies of my post. I think AtProto could at the opposite allow decentralized accounts in matrix.
atproto.com/specs/handle
atproto.com/specs/handle
Well it was working a few hours ago :(
October 12, 2025 at 12:33 PM
Well it was working a few hours ago :(