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@mastodon.social and @dmitri@social.coop
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 on a personal website), which in turn enables service providers to offer their users a “BYO (Bring Your Own) domain name” feature.
That’s really all I ever needed from the notion of a ‘single-user instance’. All I want to manage on my own is my identity; I don’t want to take on the full burden of managing a whole AP server.
In this paradigm, someone’s tiny personal website could also be their Actor-ID Provider, and nothing more. That ID could in turn be used to as a (reasonably nomadic) account on any FEP-7952 compatible instance.
From @by_caballero@mastodon.social:
the idea is to detach the Actor object (which could be operated by a microserver that consumes almost zero resources, and basically just operates a big redirect table like a link-shortener) from the Service Provider, to be a little more like email (in the use case where you point a domain that you own and configure at protonmail or mailgun or some other provider) or SMS service (in that regulation enables you to keep your number when you switch phone co’s).
We will prototype the micro-Actor in the coming months, but we have no idea how long it would take for implementations like WordPress or forks of Mastodon/Misskey/Pleroma to offer support for this kind of externalized/self-managed Actor. We are hoping existing servers will find it interesting to offer a “service-provider mode” for the nomadic/domain-owning user class, for many reasons. In the meantime, we might also prototype a Fedify-powered server that only allows external Actors to create accounts.
Mastodon: https://writing.exchange/@erlend/112684879834557152
From my understanding of this it means client side signing of actions would be supported?
It seems that accounts (actor objects) can now just be a static file hosted anywhere which lowers the bar for entry of self hosting. Id love to see something about supporting .onion addresses when looking up this file would allow self hosted anonymous identity while not requiring support for a whole instance as a hidden service.
@muntedcrocodile @erlend_sh Technically, in the current draft, it can’t actually be a *static* file, you still need nginx/caddy/etc to redirect the permanent “indirect urls” (
[https://myownserver.xyz/bumble?service=storage?object=123](https://myownserver.xyz/bumble?service=storage?object=123)) to the current/mutable “direct urls” ([https://serviceprovider.com/user/bumblefudge/AP/posts/123](https://serviceprovider.com/user/bumblefudge/AP/posts/123`)).@muntedcrocodile @erlend_sh As for .onion addresses for the Actor object/microservice, that’s a bigger ask of implementers, and even if it were implemented, I’m sure more legally-cautious servers would want to disable that feature… but i’m sure someone would make
[http://anonserver.xyz/](http://anonserver.xyz/`) once people start using this, and i’m sure they would accept payment in Monero and ZCash 😉But hey, it’s an interesting backlog ticket to consider, I appreciate the suggestion!