No point in moving your identity if your content server shuts down unexpectedly. I'm actually working on nomadic content over ActivityPub right this moment. Centralising it destroys everything I've done with nomadic identity over the last dozen years. We have clonable identities (identity and content) right now with live synchronisation. If your server cert expires or goes offline right this second, go to your clone and nothing has changed. You have all your content, friends, and settings. Everything. I'm not giving this up and neither should you. Content-addressable mechanisms don't work because the url changes if you edit the object. Every project has completely different URL paths and object-type mappings.
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.
@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@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 😏
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
(…) 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.
> 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 😃