dansupWhat if
could be
@dansup.com
Bring your own domain to Loops, migrate your full account across Loops servers.
It's coming. Funded by @nlnet ❤️
Jörgi (chaos.social)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.
Jörgi (chaos.social) (@[email protected])
Attached: 1 image One of the killer features from @[email protected] is for me, that you can use your own domain. This means, as a band, author etc you can promote everywhere your handle with @name@my_own_domain.tld This is so perfect. This means your handle will still be correct if the instance you chose in the beginning is not alive anymore. I would love to see this feature in #Mastodon, #Pixelfed #loops #peertube and the #bridge @[email protected] @[email protected] 1/3
Holos Social@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
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
silverpill@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 control their identity keys).
The difference is subtle but it may matter a lot in some cases, such as when implementing E2EE.
@HolosSocial It should actually be relatively easy to implement client-side FEP-ef61 in Holos. If objects are served by the client, you don't need to implement client-to-server API (which is the most difficult part).