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 (…)
(…) 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, not a full 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:
> 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).
@erlend Holy shit, that would be a big deal! Also, practically irrelevant to normies who will sign up at any new service outside their control but A BIG DEAL. @by_caballero
I’m looking at this and thinking it will be amazing for organizations and people of interest. This is a key step for them esp in terms of identity protection and verification.
@kiriappeee @fanden @erlend absolutely-- no one likes talking about boring small-business usecases as an adoption tailwind or business driver, but my intuition from working in the identity trenches is that making identity separate from service provision could help drive new kinds of adoption. @pfefferle may have insight here on different headless/whitelabel formfactors 
@fanden @erlend @by_caballero This seems technically easy to make available to people without a domain too: Hosting a service that provides user IDs should be dirt cheap and simple. Of course that's still not optimal, as the user is tied to that operator, but at least it's independent of the actual service provider (which is more likely to encounter problems (e.g.cost, complexity) or cause problems (e.g. moderation, federation) that might prompt you to change). The UX side is likely harder, ideally this would be a default part of account creation.
@erlend exquisitely on point. This seems great
I'm currently convinced the only way to solve this is with a mapping table, so that /item/something on my system can be found at /object/something on your system (or whatever). We also have 30-40 different object types that most other projects haven't even considered. This is the only way to make them portable. Just store the object in the mapping table instead of the local path mapping for that object. Done. The portable url could just be $apgateway/$did/$resource-id. If my software supports that kind of object I'll redirect to where we store that kind of object. If it doesn't, I'll just return the portable object.
Cheers.
@mikedev it's not so either/or, actually-- it's just a slightly different (hopefully complementary) arrangement of many of the same parts. "Every project has completely different URL paths and object-type mappings" is status quo, and this is a way that you can move-or-mirror *just the Actor object* to a server that does the generic mappings for any consumer, alleviating the chicken/egg problem of implementations not wanting to break 20 things at once to enable portability.
@mikedev the biggest problem with doing DID URLs (whether the standard form defined in the DID spec or a custom form specific to AP) is that consuming implementations need to implement that syntax to even see the "fancy Actor" as an Actor. this way, you could "wrap" a Nomadic Actor in a backwards-compatibility Actor, if you had a tiny implementation that speaks multiple forms of Nomad and translates those routes to something today's "stock Mastodon" can parse...i.e.`copiedTo`, not `movedTo`
Is the idea that "me@myname.com" could be hosted on a server called "bigsocial.com" then move to "otherplace.com" and that just sort of happens automatically? As far as remote followers are concerned nothing happened?
@smallsees @erlend @dmitri Ideally yes, target state is "status quo", but it's a little unknown how many of today's implementations accidentally hard-code assumptions to the contrary. The reason we worked on a Roadmap first and broke out just the Actor-independent URL part second is to make *explicit* and *testable* behavior that should already be possible in ActivityPub's specification of the Actor Object... but maybe not always in practice today.
@smallsees @erlend @dmitri (also the spec indirectly explains how to build a microservice that could run for $1/mo on a little heroku-style platform you could point `myname.com` at-- we can hopefully provide a prototype soon and, if people demand it, add more explicit detail about how to build one's own or adapt the idea to other form factors?)
@smallsees @erlend @dmitri The harder adoption question is finding server implementations that want to give their users this self-managed and more-portable option. It's kinda "power-user only" until there are turnkey services like what bluesky built with namecheap for people to "one click set up" a bsky "handle" (technically, a DID with very similar properties and syntax under the hood if you check it out on github!)
https://bsky.social/about/blog/7-05-2023-namecheap
@by_caballero @smallsees @dmitri full disclosure: the Weird team is building such a turnkey service:
@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)