Oddbean

I agree that delegation to other generic entities is not crucial, but a way to rotate/invalidate keys seems essential, isn't? What I worry is that when onboarding will increase, malware and scammers will follow: and a compromised key entails the loss of considerable value, and can also bring damage if the attacker uses it for malicious purposes. Such a situation would immediately drive the user away and create bad publicity for Nostr. The only mitigating alternative I see, without touching the protocol, is for NIP-46 to impose itself and become the recognised standard, and *all* clients to use it by eliminating login via nsec.

I don't know why everybody thinks rotating keys is essential. That seems to be a meme that came from nowhere and suddenly everybody thinks this is to be expected. The truth is that it is not possible to do the perfect delegation scheme without a centralized entity controlling the keys, like Bluesky has on their centralized server, or using a blockchain. And if we're going to have something that is a good-enough solution, Pablo's NIP-41 proposal is pretty good for the disastrous cases of lost keys. Also having this delegation scheme by itself doesn't imply key rotation is solved, I think these are different problems. I think we'll end up having good NIP-46 support and that will fix most things.

Rotation is essential to avoid loosing one's digital identity, that's a fundamental part of what Nostr offers. Yes, delegation in the NIP-26 form doesn't fully solve key rotation because there isn't an immediate way to revoke a key. For who is speculating what NIP-41 is, read here: https://github.com/pablof7z/nips/blob/nip41/41.md

I want my master key offline, and per-device signing keys online. That isn't centralization. And I cannot do that with NIP-46 where the bunker has to be online. The only solutions to provide this that I can conceive of are major breaking changes. My keypair has leaked all over the place and it is only by the grace of god that people haven't noticed and posted as me. But as of today there is almost zilch I can do about it.

You're talking about delegation, I'm talking about rotation. But your stuff also can't be done reliably because there is no way to revoke your per-device signing keys without a centralized server telling everybody that a key was revoked.

Noob here. What about NIP41 requires centralization? The announcement of the revocation? If so, could we remove the requirement for announcement? Could NIP41 suggest generating something like 12000 keys (1 per month for 100 years) instead of the proposed 256 in the NIP? Then everyone rotates on the first of the month if they want to? Too much processing on onboarding or recovery? Or too much of a pain for each client to download the list of 1200 keys for each of their contacts? If that’s too much then rotate yearly Puts the burden on clients, not relays (except load) or Nostr code. Remain backwards compatible for all existing keys. Clients could choose to care or not about rotated out keys. Clients could say “outdated contact, use caution” etc.

I suspect single key rotation and per-device keys require really different approaches. The latter is more similar to delegation. With a single key that rotates, the last used one is the authority and could sign the outbox relays, as hypothised here: nostr:nevent1qqsz9huty7l7yvzw8n85vsd3phrj9fkpnun8qqdrjc5lyzhltjrr7sgpz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhsygrmmmmmugka3evlgcqwq3922wsul966nhrayl04svauwldhsjjcq5psgqqqqqqsrgs8g8

Yes. I haven't changed email providers or DNS providers in years. Once nostr settles down, changing relays will be a rare enough thing that requiring the master key to do it doesn't seem overly onerous to me.

Why? NIP-41 doesn't do that? Let's hypothesize another solution. Take a hierarchical deterministic keys structure, and publish the public master key. When a new key is used to sign something (it should be a special event for better visibility), clients are instructed to ignore all events from the previous keys. Wait, but this doesn't block a malicious actor from signing and broadcasting events with a date in the *past*. These are the pain points. It's it that you are talking about? To fix this, we should validate all past events with the new key, or let the new key invalidate/delete malicious events, and both hypotheses seem crazy, even if maybe the latter is feasible as an extreme solution. Of course, we cannot block the broadcasting of old events, otherwise we would kill the uncensorable mechanism. So we end up considering time-stamping events using the blockchain, which is also a huge pain and a heavy dependency. I can see where centralization could arise.

