Unrelated: datastar doesn't use a two-way connection for interaction <-> updates. It uses two unconnected one-way channels: a long-lived long-lived SSE for updates, and new HTTP requests for interaction.

I didn't see guidance in the docs for routing one tab's interaction events to the backend process managing that tab's SSE. What's the recommend practice? A global, cross-server event bus? Sticky sessions with no multiprocessing, and an in-process event bus?

If a user opened the same page in two tabs, how should a datastar backend know which tab's SSE to tie an interaction event to?

It appears to be a SSE channel for each event stream returned, not one channel for all subsequent updates. So a PHP backend for instance could batch all the updates from one request, would open a new SSE channel, send the updates over that, then close it. With an in-process server like swoole or most things not PHP, you could presumably reuse the channel across requests in whatever framework-specific way makes that happen. Would probably need sticky sessions in any scaled-out deployment.

This is just what I can glean from the docs, I've never actually used datastar myself.

With DS (and HTMX) the backend is the source of truth. In the context of the blog post, the state will be made-up of: step no, file content, file path, etc. This can be stored against the session ID in a database.

So when opened on a different tab, the backend would do authentication and render the page depending on the store state.

In general, the backend must always compare the incoming state/request with stored state. E.g the current step is step 2 but the client can forces it to go to step 4 by manipulating the URL.

DS v1.0 now supports non-SSE (i.e. simple request/response interaction as well) [1]. This is done by setting appropriate content-type header.

[1] https://data-star.dev/reference/actions#response-handling