Discussion thread for FEP-7952: Roadmap for Actor and Object Portability, which is a normative FEP about how to create and handle Actor-rooted (as opposed to Server-rooted) ids for objects, based on self-hosted/independently-hosted, and long-lived (migration-aware, migration-suriving) Actor objects.
Sound complicated? It’s not, I just really wanted to fit all the spicy stuff into one long sentence. Give it a read!
we believe crypto is too much of a barrier to both implementation and use, and while it does solve some issues of threat model, it also introduces different issues - particularly of key management.
in the other thread we were bringing up the idea of multihoming which we believe is a better solution to avoid these caveats. after all, you can add as much crypto as you want but ultimately if you’re on a single instance, then that one instance has full control over everything you do.
but, we’re most concerned about actor-relative URIs…
these are fundamentally incompatible with existing systems, so whatever we do with them doesn’t really matter that much. regardless of them being “http-based”, the proposed fetching and dereferencing algorithm requires changes to existing systems, and they can’t use the URIs as-is anymore. as such, we strongly recommend against misusing/overloading the fragment identifier for this purpose, not in alignment with the relevant IETF RFCs. instead, consider doing something with pseudo-URIs (like webfinger’s acct) or composable URIs (like our proposed-elsewhere auth URI, which we still need to finish writing a proper document about…).
Well, if we dropped the static-server/codeberg-pages self-hosting option, and specified dynamic-server only, any “indirect URLs” (the ? kind) wouldn’t require changes to existing systems, would they? This is one of my problems with the current spec.
More generally, though, could you say more about fragment identifiers? The LinkedData world uses fragment identifiers a lot, and they’re pretty integral to the key handling and controller docs used by the W3C Data Integrity signing mechanism that many recent FEPs are based on…
No prob, the # based / static hosting part is a minor detail, i’ll move it to a future separate fep.
fragment identifiers for posts should probably reference data inside posts, just like it does for webpages. as per URI RFC, they’re supposed to follow the content-type, but here they’re following the context they’re being presented in.
(yes there is something to be said about how they interact badly with content negotiation, but we digress)
the W3C not following the RFCs wouldn’t surprise us tho…
Ok, fragment-based relative URLs removed. Now we’re just talking about plain 302 http redirects.
To be clear, this is not a W3C effort, just a FEP.
To be clear, I just meant that there is open-source tooling for this kinda stuff, and that using fragment identifiers within JSON-LD documents to navigate the graph was a pattern already baked in to lots of the LD tooling people use for AP already. I would be making different recommendations if i was optimizing for “where the W3C puck is headed,” as Wayne Gretzky would say.
For anyone else like me who struggled to find the full proposal text, here it is:
And the prime objective of the FEP is summed up pretty well here:
Unbundle the services and concerns of a typical instance
- Sign everything: Recognize client-side cryptographic signatures as proof of authorship (by implementing FEP-8b32: Object Integrity Proofs), in addition to the current practice of relying solely on the instance URL.
- B.Y.O. Actor ID: Using Object Integrity proofs enables Identity Hosting to be separated from the other instance concerns. 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.
- Separate Inbox/Outbox: (Optional) The previous steps enable message transfer and Inbox/Outbox hosting to be outsourced to separate service providers (the Actor profile links to these in the usual manner).
- Separate Object and Collection hosting: (Optional) Similarly, AP Objects and Collections can now be stored on domains separate from the Actor’s domain (since authorship and controller-ship can be proven cryptographically, in a domain-independent way). This enables the user to migrate storage service providers without having to change their Actor ID.
‘B.Y.O. Actor ID’ seems like a game-changer. If I understand it correctly, it’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 WordPress site 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. Right?
Sure, 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 
I can’t say I love this design choice:
it’s basically a one-file PR! I feel like codeberg shouldn’t suppress huge diffs for files introduced in that PR! anyone who knows whom to tag at Codeberg HQ feel free to do so, I’m too lazy to find the appropriate place to file a feature request
I love this 
(for context, here is draft-soni-auth-uri-00 - The auth URI scheme , tho we’ve taken to calling these “meta-URIs” instead of “composable URIs”…)