@trwnh IMO the Nostr approach of keeping keys in the client and having relays be more simple is good. Key management and multi devicw identity is a major PITA, but there's a lot of known approaches that can be taken.

if you're willing to accept DNS in all its faults and limitations, then we could devise a system where every social agent has its own FQDN. heck, that's basically bluesky's facade. the rest of the system mostly falls into place after that -- just make all links relative to the social agent's FQDN, and keep track of when the FQDN changes. https: can do this with some maintenance (rewriting old links), did:whatever can do it more dynamically with service + relativeRef

honestly you could just maintain a petname / contact-or-address-book type thing using redirects because HTTP lets you do that; you don't need to pre-canonicalize all your links

say my http server redirects /proxy-to-my-friend-bob/foo -> bob.example/foo

@mauve it's already pretty widely accepted on the web that DNS mostly works, so we can also establish identity that way (say we agreed to give everyone a FQDN so they can do TLS, or we adopted the CID spec https://www.w3.org/TR/cid-1.0/ so that they could use some URI or DID). aside from that we could also distribute bearer tokens out-of-band, but we have better options

@trwnh@mastodon.social Build it

@natalie that's the aim and intent. the hard part is getting everyone to agree on a federated identity system (and to a lesser extent, a standard API for publishing web resources using that identity)

@trwnh@mastodon.social everyone agreeing is an unattainable goal

@natalie to some extent we all converged on using http(s). i think we can do something similar again, or at least i would hope so

i think you could get pretty far with existing technologies like webdav or solid, but i'd really want to see a better way to manage "name to thing" resolution that isn't literally writing an nginx config with location blocks

@trwnh@mastodon.social converging is much different than "getting everyone to agree" tho

@natalie admittedly that was poor phrasing, depending on the definitions of "everyone" and "agree"

in a practical sense i think the closest current option is to assign everyone an FQDN, since that requires the least changes

@natalie i'm still trying to come up with a better answer but that's the societal baseline at least

@trwnh@mastodon.social bsky wins again

@natalie yeah i don’t fully agree with all their decisions but i understand why they made them

virtual host support would probably be quite feasible to retrofit onto existing fedi codebases but i doubt it’ll get done anytime soon