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

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