Hacker News Reader

Comment by toomim | Hacker News Reader

It works just fine. Existing servers, proxies, and middleboxes just pass through the response if they don't understand status 209. The braid.org site itself is running on Braid-HTTP, through a reverse proxy, and everything is peachy keen.

SSE doesn't work because it (1) doesn't support binary data, (2) assumes that versioning is linear (which doesn't work in a distributed system), and doesn't provide any way to add new headers to each response.

SSE also has an awkward encoding format, but that's neither here nor there.

View on HN

I'm not saying you can reuse the entire SSE protocol and interfaces, but why not use 200 and Content-type text/event-stream, like SSE does? Use mixed/subscription of mixed/braid if you really want, but this whole new thing, why?

I don't see what's too fundamentally different about Braid that it needs a new status code and protocol. Shouldn't SSE use 209 then?

It's possible that Braid could switch back to status code 200. I expect this choice to be revised in discussion within the IETF HTTP WG, but we haven't gotten to this level of detail yet. If I remember correctly, the switch to 209 in the current draft was to discourage middleboxes from caching braid responses, but it's possible that "Cache-Control: no-cache" does enough of this and that 209 is not necessary. I'll keep an eye out. Thanks for the thought.

As for text/event-stream -- braid responses are not text (they can contain binary updates to things like images) and they are not an "event" stream. Braid provides an "update" stream, as a stream of HTTP responses. Each response can specify an update using a status code, headers, and a body.

If we were to use SSE, we would be encoding an HTTP response, within a base64-encoding (to fit as text), within a sequence of `data: ` lines, in an "event", within an event stream, within a text/event-stream content-type, within an HTTP response. It's a lot simpler to just extend HTTP to say "instead of one response, a server can provide N responses" than to go through all this rigamorale to encode responses within an event stream within a response.

As for events vs. updates, an update may or may not describe the raw underlying events. Updates can also be summaries of many events. For instance, a normal HTTP response body provides a snapshot that summarizes all of the edits up to that point that created the resource. This is an update, but is not the raw sequence of events.

Ah, I've found the discussion on status code 209 here: https://github.com/braid-org/braid-spec/issues/16

Hope that helps.

Use mixed/braid then. My point is, reuse some of the technical decisions that were made when creating almost the exact same mechanism.

What is the point of standard decisions if they change every time?

Perhaps you mean multipart/braid? There is no mixed/* mime-type prefix that I know of.

How would your suggestion work? Can you give an example HTTP response to explain what it would look like?

The purpose of standards is interoperability. What software would this mixed/braid or multipart/braid mime-type help us be interoperable with?

> doesn't support binary data,

You could just as easily base64 encode it (or use your favorite encoding).

> assumes that versioning is linear (which doesn't work in a distributed system),

Whether you're sending SSE frames or subscription events, they arrive in the order the server sent them by virtue of being sent over TCP. Your versioning is an application-level concern, not a transport-level concern

> doesn't provide any way to add new headers to each response.

It's trivial to add headers at the application layer (literally just encode your own "header" to the start of each event). The headers don't need to be a part of the protocol.

Base64 encoding hurts performance, adding about 33% overhead. It's more efficient to send binary over HTTP directly.

> SSE frames or subscription events ... arrive in the order the server sent them by virtue of being sent over TCP.

We support situations more complex than that. Multiple clients can make simultaneous edits with multiple PUTs. They can arrive in different orders to a server that relays them to other clients. Each peer in the system needs to know which versions the edits were parented from, so they can reconstruct the version DAG and merge consistently.

> The headers don't need to be a part of the protocol.

Yes, they do. Not only headers, but also status lines, and bodies. We are streaming entire HTTP responses. A HTTP response consists of a status line, headers, and a body. We need all of these. For instance, if a resource is deleted, we need to send a new 404 status line in the update. If the version changes, we need to update the Version: header. These need to be a part of the protocol so that all peers can update themselves in the same way, otherwise you don't get consistency.

> Base64 encoding hurts performance, adding about 33% overhead. It's more efficient to send binary over HTTP directly.

Other encodings are more space efficient. But it's also the case that the purposes of Braid don't lend themselves to large binary blobs. Chances are the data still fits in a single packet.

> They can arrive in different orders to a server that relays them to other clients.

Again, whether you emit an update over SSE or a HTTP subscription doesn't change that. Both are literally just TCP connections. Whether you wrap the data as an SSE event or a piece of a 209, it'll arrive in the same way.

> Yes, they do. Not only headers, but also status lines, and bodies. We are streaming entire HTTP responses. A HTTP response consists of a status line, headers, and a body. We need all of these.

You can package that data not as in the shape of a HTTP response. You're making the choice to do it that way but there's exactly nothing that's requiring you to do it.

The value of putting it into HTTP the protocol is making the user agent be able to see a snapshot is a remote resource at any given time. But that's not the interface that HTTP exposes. fetch() or curl gives you back a stream or a buffer. If I created a subscription, streams are right out. So you'd need to get back a full buffer of the resource every time it's updated. But then you don't have data about what changed.

So now you have to get the details about those changes, which means HTTP isn't adding any value. Which is to say, if my application needs to be aware of the details of the protocol, it's not a transport protocol anymore, it's an application protocol. If the abstraction of the protocol just gives you ~the data that's sent over the wire, it's not an abstraction anymore and you're really just piping lines of data from the wire to your application logic (which is exactly what SSE is).

The only benefit that I can really see is a user agent could facilitate caching better? But then you're dipping into the territory of H2 server push.

> But it's also the case that the purposes of Braid don't lend themselves to large binary blobs.

That's not true. We want to use Braid to distribute OS updates, sending patches to multi-GB binary blobs; and for filesystem synchronization (think Dropbox/SyncThing/Resilio) with large binary files.

Braiders have put an impressive amount of work into compressing data: https://josephg.com/blog/crdts-go-brrr/. Data compression is critical, because these mutation histories can grow very large. There would be very strong resistance to a 33% overhead without a good reason.

> whether you emit an update over SSE or a HTTP subscription doesn't change that. Both are literally just TCP connections.

You're failing to consider a P2P mesh network. TCP only connects two computers. Braid enables a P2P mesh network where any peer can come and go, work offline, or switch connections, and nonetheless the whole network must synchronize with strong eventual consistency. Think distributed. Watch the distributed network partition, repartition, and reconfigure in https://braid.org/antimatter#viz. This won't make sense until you flip your mindset to distributed.

> You can package that data not as in the shape of a HTTP response.

Then we wouldn't be using HTTP. We wouldn't be able to re-use HTTP parsers and generators. We would lose a huge amount of interoperability with existing code.

It's confusing that you're arguing against using HTTP in order to use SSE -- while insinuating that using SSE means using HTTP. SSE is built on, but is not itself HTTP. It wasn't even standardized in the IETF HTTPWG. It's a way to tunnel a specific, limited, use-case of centralized, text-only, server-to-client-only event streaming over a HTTP response, without bothering to specify anything about how those events might change actual HTTP resource state. It's time to do better, and to bake that into HTTP more generally. We are making something way more powerful than SSE.

As for the rest of your comment, I am trying, but cannot understand what you are trying to say. Perhaps you could rephrase it.

> doesn't support binary data

But HTTP is a text based protocol. Why do you need binary?

> assumes that versioning is linear

What does linear mean? Afaict SSE ids are opaque strings.

> doesn't provide any way to add new headers to each response

XY problem? Do you really need HTTP headers or do you need a way to pass X from server to client?

I’m not familiar enough with the specific problem, but it’s always good to reuse as much as possible of existing infrastructure.

> But HTTP is a text based protocol.

Why do you say that? It supports binary content just fine. If that were true images would be horribly inefficient to send, like they are with smtp (which is an actual text based protocol).

It’s text by default, but you’re right. I would say it’s idiomatic to use text until needed, at least. But if the CRDT payloads allow binary it makes sense to avoid SSE.

Yes, like for images. You can't send image updates over SSE.

Reply on news.ycombinator.com