NUT-17: WebSocket state updates #98

2024-03-21T16:04:02Z

Egge21M commented

2024-03-21 16:04:02 +00:00

(Migrated from github.com)

This is my second take on an optional WebSocket protocol to allow bidirectional messages between clients and mints. WebSockets allow mints to push updates to clients without clients constantly polling them.

The proposal uses ids to keep track of requests, which removed the need to close and open sockets all the time and also allows for multiple request on a single socket connection.

This is my second take on an optional WebSocket protocol to allow bidirectional messages between clients and mints. WebSockets allow mints to push updates to clients without clients constantly polling them. The proposal uses ids to keep track of requests, which removed the need to close and open sockets all the time and also allows for multiple request on a single socket connection.

bumi (Migrated from github.com) reviewed

2024-04-01 15:28:24 +00:00

XX.md

would it make sense to use the JSON-RPC format here?

Egge21M (Migrated from github.com) reviewed

2024-04-01 16:27:25 +00:00

XX.md

I don't have strong opinions about this. The format is already very close to the RPC spec so I wouldn't mind. What would be the benefit of adhering to it?

AngusP (Migrated from github.com) reviewed

2024-04-11 13:10:36 +00:00

XX.md

What would be the benefit of adhering to it?

I'd guess mainly existing client libraries for using JSON-RPC rather than having to write your own

> What would be the benefit of adhering to it? I'd guess mainly existing client libraries for using JSON-RPC rather than having to write your own

Egge21M commented

2024-06-17 08:53:09 +00:00

(Migrated from github.com)

I wonder if this should include a standardised endpoint as well? E.g. wss:///v1/ws

I wonder if this should include a standardised endpoint as well? E.g. wss://<hostname>/v1/ws

👍 1

callebtc (Migrated from github.com) approved these changes

2024-06-25 17:03:34 +00:00

callebtc (Migrated from github.com) left a comment

ACK d99a6f1

ACK [d99a6f1](https://github.com/cashubtc/nuts/pull/98/commits/d99a6f10bd3b1880a7891c9b1ecdf550b74b4e93)

thesimplekid (Migrated from github.com) reviewed

2024-06-26 08:06:01 +00:00

17.md

					
				@ -0,0 +87,4 @@

				**Important:** If the subscription is accepted by the mint, the mint MUST first respond with the *current* state of the subscribed object and continue sending any further updates to it. 

				For example, if the wallet subscribes to a `Proof.Y` of a `Proof` that has not been spent yet, the mint will first respond with a `ProofState` with `state == "UNSPENT"`. If the wallet then spends this `Proof`, the mint would send a `ProofState` with `state == "PENDING"` and then one with `state == "SPENT"`. In total, the mint would send three notifications to the wallet.

Is it required that the mint sends 3 notifications. In the event the proof is spent via a swap there isn't really a PENDING state. As signing the outputs either succeeds and inputs are spent or fails and the inputs should not be SPENT. Of course could use the PENDING while the verifying and signing happen just not sure how much benefit that adds?

Is it required that the mint sends 3 notifications. In the event the proof is spent via a swap there isn't really a `PENDING` state. As signing the outputs either succeeds and inputs are spent or fails and the inputs should not be `SPENT`. Of course could use the `PENDING` while the verifying and signing happen just not sure how much benefit that adds?

thesimplekid (Migrated from github.com) approved these changes

2024-06-26 08:06:24 +00:00

thesimplekid (Migrated from github.com) left a comment

ACK d99a6f1

ACK [d99a6f1](https://github.com/cashubtc/nuts/pull/98/commits/d99a6f10bd3b1880a7891c9b1ecdf550b74b4e93)

callebtc (Migrated from github.com) reviewed

2024-06-26 21:36:25 +00:00

17.md

					
				@ -0,0 +87,4 @@

				**Important:** If the subscription is accepted by the mint, the mint MUST first respond with the *current* state of the subscribed object and continue sending any further updates to it. 

				For example, if the wallet subscribes to a `Proof.Y` of a `Proof` that has not been spent yet, the mint will first respond with a `ProofState` with `state == "UNSPENT"`. If the wallet then spends this `Proof`, the mint would send a `ProofState` with `state == "PENDING"` and then one with `state == "SPENT"`. In total, the mint would send three notifications to the wallet.

Good points, maybe we can relax this condition.

pablof7z commented

2024-06-29 20:02:59 +00:00

(Migrated from github.com)

just floating this idea, too little too late but wonder if this is something that would have been of interest; what if the mint spoke nostr REQs and acted just like a nostr relay? would be kinda neat to be able to reuse all the nostr comms libraries we've got to talk to mints

Don't know, maybe it's dumb and the protocol is too different, but was curious.

just floating this idea, too little too late but wonder if this is something that would have been of interest; what if the mint spoke nostr REQs and acted just like a nostr relay? would be kinda neat to be able to reuse all the nostr comms libraries we've got to talk to mints Don't know, maybe it's dumb and the protocol is too different, but was curious.

Sign in to join this conversation.

No reviewers

callebtc

thesimplekid