Home | Notifications | New Note | Local | Federated | Search | Logout
Note Detail
Reply to @dansup@mastodon.social
Jörgi (chaos.social)@joergi@chaos.social (2026-06-07 04:21:31)
@dansup
Great you have that planned too, exactly what I wrote here https://chaos.social/@joergi/116693955340766744
🤝
I really hope that comes not only to loops, but also to #pixelfed, #mastodon and the #fedibridge.
If you need inspiration, @HolosSocial has already implemented this, it works perfectly.
---Reply---
Holos Social@HolosSocial@mastodon.social (2026-06-07 04:40:33)
@joergi
The custom domain and full account migration feature already works on Holos Social today. On Holos the keys are held by the device, so migration works even if a relay is down: nothing is lost. This is a different approach from a shared server that holds the keys for its users, and it is probably closer to the work of @silverpill on portable identity.
https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md
@dansup
Reply
---Replies---
silverpill@silverpill@mitra.social (2026-06-07 06:32:23)
@HolosSocial @joergi @dansup Holos with custom domains provides similar benefits but there is an important difference. In classic ActivityPub, identity is tied to a domain name. Keys are supposed to be ephemeral, and HTTP signatures are merely an optimization that servers use to avoid fetching every received activity by its id. In FEP-ef61, identity is tied to a DID, while domains are supposed to be ephemeral. If did:key is used, that key becomes a permanent part of every id.
If you don't use FEP-ef61, a server can perform a MITM attack by serving a different actor document or a different key. FEP-ef61 protects against this (under the assumption that users controls their identity keys).
The difference is subtle but it may matter a lot in some cases, such as when implementing E2EE.