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.

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.

GitHub

NIP-102: Subkey Attestation by ynniv · Pull Request #1450 · nostr-protocol/nips

This NIP defines a way to separate identity from authentication using hierarchical deterministic (HD) keys. This allows people to use one key pair ...

Thanks for the explanation. I'd be interested to hear what you think about our system sometime:

opfn.co

The Operating Function Company

An Operating function isn’t a device - it’s a computer defined as software. And it runs everywhere simultaneously.

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.

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

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.

> 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:

Codeberg.org

pzp-sync

PZP replication using Kleppmann's hash graph 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:

GitHub

GitHub - hoytech/automerge-poison

Contribute to hoytech/automerge-poison development by creating an account on GitHub.

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.

Carreers? Contact Us? 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.

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.

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

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.

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.

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.