Working on it! 🐝🙂
If you had a way to discover many nostr relays in a decentralized way, without relying on the mutual relay model, then this could be even more interesting. Fun research.
I’d love to sit down and discuss how this works in-depth if they’re interested. If we had some coders at square/spiral help us, we could definitely move faster. ⌨️
Thanks for sharing. That sounds like a clever plan… ingenious to separate signing from serialization so all notes can use any format.
Ignoring clearly better routes like this for the sake of not fragmenting the space is foolish this early on. If there were millions of people using #Nostr, I’d agree that it is too late. That’s not the case though! We still have time before that happens.
If you could start from scratch, how would you do it without JSONs? Let’s have a thought experiment.
The real elephant in the room is JSONs. Will and Peter Todd both mentioned how slow they are. We shouldn’t be afraid of changes that are self-evident evolution — even if some clients don’t follow suite.
It’s not like millions of people rely on #nostr like they do #bitcoin; we are still very early. Optimize while we can, before it’s too late (hardforking with millions of users is a no-go).
I agree…
We were only hesitant to open up until we were further along because it would be easy for someone to steal our code & make a poorer functioning version to claim the bounty before we completed it.
It was a financial competition afterall, so we had to act accordingly.
Haven’t released the new merkle trees yet. We’ve only released the whitepaper on how we put merkle roots on-chain to sync the nodes hosting the merkle trees. I think it’s time to reveal how everything else works, given the concern around the bounty and everyone’s curiosity.
https://medium.com/@colbyserpa/nostr-2-0-layer-2-off-chain-data-storage-b7d299078c60
Hmm. I believe you have the ability to specify bootstrap servers. And my understanding is that IPFS is more of a foundational protocol on which to build services that can offer a user-server model (like https://web3.storage/ ) so I'd imagine a service that acts as a nostr relay and has an ipfs node in combination to provide git services.
I don't have knowledge of your third item though.
We’re replacing IPFS with a layer 2 off-chain storage system that stores files with our optimized merkle trees, like IPFS does, but we ditch their bootstrapping system for a trust-minimized relay discovery system.
The node running this storage system also runs a git server, as you suggested. I have to say, I explained the basics of our storage system with merkle root on-chain — but I haven’t gone in-depth on how we’re doing the GitHub itself in context to the storage system.
Happy to share, just was trying to finish it before someone else did — it was a competition afterall.
Jack, would you like our team to write a paper explaining everything? From how we store repos, to our optimized trees and layered architecture… happy to share.
That way you and the communities on #nostr can assess our approach before we complete the project. Thoughtful criticism is always welcome.
1. Centralized bootstrapping: you must rely on a centralized set of nodes to connect into the network.
2. No user-server model: users are forced to spin up a server to browse their decentralized web. You can’t even turn a file into a merkle tree without being forced to spin up an IPFS blockstore server.
3. Their Merkle Trees/DAGs are not optimized for downloading one branch at a time, because you must download a list of all children hashes when downloading any parent hashes — creating excessively bloated merkle branches.
We’ve invented a new type of Merkle Tree/DAG that has the ability to map file directories like IPFS Merkle DAGs, and maintains the small branches of Merkle Trees for quick user validation.
This achievement may help projects independently of Nostr.
1. Centralized bootstrapping: you must rely on a centralized set of nodes to connect into the network.
2. No user-server model: users are forced to spin up a server to browse their decentralized web. You can’t even turn a file into a merkle tree without being forced to spin up an IPFS blockstore server.
3. Their Merkle Trees/DAGs are not optimized for downloading one branch at a time, because you must download a list of all children hashes when downloading any parent hashes — creating excessively bloated merkle branches.
Releasing a paper for this in a few days, unrelated to Nostr… an exciting research project.
IPFS is a nightmare, though merkle trees are indeed vital to storing large repos. That’s how IPFS handles storage.
At this point, we’re going to finish building it either way… really hope you don’t cancel it though! We’ve got quite a motivated team.
We’ve been working on the bounty daily. Canceling it would kill the developer traction I’ve got going (1 guy on UI, 1 guy integrating UI into backend, & 1 guy coding the backend for repo storage). We’re each working on a different part of the project and it was even enough to get Robin from ZeroSync to make Sats4File — a new cryptographic scheme for trading sats for files/repos off-chain over Lightning, like an atomic smart contract. 
That’s the problem, clients shouldn’t be responsible for relay bootstrapping!
Finding relays from trusted mutuals is fine (even if that doesn’t scale extremely), but clients bootstrapping users with a default set of relays is a huge central point of failure.
We’ll release a great solution to this when we complete the decentralized GitHub.
More full-nodes and more relays, not more near-identical Twitter clients. 🤦♂️