search

nostr-protocol / nips

Nostr Implementation Possibilities
2.39k stars 577 forks source link

Client-Relay Handshake (Bidirectional Information Documents) #862

Open manimejia opened 1 year ago

manimejia commented 1 year ago

In an effort to open up (unbloat) the nostr protocol by freeing clients and relays to tailor their implementations, there emerges a need for clients and relays BOTH to identify themselves and the features that they support. This “handshake” transfer of info should happen when a web socket connection is first opened. Currently nostr only supports a one way communication of this sort, with the adoption of NIP 11 : Relay Information Document.

As a protocol to decentralize social media, nostr attempts to facilitate “user initiated” communication between autonomous relays and clients. True autonomy and decentralization (of the protocol itself) will only come once relays and clients (the apps and servers) can “learn” about each others capabilities, independent from a specific user request. In this manner, and as the nostr protocol “opens up” some aspects of the protocol (like: user generated Kind 1 typed content), client developers and relay operators will be able to freely customize certain features and “bring to market” novel offerings “not yet” supported by NIPs.

fiatjaf commented 1 year ago

Clients and relays are already free, they can write anything they want in any event kind. They don't even have to follow the NIP-01 event format, they can make up new formats, change the signatures, remove the signatures, encode the data as XML, they can do anything!

Except it wouldn't be Nostr anymore.

manimejia commented 1 year ago

Except it wouldn't be Nostr anymore.

The entire value prop for NIP-11 is for client (machines) to know what to expect from a connected relay. If implementors should be free to "do anything they want", then this "understanding" of capability needs to go both ways. Otherwise, they will (continue to be) isolated islands of experimentation.

Not nostr.

ghost commented 1 year ago

They don't even have to follow the NIP-01 event format, they can make up new formats, change the signatures, remove the signatures, encode the data as XML, they can do anything!

Except that's where you're wrong. A lot of relays have started verifying if events actually match the NIP-01 format and are also verifying signatures. I get why, it's to prevent bogus stuff from clogging the relays up, but it still sucks as the developers are now forced to use, for example, the secp256k1 curve (I'd much rather use Curve25519).

mikedilger commented 1 year ago

I agree that a feature negotiation would have been nice. But it is too late, so that would be a different protocol.

Maybe something will come after nostr that learns from all of nostr's mistakes. But starting such a fork now would be IMHO very bad for all involved. I started doing it a year ago, and then came to my senses.