Nip05 fixes this, but then that requires servers. And nostr seems to have an identity crisis that it's not actually using the internet, doesn't need DNS, SSL certs, or servers.. just these magical 'relays' that someday will run on pure ionosphere vibration or something. 👨‍💻 nostr:nevent1qqspq8a92jytj54v6unal3plfgxkhvr2phun6hll280nkxmp89qu29cpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygpm7rrrljungc6q0tuh5hj7ue863q73qlheu4vywtzwhx42a7j9n5psgqqqqqqskh6k3n

i don't get it, the problem is state application specific data already stores state in encrypted blobs and many apps already use it a number of prominent nostr devs are extremely thick and idealistic to the point of nonfunctional in some aspects

fiatjaf never bothered to learn the CAP theorem i might have to start beating some devs around the head with some CAP theorem, their thinking is clouded by a lack of understanding of the distinction of STRONG and WEAK guarantees and they think WEAK means ZERO which is not true Synchrony is another one, that maybe i can illustrate better Timestamps in Bitcoin are regulated by a set of policies that give you WEAK SYNCHRONY - what this means is that the network basically agrees on time being within a certain narrow range (about one hour either side of whatever they think it is) and blocks dated outside this boundary are not propagated by nodes this isn't an absolute thing, and it's pretty rare that a server has a clock more than an hour out of sync with the rest of the internet, but for those that are, their mined blocks are not going to be accepted part of the reason why we have to have this weak synchrony is that synchrony itself can become an attack vector if you try to make nodes agree with tighter boundaries the Time Warp Attack is literally where you break the synchrony of the system, and the reason why it happened to Verge was because they used a scheme to try and get everyone to compute a time delta against their local clock to try and agree with a tight range of "correct" time this enabled the attacker to stop time altogether the weak synchrony is actually better than strong synchrony because it spreads out the attack surface for timestamps in the consensus

not centralisation, CONSISTENCY > In a distributed system, achieving consistency falls upon the consistency model and consistency (enforcing) mechanisms. Consistency models determine which data and operations are visible to a user or process, and which kind of read and write operations are supported on them. consistency means that everywhere you ask, you get the same answer nostr's design has weak consistency not ZERO CONSISTENCY please, i beg you, go actually refresh your memory about the nature of distributed systems problems, especially the CAP theorem

no, because you are wrong consistency is a product of a protocol that gives some degree of priority to checking that all replicas are the same or in the case of eventual consistency, where the propagation strategy inevitably reaches all participants bitcoin has probabalistic consistency, which is a variant of eventual consistency, in that you can say with some amount of confidence that the chances of convergence failure after 6 blocks is basically nearest thing to impossible but not precisely impossible is bitcoin centralised? i believe it's the most decentralised distributed system ever designed nostr simply does not have a consensus, so it's not really a distributed system, the definition of a distributed system is that it acts like a von neumann machine, with limitations of time to consistency or resistance to partitioning or whatever it was intentional that nostr not have a consensus, because that frees up the space to experiment with strategies, and we have like blastr, we have nip-65 outbox model, and there's dozens of other ways that consistency can be created and actually once you can start to say that the public part of the nostr relay network is starting to have some kind of consistency, it will be so heteregenous that no single attack will ever be able to break it i mean, not that i particularly care to exercise this angle on it but using a pBFT based blockchain database effectively adds a form of consistency, that is the central point in our pitches to get the grants to do the work i don't think it's the best solution but it does in fact increase the consistency of a group of relays sharing a common distributed database, i would say that it is centralising, to a strong degree, and what primal does with cache relays is even more centralising

He talks like a distributed systems engineer. What happened. nostr:nevent1qqsyqzcfslzrtpam3yrgk4wfvxahrcw0m656z2uvaj534nuupjmne0qpz4mhxue69uhkummnw3ezummcw3ezuer9wchsygzvsqp90fvg4q5yn5zfs97zhk4dnp9jtfz6m8md44nwglfmgl3m9upsgqqqqqqs3k6ku5