Very interesting. I just read all your GitHub readmes.
How do you do networking and p2p?
I have a network design that fixes this problem (You can find a proof-of-concept here: https://github.com/baumbit/treebit ). The fix is easy: node-to-node (p2p, just like bitcoin) and content propagation is solved by #peercuration (https://github.com/baumbit/peercuration). The design even works in adhoc meshnetworks. And… good news everyone, its applicable to Nostr notes!!!
Very interesting. I just read all your GitHub readmes.
How do you do networking and p2p?
A node connects to peers that it discovers. The peers have to compete for the available bandwidth. Those peers who offers the best content gets more bandwidth. Before downloading content, your node download scores for the content. Content is always identified using its hash. An average score is derived based on your own prefences (key words, WoT aka #opengroups, etc) and a download priority queue is created. Basically put, #treebit is not(!) a gossip protocol, not a distributed hashtable either. Its 100% p2p where your node only store the content you value (which is the content you want and content your node think your peers want). The whole design is based on incentives. I dare to imagine that this is might be a novel p2p protocol, because I never heard of it before (though that could be simple ignorance on my part).
The node itself can be a hidden onion server (code on repo defaults to TOR), but data can really be transferred using what ever channel is available. You can even send content (nostr notes here) using USB-stick and someone else can publish it (same as Nostr).
I also invented “archive nodes” and “bridge nodes” which is basically what relays are in Nostr. This implies that indeed, we could implement #treebit on Nostr without actually making any big changes to Nostr.
Does your design allow nodes to maintain separate contextual channels such that "I get content from a b and c for [topic X]" and "I get content from m n and p for [topic Z]"?
In my opinion, any decentralized content/trust system must allow nodes to highly trust a given peer in one context, but strongly distrust the SAME peer in another context.
I agree with your opinion! Very important observation.
And to answer your question: Yes it perfectly suited for the kind of curation you mentioned. I went further… while my proof-of-concept has a suggested default content filtering; the hope is that users would design their own filtering algos using the basic primitives: #opengroups #peercuration #hashscore #tags and I left it open so that more such primitives could be invented and integrated. Instead of a “global content consensus” protocol I made a “local normative” protocol model. Not opinionated. Designed to be re-redesigned. #treebit could have bridges to other networks such as Nostr.