You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current specification outlines how to use a domain name for portability by backing up a server and restoring at another server. This isn't well implemented except for the almost trivial case of using the same fediverse software and a custom backup format like a database dump or tarball.
It would be interesting to delve into this further. Registering a domain (yourname.example) or using a subdomain (social.yourname.example) are great ways to have an identity that you own (more or less) that you can transfer to other AP implementations and services. Because AP uses HTTP for data retrieval and data delivery, it's relatively transparent to other instances on the fediverse if you move.
Any discussion of data portability on the fediverse needs to cover this topic.
The text was updated successfully, but these errors were encountered:
A variation of this came up during FediForum today, related to #10 as well. It could be useful to document the best solution for changing a domain name for an existing server so that this is as smooth as possible for people.
I haven't implemented this yet, but I'm thinking that if someone renames their username or domain name, the server should respond to WebFinger and ActivityPub profiles for both old and new handles (even though they are internally the same account). Then send out "Move" activities to followers.
Happy to hear if anyone has other suggestions or if I'm overthinking this.
Partial/possible answer to OP's question: FEP-e3e9 (assumes a microservice running behind that BYODomain, prototype forthcoming)
I'm also working on a draft FEP (shipping any day now!) that is tangentially related to Manton's question, as the exact semantics of pointers and tombstones and move Announces keeps coming up in LOLA discussions and Lisa would like it addressed somewhere else she can point to from LOLA 😅
The current specification outlines how to use a domain name for portability by backing up a server and restoring at another server. This isn't well implemented except for the almost trivial case of using the same fediverse software and a custom backup format like a database dump or tarball.
It would be interesting to delve into this further. Registering a domain (yourname.example) or using a subdomain (social.yourname.example) are great ways to have an identity that you own (more or less) that you can transfer to other AP implementations and services. Because AP uses HTTP for data retrieval and data delivery, it's relatively transparent to other instances on the fediverse if you move.
Any discussion of data portability on the fediverse needs to cover this topic.
The text was updated successfully, but these errors were encountered: