The real nostr 2.0

Reply to this note

Please Login to reply.

Discussion

Isn’t Blossom just an NIP for how to manage media endpoints? How is it different from the ā€œmedia metadataā€ NIPs?

Yeah, it is, I'm mostly kidding. It just looks like nostr 2.0 because it has a similar but separate network architecture and content discovery mechanism.

It's different from NIP 96 in that it's simpler and more focused on discovering verifiable file contents based on the file's hash, whereas it's unclear to me how strong the guarantee is with NIP 96 that you can verify a file hasn't changed, since the spec says:

> Note that the "" part is from the original file, not from the transformed file if the uploaded file went through any server transformation.

This could probably all be fixed within NIP 96 itself, but hzrd and stu have decided to go in a different direction.

Nostr 2.0 is dead. Posting Merkle roots on-chain all the time was just too expensive.

Merkle tree-based file storage on #Nostr relays is still coming though, because files should be chunked in decentralized networks.

I think you’ll love what we’ve done with Negentropy too! Changed the name FOREST to LeafSync as well, found a way to blend it with Negentropy.

It’ll be unfolding soon.šŸ»

We coded Negentropy v1 in Go 🤭

I believe you were the one who told us FOREST was too confusing sounding.

We also explained what Scion means on the website. It’s an analogy to plant grafting, since we grafted two types of Merkle structures together. 🌳