I'm not convinced on 209, either. There might be a better response code. See the discussion at https://github.com/braid-org/braid-spec/issues/16 https://githu

I'm not convinced on 209, either. There might be a better response code. See the discussion at https://github.com/braid-org/braid-spec/issues/16 https://github.com/braid-org/braid-spec/issues/16 Braid is not trying to be "application logic" or "transport protocol" -- it is a State Synchronization Protocol. If you can think of a more elegant method to support all of state synchronization within SSE, we're all ears! But AFAICS you end up having to embed base64-encoded HTTP responses within SSE events within HTTP responses, which is gross pile of russian dolls, where both the innermost and outermost dolls are the same type of doll -- an HTTP response! So why all the intermediate dolls? It's more elegant and simpler to extend HTTP at the root level, and say: "Instead of returning 1 HTTP response, a Braid server can return N HTTP responses, concatenated together with optional newline separators."