@jens if you’d like to pick up at some future point i would be interested in hearing more — the tradeoff with key-based identity as i understand it is that key rotation invalidates old signatures. which is afaik why zot uses a random guid and then signs that guid (iirc). sounds a lot like that tuple you were talking about, but it’s been a while since i read the zot protocol docs.

if you have any other resources you can point to in the meantime (heh), i’d appreciate those

@jens really my concern here is that losing a key means losing all your resources and breaking all existing links. i don’t think most people want cryptographic guarantees when alternative means of establishing identity will do fine. for all its problems, people generally trust DNS. can we extend that trust to resources? arbitrary name-to-thing lookup where you can register not just IP addresses but also arbitrary resources? like doi: or isbn: but for anything, by any host

@jens hopefully you at least see why i’m not fully giving up on the RNS idea lol

@jens but anyway you dont have to answer that right away. have a pleasant night!

or actually… maybe //host/thing is good enough if you trust the host to not lie about its own resources?

i wonder if it makes more sense to build RNS as an extension of DNS or if it should be a reimplementation of the same principles but

ah shit i’m reinventing XRI aren’t i

as i’ve read it, the w3c tag opposed xri on the grounds that it was unnecessary when http: could do most of what anyone cared to do at the time

i would personally counter that the w3c tag was being extremely short-sighted for what seems to me like mostly political reasons

it’s on one hand“http supremacist” and on the other hand failing to acknowledge the shortcomings of http: as a uri scheme. the very existence of https: as a separate scheme proves this, while failing to address shortcomings.

like, damn, we really fucked up pretty badly here. even the semwebby people now have to deal with some concepts being identified as http: and some as https: — mostly by how old the vocabulary is. lol, lmao

idk about y’all but i don’t feel like making a bunch of owl:sameAs, owl:equivalentClass, owl:equivalentProperty statements just to deal with a single letter being inserted

@trwnh One early source of confusion for me - and I think some others, too - was the distinction between "a URL that's meant to be dereferenced" and "a URL that's being used as a unique identifier, in a JSON-LD / RDF type way".

I can see the merit in allowing anyone to define brand new, guaranteed unique identifiers based on their control of a domain name - but allowing that namespace to overlap with actual dereferencable URLs was maybe not so clever, in my view.

@FenTiger it’s clever only as long as there is exactly one canonical protocol that everyone uses forever

@FenTiger also as long as you never reassign a domain name to someone else

@trwnh ...or stop paying your bill. I've seen things in the JSON-LD @.context that resolved to porn sites.

in some ways it is a clever idea to have things be identified in a way such that you can easily fetch more information about them. indeed, the web works on this principle. but it’s clever only as long as there is exactly one canonical protocol that everyone uses forever, and our dependence on dns also means that all our identifiers and extant links break when a domain name lapses or changes hands.

i think any "solution" needs to have the following qualities:

- transport-independent.
- stable.
- support aliases.

additional goals:

- easy to adopt. resource resolvers can have gateways or something like a browser extension at worst. you should be able to run a local resolver on your localhost or localdomain.
- recoverable. if someone refers to the resource via a gateway, you should be able to extract *some* info from it and maybe find a different path to the resource (possibly via alias).