I keep coming back to this for the all-in-one solution to side-stepping DNS and key rotation.
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)
Discussion
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.