Without a “state”, relays will never know if they’re missing notes from their users.

By letting the client turn all their notes into a Merkle Trees, relays can realize when they’re missing notes from you.

This benefit is independent of syncing. It turns relays into librarians rather than having them just store stray notes. 📚

Syncing allows the relays to request the missing Merkle leaves/#Nostr notes, now that they know what notes are missing!

Reply to this note

Please Login to reply.

Discussion

Relays can use syncing to find what notes are missing for profiles they already store. They don’t need to use syncing to become “super” relays… it can be used to get a complete set of notes for the profiles they already have.

I like the sound of this

Today, Nostr acts as a weak storage layer. By using Merkle Trees, Nostr can act as a strong and consistent storage layer.

Love it.

I am focusing most of my time on my next #bitcoin awareness project right now, so I won't be launching sticker bounties for the foreseeable future.

There will be plenty to do when the project launches in January 😉

Feel free to post some stickers and I'll zap you in the meantime!

🐝 cyber hornet stickers would be tight…

Zapped.

What’s a relay’s “users”? And why do this relays want to have all “their” users’ data?

Sounds like Facebook

The goal is to click a profile and actually see ALL their notes.

Stop using propaganda-like wording to argue against me and just refute the main point. Why can’t we work together?

nostr:note1zqm86fdhwzrld897wxzmzyq7tex4j6mp39r76aapw39h507del8q8wnsrx

All the data is still controlled by the user because the root is signed with their npub. Are you trolling or do you genuinely not understand?

NIP-65 is great but the list of relays in each note may expire. We’re working on a way to fix that part of NIP-65 though. It’s gonna be a mind blowing combination! 🤯

I agree that NIP-65 is insufficient, but you seem to be very pissed off, not sure why.

Sorry if I’ve been angry. We get passionate about the things we care about. It’s hard to communicate over notes.

I just hope you can see the value of syncing for the sake of maintaining a profile state — not to have it be the only way to discover notes.

NIP-65 with a few changes could be the game changer we need. Improved syncing with shrunken request sizes compared to Negentropy is also a bonus.

nostr:note1zmzvy8xqfm8auwpy52qgrc84jmllf0l4au60lyxll6rehaefwj9qxuxwvq

I apologized but you seemed a little pissed too… you’re literally acting like I’m Facebook here but I’m just talking about Merkle Tree profile states.

nostr:note1sujy3txqglhkjlhd55wt3czau7d9tsj5effr70lgx5lsj8vpagqslly0va

Complaining about my attitude and then comparing us to Facebook 😂 why not ask me a question about anything technical — like our small merkle branches or small request sizes, or the file storage ability of the tree’s?

There’s so much to this technology I’m trying to show you.

Dude, I didn’t know you had a project and you just came out swinging when I wasn’t even talking to you and saying I was spreading FUD.

I think you’re assuming I was subtweeting you when I wrote the first note earlier today you responded to.

I was not, my comparison with bcash was not about your project, it was a comment about the idea of having all relays keep state of all nostr data (which I am obviously not saying is what your project is about, but again, that note wasn’t about you, your project nor a response to you!)

Again, my first interaction with you was you responding to me, accusing me of some spreading FUD about a project I hadn’t heard of 🤷‍♂️

You compared Relay Syncing to bcash so yes I came out swinging. I didn’t think you were subtweeting at all. I was just saying don’t spread FUD about Relay Syncing and explained why in-depth…

Read the note I was responding to again; the guy was proposing keeping a single state, like bitcoin. Not just syncing.

A single state. For all of nostr data. That’s why I used the analogy of bcash.

technically it is a single state, and the thing that you didn't get was that this is not a consensus but rather an inventory (merkle tree) that can be used to identify missing pieces and how to request them from peer relays.

the goal is not a blockchain but an eventually consistent replication of events associated with a nostr key.

it's pretty advanced distributed systems stuff, nobody should feel bad about miscommunicating about it.

i just got done writing quite a long winded bit of signing algorithm just now and i don't want to test it yet because it's too close to bedtime. but it's drafted :D

yes i am working on part of what Colby is talking about.

that’s great; that’s not the proposal I responded to, to which Colby responded unnecessarily aggressively. 🤷‍♂️

Good luck with your project, it sounds interesting.

Ahh I see. The guy you were replying to wasn’t suggesting a single state — he just wanted syncing, but yes a single state would be bcash vibes indeed. I see what point you were trying to make.

We’ve quarreled a bit in the past Pablo so sorry if I was quick to be combative this time around. You were complaining at us a few months ago before OpenSats got the 10M about our decentralized #Nostr GitHub project not being open-source yet.

We told you we would release the project details (trees etc) when they were functional, we finally did on the 4th of July. Still more to be released soon.

https://github.com/HORNET-Storage/scionic-merkletree

it's hidden in interfaces but follows, reactions, mutes, profile json, all are publicly available over relays. a relay's users are the people who publish their notes and other messages to them.

Adding verifiable completeness of a set of data seems like a nice optional feature

“What’s a relay’s “users”? ” It's philosophically hard to answer this question.

It’s a non-sensical question… the relays don’t control the users. This is an add-on to #Nostr and works exactly the same sovereignty wise.

Perhaps this can be a new kind of server. Relays are dumb pipes. This wouldn't be.