I think nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c had some ideas
Discussion
I'm kinda unsure if I should move on my ideas. After all, if we break everything is it nostr anymore? I don't think so. And if it isn't nostr anymore, will OpenSats want to fund me anymore? I'm kinda jailed into sticking with nostr if I want to keep that sweet sweet funding. At least I need to stick to what I proposed I would do.
But yes I do have a lot of breaking ideas. As it stands, those ideas keep piling up. If I had "started over" 6 months ago I would have been doing it wrong. I think it might be better to just keep piling them up and doing small experiments with them, and thinking about them for some time, before actually forging ahead with it.
For example, the other day I was explaining CRDTs to a friend/colleague in town and in preparing what I was going to say on the drive over, I realized that follow lists with CRDTs aren't enough, we still need to avoid simple race condition clobbers per-server: https://github.com/mikedilger/nostr-next/issues/55
For example again, I was thinking about still using websockets, but now I think building directly on QUIC is better and the HTTP and WebSocket layers don't buy us anything we want (what they give us, like proxying, is actually against good security practice). Because QUIC has to work for HTTP/3 to work, there wont be middle-box routing problems.
I also recently did https://github.com/mikedilger/alt-tls where I got TLS running with ed25519/x25519/blake3 in ways browsers suspiciously do not support (even though the RFCs do), with modern crypto that didn't come from the US government. Interestingly I can't get secp256k1 working because of this stupid thing: https://docs.rs/rustls-pki-types/latest/rustls_pki_types/alg_id/index.html I don't know what the pkix algo identifier is or if there is a reserved area I can use.
A quick summary of other breaking things I'm interested in:
* Framed binary protocol over QUIC, not WebSockets, not JSON
* ed25519 signatures, not secp256k1
* Device keys that can be rolled over, the master key used only for managing device keys (and the DHT).
* Learn a person's relays from Mainline DHT
* Relays/servers have a pubkey and use it in their TLS certificate, so we don't need to trust DNS.
* In-protocol feature negotiation
* Mechanisms to avoid all possible clobbers
* All event kinds are default replaceable, but see the application layer to determine how the application specifies it
* Separation of application layer from the main protocol, avoiding proliferation of NIPs.
* Nodes (clients/servers) remember timestamps when records arrived, which bounds when the record was created, giving better idea of what to do regarding revocation and such
* Spans within content marked in 'tags' e.g. (start=13, end=18, bold) or (insert=56, url=SOMEURL)
Good list sir!
Agree with most things on there.
Fundamental stuff! Are you publishing the whole pile somewhere, to keep track as it mutates?
I keep track of breaking ideas on https://github.com/mikedilger/nostr-next
Great, thanks. If there ever is a Nostr Next I'd put my hat in the ring to also update the name. Nostr feels like a tricky name to popularise in blogs and podcasts aimed at non-technical users, it puts people on guard for whatever reason, plus the whole divergent pronunciation thing. The Ostrich Protocol, or OP for short, I like. Or maybe the Nostra Protocol. Or just Nos.
I’d spend a few weeks to see how far I could get into this… but that’s just me
I keep coming back to this for the all-in-one solution to side-stepping DNS and key rotation.
I hadn't seen that before. It is associating a sequence of keys with the same identity leveraging a bitcoin wallet identity. And it piggybacks on bitcoin's blockchain for distribution.
But you could make that same association using a master key (in the place of a bitcoin wallet key), and piggybacking on a signed DHT record that specifies your subkeys and/or IP address(es) (in place of the inscription).
There is more than one way to skin a cat.
I agree.
I’m just partial to this one, because it has a payment layer built in.
How would it solve these such issues though?
Key rotation doesn’t automatically include subkeys. The above proposal only solves for key rotation and it solves it with a soft solution that doesn’t require widespread adoption either from users or clients and is backward compatible. It defaults to separate identites for each npub, as they are now. A DVM could serve all the required data checks to clients and relays, so they are not required to run extra services or complete implementations for themselves.
I don’t have an equal solution for subkeys.
Keep recording it, thinking about it, even prototyping. Nostr has a lot of momentum right now, so I don't think a toy protocol will divert substantial effort away from nostr. But keep it visible enough so that if/when a successor is obviously needed we have a good starting point. It's a good project, and I think (at least for now) it "counts" as nostr
I think you just named the new protocol. Henceforth it will be called the "toy protocol".