@hongminhee

> more modest goal: server-independent object identifiers that survive a server disappearing

does fedify support binding a base uri or fqdn to each individual actor? the most basic path to this starts with identifiers that outlive their servers, so instead of using the service's dns name, you can let actors bring their their own dns name.

you can imagine me not as mastodon.social/@trwnh but as mastodon.trwnh.com or trwnh.com/mastodon/ instead.

@trwnh@mastodon.social Fedify currently doesn't support binding a custom domain to individual actors—all actors share the server's domain. Honestly, I'm not sure how that would work in practice either; it would need some kind of indirection or delegation mechanism at the HTTP level, and I'm not aware of an established spec for it. Do you have something specific in mind, or perhaps an approach you've been thinking about?

@hongminhee you can use HTTP 3xx redirects but that's not strictly necessary because you can use DNS A/AAAA/CNAME as well (and have the HTTP server respond to those names in conjunction with TLS SNI)

the idea is that multiple server names can be responded to by the same Fedify software instance. in nginx it's doable with the http.server.server_name directive. https://nginx.org/en/docs/http/server_names.html

SNI: https://datatracker.ietf.org/doc/html/rfc6066#section-3

does fedify expect to run behind a reverse proxy? if so, it can route requests.

@trwnh@mastodon.social Fedify does run well behind a reverse proxy, and it doesn't actually require a fixed base URL—it can derive the base URL from the incoming request. Ghost takes advantage of exactly this to implement virtual hosting on top of Fedify, so in principle the kind of per-actor custom domain you're describing should already be achievable without changes to Fedify itself.

@hongminhee i think the only support from fedify needed is basically like an environment variable or property for wherever identifiers are assigned or dereferenced

so for example if the service is mastodon.social it would assign identifiers using trwnh.com/mastodon/ as a base uri

it only needs to know which uris are already used, so it doesn't assign an id that's already in use.

@trwnh@mastodon.social Actually, Fedify already supports this quite well. The actor dispatcher gives you full control over the actor's id—you can set it to any URL, including one on a custom domain. And since Fedify 1.4.0, there's a mapAlias() method that lets you handle WebFinger lookups for those custom URLs too. So running Fedify behind a reverse proxy that routes multiple hostnames, and assigning per-actor custom domain identifiers, should be achievable without any changes to Fedify itself.

@hongminhee so are object ids handled outside of fedify? the application written around fedify would have to keep track of which ids are already used/assigned?

@trwnh@mastodon.social Yes—Fedify is database-agnostic, so tracking which IDs are already in use is the application's responsibility. Fedify handles the federation layer, but the data model and storage are entirely up to the application built on top of it.

@hongminhee@hollo.social nice! though I'd encourage using a root identity that's an actual DID document (not just did:key), and points to the service(s) through which it works. Whether that's did:web/vh or did:plc or some other did method, the properties of a full DID document are very useful.

@thisismissem @hongminhee imo the value of a did document is overstated -- did can be a useful framework for how to interact with identities that *can* be operated on and *can* have keys and *can* link out to other services, but none of those things are actually required and a lot depends on the actual did method to fill in that framework. in the case of did:key, the "key" method is just a thin wrapper around a key (for when that key is the identity). this makes the key valid for *any* purpose.