I think the point #[2]​ is making though is: “an ion node isn't giving me any proofs that i can use to verify the legitimacy of a response" (definitely correct me if I’m wrong Colby)

if i send a request to an ION node to resolve a DID for me, what proofs are provided alongside the resolution result that would allow me to do any integrity checks?

Without these proofs, an ION node could just lie to me about the contents of a DID Doc and I’d be none the wiser.

an example that isn't ENS would be a DWeb Message or a Nostr event. they're independently verifiable. i can immediately do a sigcheck clientside and know whether the message/event is bunk.

it seems like ION node does have these proofs because they’re required in order to anchor a DID (e.g. self certifying inception event). it just doesn’t return them currently.

If they were returned as part of a resolution result (or could be requested separately) a client would have everything needed to verify legitimacy I think.

Or is the expectation to run your own ion node if you want to verify? Which is a significantly heavy lift

#[6] imo, the primary benefit of ION is the censorship resistance provided by the anchor to Bitcoin.

Operationally, the lift to run an ION node is probably too high for most to consider actually running one primarily because of how tough it can be to run a reliable IPFS node. Given the high barrier, i feel that the likelihood of there being many ION nodes to choose from is low. This paired with the high likelihood that ION DIDs will almost always be resolved by ION nodes instead of clients/light wallets manually doing what an ION node does for you sort of nullifies / diminishes the censorship resistance provided by the anchor to Bitcoin.

Generally speaking, i think reducing the # of intermediary servers/nodes that have to be relied upon to resolve a DID is the best path forward because it decreases the likelihood of getting tricked (e.g. your example an ION node tricking a user) or being censored.

If there have to be intermediary servers/nodes in between, the hope would be that running that server/node is dead simple / ezpz as a means to increase the likelihood of many people/businesses actually running them. people already don't want to run servers so the barrier is already high.

Part of your confusion seems to stem from the idea that IDs are something you can register like an ENS/DNS name, wherein different people could end up with a string attributed to them. ION specifically removes this whole class of issues due to its self-certifying inception event for creation of IDs, and it's non-transferability properties.

That's not how creation and ownership of ION IDs worlds. You cannot attempt to create/own the same ID as another person, because the ID itself is entirely generated by the initial state of the IDs PKI (including the keys). This cryptographically secure, unique, immutable means of creating identifiers is know as a 'self-certifying inception event'.

Because all data related to DIDs in ION is DID-relative, and you cannot Sybil/own another person's IDs, your routing and data URLs are not susceptible to the type of issue you are describing.

That's not how creation and ownership of ION IDs worlds. You cannot attempt to create/own the same ID as another person, because the ID itself is entirely generated by the initial state of the IDs PKI (including the keys). This cryptographically secure, unique, immutable means of creating identifiers is know as a 'self-certifying inception event'.

Because all data related to DIDs in ION is DID-relative, and you cannot Sybil/own another person's IDs, your routing and data URLs are not susceptible to the type of issue you are describing.

Good quote.

“This paired with the high likelihood that ION DIDs will almost always be resolved by ION nodes instead of clients/light wallets manually doing what an ION node does for you sort of nullifies / diminishes the censorship resistance provided by the anchor to Bitcoin.”

Thanks Moe.

We cannot rely on a prevalence of honest ION nodes as a form of security because it creates the risk of an ION Sybil attack. The proof a user receives must prove that the URL is not registered to anyone else, like it does in ENS.

Unlike ENS, an ION node could omit previous registrations of a custom URL and deliver valid proofs of a new on-chain registration. This means an attacker could perform URL spoofing on users with a mere ION node Sybil attack and a few bitcoin transactions, unlike the extremely costly 51% attack required for URL spoofing in ENS.

In ENS, full-nodes can’t perform this trick without launching a 51% attack because users receive a Patricia-Merkle proof from full-nodes that verifies the current state of the domain registry. ION trade-offs aren’t worth the risks.