“Not a single entity I know that’s doing production deployments has actually vetted did:ion and found it to be production capable.”
The guy leading the DID effort said this about ION.
Seems like they may be 6 months away from producing something.
In their design it says you can create, update, recover and activate. It is a bit magic
But update implies a versioning system. So you could think of it like updated nostr events. My key is A. Now my key is B. Tied to a content addressable static ID (like a genesis event ID).
Let’s see. I hope they produce something useful. Daniel tends not to answer questions
When we first made DID, the idea was that your (d)id and your public key or hash were the same string.
As it evolved, that got broken. Which can be useful because then you can have multiple keys, but the trade off is more management needed.
So you have DID <—> controller two way link. Then it can have multiple keys. Those can be used to update the record. How that chain of records is stored, fetched and verified, is not covered by DID. So everyone will do it differently. Nostr for example could create updating keys with a NIP, it would do the same thing.
Basically impossible to have a convo with Daniel
true. too often appeals to authority
the side tree spec has an update function
‘Retrieve the Update Reveal Value that matches the previously anchored Update Commitment’
so it looks like they have a chain of anchors … anchored to something, ion nodes i guess, which also run btc full nodes
‘Embed the Anchor String in the transaction such that it can be located and parsed by any party that traverses the history of the target anchoring system’
‘By leveraging the blockchain-agnostic Sidetree protocol, ION makes it possible to anchor tens of thousands of DID/DPKI operations on a target chain (in ION’s case, Bitcoin) using a single on-chain transaction’
there you go
do a search in the ion repo for ‘anchor’ and it gives some details
there’s a Q & A
Their anchor protocol doesn’t guarantee you have a full view of the data, so you can open the commitments to anything you like (provided you pre-committed to different views). In my opinion this makes the commitments pointless.
‘Assuming you are running your own node, you simply need to submit 1000 create operations to your node (ie. http://localhost:3000/operations) before your batch writer kicks in every 10 minutes by default, the batch writer will batch all 1000 operations into 1 bitcoin transaction thus you’ll pay fee for just one transaction to the minor. The technical spec for constructing a create request can be found in Sidetree API spec, but if you know TypeScript, you are better off using the ion-sdk directly, it will save you a lot of time’
seems 3 places data is stored
anchored witness data: bitcoin tx batches of operations: ION nodes non witness data: maybe IPFS
‘The logical order of operations, as determined by the underlying anchoring system (e.g. Bitcoin block and transaction order). Anchoring systems may widely vary in how they determine the logical order of operations, but the only requirement of an anchoring system is that it can provide a means to deterministically order each operation within a DID’s operational lineage.’
It’s deterministic given a set of data, but there is no consensus on the set of data, so if A and B get presented with a different set, they come to a different conclusion
yes. “DID owners can create forks within their own DID state history”. so you dont actually know the full state. I think the design is of each identity has eventual consistency, with the anchor as the tie break. It can change as you know more data. But doesnt say what happens if two updates happen in the same block.
the aim is eventual consistency
so at any time you might have the wrong state, but if you had every update associated with a given id, you could determine the right order to apply the patches by using the bitcoin block chain (I dont know what happens if there’s a tie in the same block) … there’s no peg in or peg out, it’s just like version controlled files
But you can’t know when you’ve reached the state of eventual consistency (i.e. when you finally have the full data set) and in practice it may never be reached, so there is no consensus
When there is conflicting data, the first one counts and the second one is ignored.
This problem is literally detrimental, yet it is being presented as a minor inconvenience.
yes, and the first one can be published later, so systems will think the second is valid, until it isnt
you could actually steal someone’s identity, and revoke all their keys, and then reveal it years later
arguably this is worse than github
lol yeah you could
or an attack vector, get someone’s ID, but they dont know, then sell them lots of ‘cheap’ NFTs … at some point you publish the new keys and reclaim all the tokens … no one will know when they will be rug pulled
That was my original argument, but Daniel claimed the protocol wasn’t meant for transfer of ownership rights.
so then i wonder what the primary use cases are that cant be easily achieved already
‘How Can ION be Used? ION can see a lot of use in many cases. The most obvious use case is for verifiable credentials. A business can credential employees, who can then be verified via blockchain on arrival at their destination. This functionality also raises its use as a means of supplying and verifying international travel documents.’
‘Another use case could come from accreditation for organizations. Using an organization’s public key, users can verify their accreditation status and trace their accreditation history over time.’
so i guess its an updatable profile page, but you dont know when your profile is compromised. OTOH it’s free (their node is paying fees to start with), and improves BTC security budget. If you keep your key safe, and the nodes publish the updates for you, it might be a nice little profile you could use for stuff. But not sure id use it for anything high value. And nostr (for example) can do alot of this already — updatable profiles and publishing
i think it may be to a degree censorship resistant too
there’s also no incentive to run a node, so im not sure why they would stick around
nodes can actually very easily censor by black listing certain tx (e.g. a hack, or sanctioned identity), removing the decentralized nature
so the nodes can never reach consensus
Like I said, the commitments are pointless. I think it’s equivalent to just signing stuff with a key and making what you signed available for download in “the cloud”.