Nostr Web Client

So it looks like some Scuttlebutt folks have made a new protocol called PZP (previously PPPPP, which was a better name) and they even have a section in their docs about Nostr: https://pzp.wiki/guide/intro/#how-pzp-is-different-from-nostr

But aside from that the protocol seems to be pretty much like SSB, but with per-device keys and no strict need for a key to follow a single chain of notes. I can only imagine this makes the implementation much harder.

Do you have opinions nostr:npub1wmr34t36fy03m8hvgl96zl3znndyzyaqhwmwdtshwmtkg03fetaqhjg240 nostr:npub16zsllwrkrwt5emz2805vhjewj6nsjrw0ge0latyrn2jv5gxf5k0q5l92l7?

21823843... 1y ago

> sig-chains - you know if you're missing content in PZP

You could do the same on nostr if anybody actually cared about this. Just include a "prev" tag with the ID of the previous message in the chain you're building. You could also have a "last" tag or something to indicate the chain is complete. Clients could render it as "message 3/9" or whatever, like people do manually on Twitter.

In fact, PZP's replication appears to *rely* on these hash chains, since it uses hash graph replication: https://codeberg.org/pzp/pzp-sync

I did some analysis of this sync method and if you tried to use it for non-linked data you can easily cause it to degrade into a worst-case behaviour: https://github.com/hoytech/automerge-poison

IMO RBSR/negentropy is better, one of the reasons being you can sync arbitrary collections of (unlinked) data, for example all kind 0 notes, or all notes with a certain hash tag.

Reply to this note

Please Login to reply.

Discussion

fiatjaf 1y ago

For some reason some people really seem to care about the "you know if you are missing content" bit, given that I've received that criticism many times with regards to Nostr.

However I suspect it's only an abstract concern they heard about because some other protocol or scheme provided it and then they decided it was a real problem.

rabble 1y ago

Yeah I don’t get it. Assuring you’ve got all the events is a hell of a lot of work for only theoretical benefit. ATprotocol does the same thing. But why. Are peers dropping content really a big issue? We don’t care about it in Nostr and it’s fine. Everything is so much simpler too. We could implement it a number of ways in Nostr. But there’s been little need.

liminal 🦠 1y ago

I tried implementing it for sections of text to compose into a single article - still doesn't make sense, even for modular content

Mike Dilger ☑️ 1y ago

IF a protocol could provide it, it is a nice way to rest assured that somebody isn't censoring the most subversive of the events. On nostr you can't tell. Maybe you are only getting 50% of the events, the ones the government censors allowed.

But it should be done in a soft way so the protocol doesn't break, or become inflexible. Since events can be used in many ways in many places, and there is no global store of events, it is inevitable that you will miss events in nostr. You will miss the ephemeral "king of hearts" event on the relay where people play bridge. You will miss the event that someone sends to their bunker. So clearly such a thing could not be globally applied in nostr without causing serious problems.

But maybe it could be applied in a soft way to certain kinds of events, maybe even linking back to the last 3 events meant for public consumption, instead of just the last one.

In any case, not a core/critical part of the protocol and can be added at any time we want.

Matt Lorentz 1y ago

I think it’s more about trust and dependency on a middleman than fear of censorship. It’s abstract at scuttlebutt’s scale but the idea is that we can only avoid a capitalist enterprise enclosing and extracting value out of our open network if the system is not dependent on them. And I’m not convinced that’s wrong. But maybe it is too big of a step forward. Nostr is much more practical.