We spent a long-time crafting a standard for file chunking by evolving Merkle DAGs, which are modified Merkle Trees used for file storage.
These Scionic Merkle DAGs are a significant improvement over IPFS Merkle DAGs. https://github.com/HORNET-Storage/scionic-merkletree
IPFS is arguably one of the most popular P2P file sharing platforms in the world, as you know. Their entire system is cryptographically secure due to their Merkle DAGs.
Our merkle branches contain fewer useless hashes. As the folder grows, the branch size decreases logarithmically compared to Merkle DAGs. Stats can be seen on the GitHub page.
These new Scionic Merkle DAGs can be used for a user-sever model where relays store files beyond notes, or a P2P model as you described here. We’re setting up a #Nostr relay that supports them now.
I don’t mind pursuing both futures, but I lean toward the paid user-server model. I’d be curious to see where you and JB take the P2P model, as Robin Linus and I are working on a way to paid relays over Lightning in an atomic way, with preimages as file chunks. nostr:note12fxpjxw6w6l78dye7w073t8paakrc6demp4emlze3zcdw00n029q7xtrg9
Robin Linus and I are working on a way to pay* relays over Lightning in an atomic way
We spent a long-time crafting a standard for file chunking by evolving Merkle DAGs, which are modified Merkle Trees used for file storage.
These Scionic Merkle DAGs are a significant improvement over IPFS Merkle DAGs. https://github.com/HORNET-Storage/scionic-merkletree
IPFS is arguably one of the most popular P2P file sharing platforms in the world, as you know. Their entire system is cryptographically secure due to their Merkle DAGs.
Our merkle branches contain fewer useless hashes. As the folder grows, the branch size decreases logarithmically compared to Merkle DAGs. Stats can be seen on the GitHub page.
These new Scionic Merkle DAGs can be used for a user-sever model where relays store files beyond notes, or a P2P model as you described here. We’re setting up a #Nostr relay that supports them now.
I don’t mind pursuing both futures, but I lean toward the paid user-server model. I’d be curious to see where you and JB take the P2P model, as Robin Linus and I are working on a way to paid relays over Lightning in an atomic way, with preimages as file chunks. nostr:note12fxpjxw6w6l78dye7w073t8paakrc6demp4emlze3zcdw00n029q7xtrg9
And they are all right-aligned instead of spread out like how they are on Twitter. Really miss that.
The replies, retweets, likes, and zaps don’t match the order of how they are on Damus and Primal.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402 
nostr:note1tzx2gdrdpuh9tdrcy8ngawva50jwqsd3ncw40p6rqyfg8arlmweq8knevl
I’ve never read this book because I lived through it, but that’s a good quote.
If it isn’t atomic, I don’t want it…🪬
⚛️Atomic trust-minimization✅
“Quote reposts are kind 1 events with an embedded e tag (see NIP-08 and NIP-27). Because a quote repost includes an e tag, it may show up along replies to the reposted note.”
Sounds like it needs its own NIP too.
A way to reference a previous note like quoting it.. but to mark it as a previous iteration.
Cool idea… would need a different UI for that type of reference.
The shadow of a butterfly… 🦋
A trillion iterations later.. ⛩️
PTLCs improve privacy but worsen the risk of jamming attacks and are computationally intense if used for Sats4Files due to all the ecliptic curve operations required across thousands of invoices.
Can we build a simpler, faster Sats4Files without PTLCs? 🪺⚡️
https://bitcoin-problems.github.io/problems/ptlc-cycle-jamming.html
elliptic*