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.
> 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.