@jens thank you!! i think i disagree with usage of “irrelevant” and “unnecessary” but otherwise understand what you are saying about cryptographic identity.

my conception is you use the name to get to a resource whose contents include some key(s) — kind of like a DID resolver returning a DID document which contains keys. but the identifier is still did:example:whatever so you can’t refer to it without going through the whole DID resolution thing

@trwnh The linkage to the IP comes via the sender address in the IP packet. Yes, that could be spoofed, which is yet another issue. I tried to leave that out

But in principle a cert's name could also be an IP address.

It doesn't really matter for my rant, because that's more about there not being any connection to the resource or its "owner" for lack of a better term.

@trwnh So how do you know you and I get the same keys for did:example:whatever?

It's the same problem again?

@jens the part i am specifically interested in having stable identifiers and stable references. so avoiding link rot.

one way is to have the resource assert its own identifiers, but this is only a unidirectional claim. you’d need to dereference every single claimed alias to be sure. not good!

another way is to make the identifier based in something intrinsic to the resource or thing. for a blob of content, hashing contents works. for mutable descriptors? i’m not sure…

@jens how indeed!

@jens the word the w3c people are using is “controller”

@trwnh No, I'm basically picking random identifiers here, for some definition of random

There's a whole lot of stuff hanging off of that, but the TL;DR is that a random identifier and a signature by the owner is good enough.

It can't prevent a collision, but it can ensure that my foo and your foo are different. Arguably the full identifier then are the tuples (foo, me, sig) and (foo, you, sig). But for most purposes except validation, foo is fine.

@jens so zot_guid and zot_sig, to borrow from prior art…

now here’s the hard part: how do you rotate keys without having to resign every single existing resource?

@trwnh No, no, Zot relies on names again. Really, let's not.

Rotating keys, ah... that leads down a new rabbit hole for which it really is too late.

It's doable, suffice to say!

@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