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?

Reply to this note

Please Login to reply.

Discussion

serapath【ツ】☮ 1y ago

pzp is conceptually in ma y ways ver similar to the pears runtime.

they allow sparse replication. The stack is not as mature and developed, but the concepts are great.

SSB had big issues, because it did not allow sparse replication in its original form and modifications where difficult to introduce later on.

in essence, SSB was linking back to previous entries via hash, while e.g pear runtime uses append only logs with merkle mountain ranger to sync data sparsly.

vinney...axkl 1y ago

Thanks for the explanation.

I'd be interested to hear what you think about our system sometime: https://opfn.co

serapath【ツ】☮ 1y ago

Carreers?

Waitlist?

And a long nerdy description end users wont understand.

Sounds like a recipe for failure.

While the ideas are great, the point is to put something out there that works instead of a waitlist with description.

Also, the second challenge is to use every day language to express the concepts instead of nerdy math and logic, which is easy, but makes it unlikely to succeed outside of a niche.

vinney...axkl 1y ago

Good feedback, thanks!

The site (and our docs and GitHub) are technical, for programmers and those familiar with the tech involved.

We are currently building an end-user product that will be explained VERY differently once an alpha is available early next year.

vinney...axkl 1y ago

And btw, as far as "something that works" - our GitHub is open source and the stack currently does work. We have relatively complete docs on the language and architecture

ynniv 1y ago

I still think that one Identity key and multiple device specific keys isn't that complicated. It's what we have now, except you validate in-event identity claims, and when you see a new revocation event prune the disavowed device events.

https://github.com/nostr-protocol/nips/pull/1450

ynniv 1y ago

Anyone who's implemented NIP-09 is most of the way there already - revocation is just a deletion request for every event by that key.

ynniv 1y ago

I'm not an expert, but I did write NYSE's SSO

PixelBob 1y ago

Sounds interesting, look forward to testing it out when its a bit more built out. One of the strengths of Nostr is simplicity, a user signed 5 field object is all you need to know. And if you want to get fancy, a websocket subscription and some event filtering.

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.

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 💬 1

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 💬 1

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.