I am finally taking the “WIP” caveat off a use-cases/requirements document I’ve been working on for months. The basic thought experiment is: what if ids didn’t contain their originating or current hosting servers? This is kind of a “back-burner” research issue for the portability task force, but also relevant to people working on federated/federation-aware moderation, and interop with other decentralized social platforms.
1 Like
Well then it probably wouldn’t be HTTPS. If it was, the best you could do is punt ID generation and resolution off to a nameserver of some sort.
I’m not sure I understand-- I know you need an HTTPS server to be the authority of a URL to resolve it, but what I’m thought-experimenting is, what if ids weren’t URLs in the first place? How else could they be made verifiable and resolvable, so that moving servers were a detail that doesn’t require breaking and reconsistituting the whole graph?
They’ve gotta be rooted in something. If not DNS and HTTPS, then probably look toward DIDs.
1 Like
This topic is specified in discussionsTo field of FEP-cd47, so I’m moving it to Fediverse Enhancement Proposals category.
1 Like
Draft FEP for one server-independent scheme opened as a draft PR:
Well, DIDs are a big design space… maybe we don’t need the entire DID toolkit here, or the complexity of DID resolution. The [draft] PR above proposes a much more lightweight approach, turning Actor objects into “controller documents”, which are like, DIDs resolved via classic HTTP with no fancy trust models 
could we have multiple IDs, and make them discoverable?
1 Like
This is a great question-- and I’m not sure how to answer it. Do you mean:
A.) Could one end-user maintain multiple ActorIDs in different places for more discoverability?
(I wanna say, yes, this would allow multiple actorIDs to maybe share one “account” with their inbox/outbox and storage providers, but I’d have to think through corner cases-- probably worth doing so after the PR is merged, at least here!)
or do you mean
B.) Does the coexistence of the direct and indirect URLs for the same effective Actor impede discoverability?
(I think the trick here is that the indirect one “resolves to” and is functionally equivalent to the direct one, but the direct one changes each move. So you can use the indirect one as the “canonical form” but then you’re effectively limiting that actor’s portability to implementations that support this “external actorId” config. Or you can use the direct one as the “canonical id” and you’re effectively stuck in status quo, needing redirects, not surviving migrations off dead servers, etc etc)
I would also point out that Dima is hard at work removing things from this FEP, and I’m trying to catch them and drop them here as a to-do list, to at least discuss them or maybe put them in some other FEP/CG-report/document if there is demand/utility in doing so. For example, in the most recent house-cleaning commit, Dima took these out of the kitchen sink:
5. Current Moderation tooling is not affected normatively by any changes
proposed here, but may benefit additional affordances such as object address
permanence across migrations; see [Appendix A](#appendix-a-current-portability-challenges).
6. Community discovery -- [FEP-1b12]https://codeberg.org/fediverse/fep/src/branch/main/fep/1b12/fep-1b12.md)
can be used to model a given server's Local Feed rather its behavior being
defined by (and closely coupled to) implementation-specific logic.
7. Implementing C2S protocol allows for fully "headless" instances -- unbundling
the front end client from the backend and lowering the implementation burden
for more clients to connect to each backend.
These are kind of “additional implementation changes” (probably each requiring 1 or more future FEPs…) that could be combined with support for Actor-relative URLs & separately-hosted Actor objects, not really necessary or germane to the changes proposed but also kind of additional justification for the leap.
#6, I think, speaks to the discovery issue (B), in that today’s implementations (there are many!) that have some form of “Local Timeline” or “Home-server only” mode could seamlessly retain that end-user experience as some of its users switch to an externally-hosted and actor-relative-addressed Actor object, by upgrading their home-server timeline to a FEP-1b12 Group (and figuring out separately how to gate access to their local group-- realistically, we’re talking about externally-hosted Actors that still get their inbox/outbox and storage services from the server hosting the group, so all of this is ideally invisible to the entire fediverse, in- and out-group alike). This takes a cool UX feature out of implementation-specific logic and makes it more interoperable by encoding it at “the Protocol level” (if you can call an extension protocol); implementations that never implemented FEP-1b12 would continue blissfully unaware of both implementation-specific groups and protocolized groups, but at least FEP-1b12 implementations crawling or assessing external users would see it among other memberships
1 Like
Oh, and one last thing-- actor-relative URLs could, to smooth over interop/graph-reconstructibility concerns between FEP-7952-aware and -unaware implementations, use alsoKnownAs to point to their direct URLs (contingent on today’s service-provider relationships and subscription payments, hehe). Or, maybe @codenamedmitri already considered this possibility and rejected it for good reasons he hasn’t told me, just spitballing here.
could you just bolt extra IDs to an object and and if the objects those extra IDs resolve to also point to each other they can be considered interchangeable, including for future removal of extra IDs?
e.g.
you fetch https://foo.example/@UserA and find it contains extra IDs: https://bar.example/@UserA
you fetch https://bar.example/@UserA and find it contains extra IDs: https://foo.example/@UserA
so now you know these are fully, mutually interchangeable and should be treated as one.
later, some time in the future, you find that https://foo.example/@UserA no longer resolves (404) but you can fetch https://bar.example/@UserA and it now contains extra IDs: https://baz.example/@UserA
you fetch https://baz.example/@UserA and find it does contain extra IDs: https://bar.example/@UserA
so now you know to drop https://foo.example/@UserA because it’s no longer relevant and to add https://baz.example/@UserA
1 Like
You have just eloquently described what I would call “passive support for actor-relative URLs”, meaning that if implementers of this FEP did the “two IDs pointing to each other as alsoKnownAs” part, and other servers were aware of this config and treating them as contingent synonyms, backwards compatibility is solved smoothly. Implementations not interested in enabling their own users to externally-host their Actor objects but wanting to preserve status-quo interoperability with implementations doing so could just implement the synonym-awareness you describe in your comment and we’re all good! For all I know, some already do something real similar for handling multi-account users and “Move Actor”-style migrations, so they might not need to lift a finger. (This might make a good Appendix, actually…)
One caveat/corner-case tho: I’m still trying to figure out the #/? optionality for statically-hosted Actor objects, which might be an additional ask for passive interop as currently specified…
1 Like
we would propose going slightly further: this should also apply to posts and other objects, and the timelines should be merged and deduplicated on a best-effort basis.
if https://yourinstance.example/ blocks https://foo.example/ then it should still show https://bar.example/@UserA and the appropriate posts.
however, this is what we would call a “multihoming” proposal. the posts have multiple homes, this doesn’t detach the posts from the concept of an instance. this has some benefits beyond mere compatibility with existing instances. (as a bonus, it also deprecates “move actor”.)
what do you mean about #/? ?
Oh, sorry, I kinda messed up the organization of this thread about an information FEP by making it the “discussionsTo” link to a second, normative FEP. the question of # and ? is one of the few remaining questions I’d like to resolve before marking the latter as ready to merge.
1 Like
So, what @bumblefudge is referring to, is the in-progress FEP over at #334 - WIP: FEP-7952: Roadmap for Actor and Object Portability - fediverse/fep - Codeberg.org, which defines the term Actor-Relative URL.
And it has two types of relative URLs – 1) for Actors hosted on dynamic servers (that can process query params), that looks like https://alice.example/actor?service=storage&relativeRef=/objects/123.
So that’s the ? part.
And the second type of actor-relative URLs is 2) for Actor objects hosted as static files (like on Codeberg pages, personal websites, etc), that looks like https://alice.example/actor#service=storage&relativeRef=/objects/123.
That’s the # part.
I linked it with markdown!
(is there a topic for that or should we discuss it here? we would strongly recommend against overloading fragment identifiers tho, maybe look at alternatives like webfinger acct: URI or our proposed-elsewhere auth: URI stuff.)
Good point, probably better here