WebSocket Device #317
Description
WebSocket Device Specification
Why We Need This
We want to build a WebSocket device that can quickly push AO process results to external systems. Think live dashboards, web backends, or any API that needs instant updates when something happens. We can also filter by specific processes or messages to avoid spam.
Before we start coding, we'd love some feedback - are WebSockets actually the right tool here, or should we be looking at something else?
How It Works
This thing sits in the middle as middleware and just passes messages through to whoever's listening. No fancy processing, no delays - just straight broadcasting to keep things fast.
What It Does
The info function
Tells clients where to connect and what topics they can subscribe to:
info() ->
{ok, #{
uri => <<"ws://server:port/ws">>,
topics => [<<"topic1">>, <<"topic2">>]
}}.The cast function
Fires and forgets - sends back "OK" immediately, then handles the actual broadcasting in the background:
cast(Msg, _Opts) ->
spawn(fun() -> broadcast_message(Msg) end),
{ok, <<"OK">>}.How Clients Subscribe
Pretty straightforward - just add topics to the URL:
ws://server:port/ws?topic=topic1,topic2
Topics get created automatically based on message tags. We're thinking about adding regex support later if people need more flexible matching.
Server Setup
The WebSocket server starts up automatically when the device loads. It handles all the subscription management internally so you don't have to worry about it.
One question though - should we try to align this with the existing Hyperbeam hashpath?
Security
Right now we're keeping it wide open to make integration easy. We've thought about adding auth and permissions, but we're trying to balance security with keeping things simple and flexible.
The main concerns are:
- Don't want to make nodes less flexible
- Don't want to overcomplicate subscriptions
- Want to keep integration as painless as possible
Any thoughts on the right approach here?
Other Options We Looked At
We considered a few alternatives but they all have issues:
Webhooks - These work great for single clients but don't scale well when you have multiple subscribers wanting the same data in real-time.
Server-Sent Events - Good for real-time updates but limited when you need more complex subscriptions or want bidirectional communication.
Pre/Post-processors - We're not sure about these. Can they talk directly to external services or do they need to go through dev_relay? And can they handle dynamic subscriptions or would we need extra infrastructure?
WebSockets seem like the obvious choice for real-time, multi-client scenarios, but we're open to other ideas.
Requested Feedback
Is WebSockets the right call here? If you think there's a better approach, we'd love to hear it.