Negentropy is a minimal version of IPFS’s BitSwap, used by Strfry and NostrDB.
GraphSync is IPFS’s evolution of BitSwap: it syncs with ranged requests rather than asking for each note one at a time.
We are building our own version of ranged-request syncing, similar to GraphSync, for #Nostr.
The Scionic Merkle DAG-Trees come equipped with numbered leaves to facilitate this type of syncing. Given that the new Merkle DAG-Trees make it possible, we’ve named our syncing system FOREST. 🌲 FOREST synchronizes the Merkle DAG-Trees across nodes. 🌐
Threads is hugely a backend problem… syncing notes so threads load properly. We’re working on it! :-)
🐝🌲
You got this
Mistakes make us human. It’s ironic the repetition of mistakes is the path to eventually learning truth… it’s almost like the path to truth is inherently humbling, because it requires failing so many times.
The sky is purple and orange right now, as we prepare our OpenSats grant application.
Primal’s iOS app looks slick. Too bad the App Store is such a gatekeeper.
🐣 
I agree. For example, sending spoof messages to prevent timing-based surveillance requires a lot of bandwidth if you have thousands of DMs. It’s definitely a “defcon 5” feature.
Not sure if we can top that adventure, but we’ll try! I think Satoshi would love the idea of owning your account wherever you go.
Nostalgic I bet! 😁
If you download the entire file and verify the signature afterwards, then you’ve wasted a ton of time downloading a file that may not be the one you requested.
This is why large files should be Merkle DAGs in decentralized networks. It provides security against this type of attack.
Merkle DAGs are required for file storage. Merkle DAGs allow users to sign the root and cryptographically verify that the hash of each chunk matches the root hash. They can perform this verification check everytime they download a chunk…
**This way they don’t need to download the entire file before verifying the signature.**
We evolved Merkle DAGs significantly and shrunk the branches for faster speeds than IPFS. The code is already done. :-)
nostr:note1d7d6w46j7jgufd6hz8pky0h5awrucrwpmvwt3fkp3f6v7dp74h4qvcthwd
Thank you! We hope you’ll consider adopting it into Iris for photos/videos etc. Our first client with it will either be a fork of Iris or Snort, so you can experience how it works first.
We’ll be coding a JS version of the Scionic Merkle DAGs soon for all webapps.
Very high memory/RAM requirements needed to support an extremely large amount of notes. It might struggle at higher scales unless the relay setup has a ton of RAM.
It’s a memory-mapped database, so it’s very fast since it can pull so much more from memory instead of the harddrive — but reliance on RAM for that speed requires buying a lot of RAM, which is costly compared to SSDs… that’s the only notable trade-off I’ve seen.
Encrypted AI… (zkML may work too) with an atomic sats per token model. ✅
This is why we don’t want to lead the webapp development. We have a lot of work to do implementing our syncing system. So, if anyone is interested in teaming up I’m all for it.
The Strfry relay uses Merkle Tree syncing called Negentropy. Our syncing will require fewer rounds of communication between relays exchanging missing data, and will support file storage due to our new Scionic Merkle DAGs/Trees.
Negentropy requires relays to request one missing note at a time… this inherently slows it down. IPFS has a syncing protocol that works just like it called BitSwap, but they evolved it into GraphSync so that nodes can ask for a large range of missing notes/data in a single request.
Our syncing protocol will mimic what GraphSync did with ranged/batched requests, but for #nostr — we achieve the ranged requests in a simpler way too, without needing the complicated graphing system.