Extensions to the websocket API

[guilhermelawless]

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]

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]

For reference, I have the vote subscription here: guilhermelawless@5a40e4e

Surprisingly easy to set it up; can PR whenever.

[guilhermelawless]

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]

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]

PoW-related notifications: #2289

[guilhermelawless]

This adds the idea of incremental filter updates: #2566