sounds like the author would appreciate the holochain framework and its built-in throwaway DHT network ontology allowing a surprisingly simple linked-data paradigm in a distributed computing environment, which in turn allows an incredibly intricate web of graphed knowledge.
---
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/
yes, i agree it initially sounds counterproductive. their (imo legit) reasoning for this strategy though is protection from patent trolls:
"Holochain in an open-source project - so why would we spend the time and money to file for a patent? The reality is that projects can be stopped in their tracks while using their own innovations if others are granted patents for the technology. In other words, this is a defensive patent. It is our intention to use this innovation and share it openly within the context of the Holochain open-source framework."
source: https://holo.host/holochain-patent/
i hope you post your 3 questions on the holochain forum (it's quite active and filled with friendly considerate people).
https://forum.holochain.org/latest
or if you want a more private/intimate place to discover/discuss/learn you can also PM me on Twitter or email me and i can invite you to the latest holochain devcamp discord server where people like @helioscomm hang out (he wrote the holochain documentation i linked to).
edit: oh wow just saw your Go p2p networking library on github. awesome 'coalescism' [1] here - you might appreciate the earlier version of holochain, which was written also in Go (but abandoned for Rust lang's security benefits): https://github.com/holochain/holochain-proto
now i'm even more hoping you join us in the holochain space!
[1] https://forum.holochain.org/t/game-what-is-your-wildest-drea...
> At a first glance this seemed idiotic
100%. i've immensely enjoyed the blogs of Eric and Arthur, it's essential complementary material:
https://eric.harris-braun.com/blog/2012/01/03/id-225
I don't follow the world of blockchains that closely (only so much free time) and I seem to have missed out on some interesting stuff that Holochain is trying to do.
---
As for the patent part, I'm not fluent in legalese and so reading the following really doesn't fill me with hope on anyone being allowed to implement something similar for an open project that the holochain developers don't approve of, or they might consider competition.
> It is our intention to use this innovation and share it openly within the context of the Holochain open-source framework.
The "within the context of the Holochain open-source framework" part especially fills me up with dread.
