> I am feeling that way about the entire protocol

I think it was Maxim Orlovsky of RGB fame that proposed a Nostr2 using binary

NIP-1 is pretty ossified at this point so I don't think it'd be fruitful to try and change that now, but a meta-protocol for the client <> gateway <> signer doesn't necessarily need to adhere to that.

> sovereign identity needs a sovereign identity server just as sovereign payments need a sovereign payments server.

It is, yes. I still would love to subscribe to a superkey instead of a signing key; that would make things a little less dangerous on the signing key exposure. But yes, NIP-26 feels incomplete for that to me too (and relies on relay-side routing, not just relay-side signature validation.) Running one serverside vault is easier to secure than running it on your Samsung that never gets patched too - but then, people have no clue anyway.

> transport. Nostr is paradoxically not a good fit for this

I am feeling that way about the entire protocol, haha. It's not transport-optimal in any way. Nesting layers of base64 encoded json.. oof.

optimism

Yea that's the trade-off with all this sovereign internet stuff. Same as Lightning, sovereign identity needs a sovereign identity server just as sovereign payments need a sovereign payments server.

Biggest decision I have yet to make on it is the transport. Nostr is paradoxically not a good fit for this because of the size increase of the response event nesting the signed event. Need to investigate what compression or returning the signed event as binary might achieve. Having the signer do the actual emit could have security implications since it couldn't be in a militarized network, and the client UX/DX could suffer.

nostr

Why Nostr Identity Is Not a Negotiable Feature - alp

Scoresby

> not loving the liveness requirement

Yea that's the trade-off with all this sovereign internet stuff. Same as Lightning, sovereign identity needs a sovereign identity server just as sovereign payments need a sovereign payments server.

Biggest decision I have yet to make on it is the transport. Nostr is paradoxically not a good fit for this because of the size increase of the response event nesting the signed event. Need to investigate what compression or returning the signed event as binary might achieve. Having the signer do the actual emit could have security implications since it couldn't be in a militarized network, and the client UX/DX could suffer.