Reflections of knowledge – Apps and APIs on the decentralized Web

---

Their example in the linked document has the following usecase:

> [Alice is a singer/songwriter] joins the app and chooses to register the username “@alice_ukulele”. She checks if it’s already been taken by calculating its address and looking for an existing username DHT entry with that address.

In traditional DHTs (chord/kademlia/etc) this wouldn't work as anyone could create "links" with the same key, and since there is no consensus on the network or coordinator nodes, this is not useful for registring unique keys on the DHT. This is the reason IPNS and other such systems use public keys instead of arbitrary strings when they want to create links to content addresses.

From my 15m of Goolging, I think holochain is trying and kinda managing to solve this issue by having a custom DHT called rrDHT (RedRibbon?) [1]. Which apparently they patented [2]. Like, WTF guys.

They have taken the core notion of "buckets" in DHTs and renamed them to "neighborhoods". Now, each node keeps their own ledger for each neighborhood they are in, and gossip it with their neighbors, which then become "witnesses". If you attempt to alter your ledger, they will let others know and everyone in theory will block you.

---

This is an interesting idea, but without having the implementation details this can be either amazing or terrible.

i. What is the conflict resolution mechanism? If two ledgers have the same key/value pair, which came first? This can't be time based, so I assume there is some sort of conflict resolution which quickly skimming the patent and docs didn't appear.

ii. As a node without too many resources that is simply trying to lookup a value, how do I know if I trust the nodes I connected to without having to sync all ledgers from all neighbors?

iii. Scaling this will be so fun.

---

1. https://blog.holochain.org/how-rrdht-works-a-tech-deep-dive/

2. https://uspto.report/patent/grant/10951697