Is there a more reliable way to pub/sub with nodes? So you can target any running AE node?
Also is it possible to open state channels with different nodes? Like say there are 2 different AE full nodes, and one client opens channel with node1, and then other client with node2. Can both clients still receive state channel evented messages, in realtime without polling?
Also are 1 to many state channels possible?
My usecase is pretty simple, its a pub/sub queue, so the queue should be evented, meaning without polling, subscribers to it should be able to receive notifications ASAP when something changed.
This is not something the middleware currently supports–but our main middleware servers are monitored and restarted if anything bad happens, and the node to which they speak is reporting > 99.99% uptime for the last 30 days, so is this a problem for you in practise?
In order for them to keep the connection trustless, both Alice and Bob shall have a full node of their own that keeps them safe. If they really want to, they could share a single node if they want to, but this implies both of them trusting the node operator. In the described solution Alice has her own node that connects to Bob’s node and both clients get notifications from their own node in a trustless manner. At the heart of our example implementation is the FSM that does all the heavy lifting for the clients. We are also using WebSockets so as soon an event occurs and is detected by the FSM, it can be pushed to the client, no polling needed.
Not yet. Currently we only support 1:1 channels and the plan is to keep it that way. Introducing Virtual State Channels on the other hand will open the possibility to build 1:N solutions. Those will not be baked in the protocol itself but rather will be implemented on top of it, making them as flexible as needed.
The thing with 1 to many channels is that there are different approaches. Some of those are a nice fit for certain problems and not so good for others, when talking about 1 to many - there is no “one size fits all” solutiton. That’s why we’d rather keep it simple on a protocol level and let users build solutions that fit their needs best on top of it.
Cool thanks, is there a list of all open node running on the network? (including middleware), kinda how eos has the block producers be required to keep an open node.
