@oblomov

the challenge is of course maintaining consistent identity and links between data over the "network". we can have identity be handled by a dedicated identity service that keeps track of resources and their current locations. a sort of "resource name system" rns counterpart to dns.

basically, links should stay valid even when browsing a local archive. and that local data gains a new id/alsoKnownAs when syndicated somewhere, and this gets registered in the rns backing data store.

@oblomov RNS servers are pluggable webfinger-esque servers that you can choose ahead of time, or even set up local resolvers for. imagine the id of an object gets passed to a local resolver which returns a file:/// uri to the location of that flat file object on your local system!

the challenge *here* is in setting up protocols for the rns resolver to communicate with the backing storage provider, and update rns records and/or the resource as needed. but this is where i'm stuck for now...

@trwnh if you want resource identifiers to remain valid, you have to decouple their URIs from any specific HTTP URL. You don't necessarily need a centralized system, though. The Portable Objects proposal https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md introduces a new URI that includes a “gateways” parameter that acts as location hint (multiple ones may be present) piggy-backing on DNS. But that's probably too big a change.

@oblomov that fep also brings in too many hardcoded assumptions that i want to avoid. i'm not a fan of the ap:// scheme or the .well-known endpoint or the use of did:key or even the key-based id assumption.

also you can keep HTTP(s) and still have it be better off / location-independent, if you assign HTTP(s) URIs against the identity service which acts as a proxy or resolver or gateway of its own. i could author LD documents with ids on trwnh.com but HTTP redirect to some other location...

@oblomov the only thing that makes me not wanna use http necessarily is that domain names can be reassigned so the authority component is not actually referring to you. it's referring to whoever is leasing or controlling the http server running on the ip address that the dns points to. this might be acceptable risk if you expect to own a domain name ~forever, but if you want better than that, you need a way to refer to individual entities as the "authority component". this means variable base.

@oblomov which i'm not above using! i know as2 recommends against variable references because "they might not be understood" but my general response to that is that if you are building what is effectively a web browser and you don't understand relative references then that is a skill issue

@trwnh I think that's part of the reason for the choice to go with a different protocol. I guess you could still have some kind of proxy service like there is for DOIs: you have an URI that is doi:prefix/suffix and then you have the HTTP proxy https://doi.org/prefix/suffix that redirects to the known HTTP URL of the document. We could have a similar scheme, but only as long as alternative resolution mechanisms are also provided.

@oblomov sure, DOI works as long as the DOI organization remains solvent and as long as there is a consistent database or lookup table for doi: -> https: or whatever.

i don't think the answer is "force everyone to obtain a DOI prefix before being able to publish on the web" though. i mean you could do that, but that in effect creates the "doi network" or "doi web" instead of the current "http(s) web" that we call "the Web" or "World Wide Web"

@trwnh sorry, I didn't meant it like that, I meant it in a way similar to how DOI works in the sense that the URI could exist without the doi.org domain, and the doi.org domain is essentially a proxy to resolve doi: URIs into HTTP URLs. I think the DID idea could work in a similar way, which is what I think the PLC DID from BS is intended to be, but I'd like it to be “decentralized first”, with the HTTP proxy only useful for the transition.

@trwnh this BTW is also why I'm not to fond the RNS idea (same issue as with DOI and PLC), unless again it's “distributed first” (hence the Kademlia idea). I'm not sure why you're opposed to keys as IDs, but whatever the choice is, it should still provide some key information simply to ensure validity.

@oblomov instead of inseparably coupling "key as id" i would prefer "key to prove controllership of an id" or "key to prove a message was not tampered with". you should be able to rotate keys without it destroying the entire identity graph. you should be able to use different keys for different purposes.

@trwnh OK, but the ID still needs some crytographic element to allow keys to prove controllership of id? Or how would a key be used to prove control?

@oblomov where RNS differs from PLC is that the server you ask to do the lookup is arbitrary, instead of being centralized and hardcoded. you get a ship of theseus issue ("it is whatever i say it is" / "depends on who you ask") but DNS largely has this issue as well and there are ways of mitigating it (authoritative servers, dnssec, ...)

also in RNS the scheme can be anything, not just https.

the "network" becomes whatever set of RNS servers agree on something. you could ask multiple, i guess?

@trwnh am I reading it correctly that it sounds a bit like how the eDonkey network works? You can connect to any server, and then search for resources (file hashes in that case) and you'll get a more or less uniform view of the network anyway, modulo massive netsplits?

@oblomov same way we do right now, link to the key within some identity document or "controller document". if the signature or challenge validates then a message came from the controller of that uri

identity documents could even be passed around p2p with an introducer model

failing that, keyservers could exist to let you lookup keys and link them back to other ids

@oblomov i dont know enough about edonkey or kademlia to answer further about those, but i will read into those and see if there are any similarities or lessons to be learned, thank you!