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

@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.

my kingdom for an actually functioning first-class social web (and not a bunch of silo clones co-opting the term)

@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

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

@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

@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