Starknet WebSocket specification proposal

[amanusk]

How to read this spec

• Each subscription type is described by its own method, with relevant parameters.
• The result of the subscription is a subscription ID, used to determine which stream a notification was received from, as well as an option to unsubscribe.
• For each subscription type, there is a notification method describing the results received in each streamed event
• A Reorg error is possible on all subscriptions, notifying that a reorg has occurred, and it is up to the client to treat this case according to their business logic

---

This change is 

[ittaysw]

What is the behavior of these subscriptions when a node is syncing? E.g. I subscribed to events, will i get all events as it is going through blocks? A node may be syncing back as well, what is the meaning of 'latest' then? And if two nodes are syncing on the same range, one forward, one backward, will they send different events on the stream?

Seems to me like we should just not allow subscribing when a node is syncing, only when it is fully synced. Then we can also remove the syncing status call.

[amanusk]

Latest changes based on discussions above

• Add sender_address filter to pending transactions subscriptions
• Add subscriptionReorg that can be received by Headers, Events, Transaction Status
• Remove sync subscription and events
• Nodes only allow WS sucscriptions after they are synced
• Updated keys as in event filter

Open question:

• Allowing to start a subscription from a previous block and "catch up" to the latest (applies to headers, events, transaction Status)
• Returning subscription notifications one by one or as an array (applies to Headers, Events, Pending Transactions)

These are also questions for Full nodes and how much does this complicate implementation

[amanusk]

Update: Added the option to subscribe to up to 1024 blocks back, and the accompanying error