-
@ Mike Dilger
2025-04-03 07:40:53
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)