Recent searches
Search options
I think this is the most important (WIP) Fediverse Enhancement Proposal of this year for the #ActivityPub protocol:
FEP-7952: Roadmap for Actor and Object Portability — by @by_caballero and @dmitri
It ties a lot of elementary building blocks for #nomadicidentity neatly together, most succinctly summed up by one particularly magic feature:
Bring-your-own Actor ID! 
Actor profiles can now be hosted separately from the instance (including as a static JSON object (…)
@erlend @by_caballero @dmitri Woah. This was the one good thing about the BlueSky design. 
So the idea is to move "me" to my own server, and my name would be "crell@crellshouse.com", but accessed via phpc.social?
@Crell sounds right, yup. What your ‘own server’ is exists on a spectrum of course, depending on how much upkeep/security you wanna be responsible for yourself.
@erlend What does this do to blocks? Are blocks of the identity server or the message server? How about migrations?
@Crell not sure, you’d have to ask the authors of the FEP.
@erlend @Crell Great questions-- honestly, as-is, "blocks" aren't a feature of ActivityPub or even standardized enough for there to be one spec I could go update, extend or replace-- it's all pretty ad-hoc at the moment, sadly.
In theory, however, a server would have more options open to them: if they want to apply a `phpc.social` block against anyone with `phpc.social` in their Actor object, they could! And a block on `crell@crellshouse.com` would survive you moving to `freespeech.social` 
@erlend @Crell (currently, tho, most implementations apply blocks by looking for `phpc.social` in the `Actor`'s URL rather than in the whole Actor object, since today the latter would just be a more inefficient way of doing the same thing-- it's another adoption lift/backlog item for people working on moderation tooling)