Extensions to the websocket API

guilhermelawless commented 5 years ago

The socket replacing HTTP callback is well built and can immediately support extensions with little development effort.

One way to extend will likely be to add account filters in order to minimize the number of unnecessary messages broadcasted to clients.

I would like to discuss if it is possible to add other kinds of extensions. One example I have already built is broadcasting all vote messages received:

{
  "topic": "vote",
  "time": "1554995525343",
  "message": {
    "account": "xrb_1n5aisgwmq1oibg8c7aerrubboccp3mfcjgm8jaas1fwhxmcndaf4jrt75fy",
    "signature": "1950700796914893705657789944906107642480343124305202910152471520450456881722545967829502369630995363643731706156278026749554294222131169148120786048025353",
    "sequence": "855471574",
    "blocks": [
      "6FB9DE5D7908DEB8A2EA391AEA95041587CBF3420EF8A606F1489FECEE75C869"
    ]
  }
}

Other extensions in mind:

Computed proofs of work
Wallet lock/unlock or any kind of wallet use, for security reasons
Using it for the RPC functionality

In my opinion, having the power of getting notifications of any kind from the node to any service is quite powerful.

The discussion falls into the usual "Should we have addons in the node?". I would argue that developers have enjoyed the benefits of having a thorough RPC and by extension, this could help people analyze data by not requiring them to build a packet sniffer (and keep it updated with the protocol).

It is inherently optional as I have to actually subscribe to it through the websocket, specifying a topic.

cryptocode commented 5 years ago

Thanks for testing the WebSockets feature and initiating the discussion! The possibility of using it as an RPC came up earlier. Given the full duplex nature of WS we'd need a common request/reply correlation system, or look into something like the WAMP sub protocol.

guilhermelawless commented 5 years ago

For reference, I have the vote subscription here: https://github.com/guilhermelawless/nano-node/commit/5a40e4e379181fe896579656d6ad4f6de5d39611

Surprisingly easy to set it up; can PR whenever.

guilhermelawless commented 5 years ago

The vote subscription only provides a subset of the votes in the node, and does not separate by vote type (e.g. a replay, a locally generated vote, etc).

One idea would be to have multiple subscriptions to votes, possibly using the same options for each one.

guilhermelawless commented 5 years ago

Further ideas:

Filtering votes by the accounts that the votes refer to. This would mean grabbing information about the hash from inside the should_filter() method for a vote message. Use-case example: analysing vote behavior during spam without getting huge amounts of data.
Ability to change add/remove parts of the options. Use-case: not having to re-subscribe with the full options when tracking thousands of accounts and wanting to simply add one more. Example services: DPoW , Nano Callback System

guilhermelawless commented 5 years ago

PoW-related notifications: https://github.com/nanocurrency/nano-node/pull/2289

guilhermelawless commented 4 years ago

This adds the idea of incremental filter updates: https://github.com/nanocurrency/nano-node/pull/2566

nanocurrency / nano-node

Extensions to the websocket API #1901