Is it websockets, SSE, something else?

According to this it is based on SSE:

Congrats Bart! This is huge. Also great to see with included.

POST up, SSE down. No WebSockets.

Thanks @jam! Yeah, with was a great addition to finally land.

When you say POST up, SSE down, do you mean all down stream messages are coming from SSE? In other word, does the reply from POST carry meaningful messages? If they don’t, do you need to have some extra metadata to keep track of the causality between the POST and the resulting message from the SSE channel? If both reply of POST and SSE carry messages, do you need to worry about ordering difference caused by 2 different channels?

Here’s the full flow:

A command is a plain POST to /hologram/command. The client sends the command name, params, and target component, the server runs your command/3 handler, and the resulting action comes back in that same response body.

That round trip is async with respect to the event loop: the client fires the POST as a fetch and keeps running, and when the response resolves the action is scheduled onto the normal action queue, like any other action. So “comes back in the response” means in-band rather than over a separate channel, not blocking.

SSE handles the other direction, broadcasting. Subscribed clients hold open an EventSource stream, and a broadcast goes out via pub/sub to every subscribed instance, which runs the matching handler locally.

The two meet in one place: if a command broadcasts on a channel the originating instance is itself subscribed to, that broadcast piggy-backs on the POST response too (a self-echo), and the instance is dropped from the SSE fan-out for it. So the originator gets both its command’s result and its own broadcasts back in the one response it’s already awaiting, and SSE only carries broadcasts out to the other clients.

Thanks for the explanation. My concern is that the server and the different client can see events in different order. Let’s say client A broadcasted message_a and client broadcasted message_b, each will have a corresponding outcome. Will it be possible that client A see outcome_a then outcome_b, but client B see outcome_b then outcome_a?

Also, let’s assume the server side see message_b before message_a and compute outcome_b before outcome _a. However, outcome_a may reach client A sooner than outcome_b (different channels, no enforced order). Will it confuse client A?

Both can happen, yes. The realtime layer is an abstraction over pub/sub, so it’s fire-and-forget with no ordering guarantee, the same semantics as Phoenix.PubSub or Phoenix.Channels. When you use it, ordering and data consistency are yours to manage.

That’s deliberate, and it’s exactly the gap the upcoming Local-First auto-sync data layer fills (I touched on this briefly in my ElixirConf EU 2026 talk). Instead of broadcasting actions, you subscribe to state, and the framework handles ordering and consistency for you. It will most likely be built on top of this same realtime layer.

The two are complementary, not either-or. Even once auto-sync lands, the raw realtime layer keeps its place for ephemeral, high-frequency events like cursor tracking, typing indicators, or live reactions, where each update supersedes the last and ordering or persistence would just be overhead.

There is still a difference. With Phoenix.Channel, I can manage ordering and data consistency at the server side, where I was better equipped. In your case, the hard work would need to happen on the client side.

By the way, I am developing something in a similar vein (in a much reduced scope, of course). I also use 2 communication channels (one POST for upstream and one long poll for downstream). In my design, all downstream communications happen in the downstream channel and the replies of POST carry no payload.