4 ms·

IETF draft proposal to extend HTTP for efficient state synchronization, which could improve UX on slow networks, https://news.ycombinator.com/item?id=40480016 h

IETF draft proposal to extend HTTP for efficient state synchronization, which could improve UX on slow networks, https://news.ycombinator.com/item?id=40480016 https://news.ycombinator.com/item?id=40480016 The Braid Protocol allows multiple synchronization algorithms to interoperate over a common network protocol, which any synchronizer's network messages can be translated into.. The current Braid specification extends HTTP with two dimensions of synchronization: Level 0: Today's HTTP Level 1: Subscriptions with Push Updates Level 2: P2P Consistency (Patches, Versions, Merges) Even though today's synchronizers use different protocols, their network messages convey the same types of information: versions in time, locations in space, and patches to regions of space across spans of time. The composition of any set of patches forms a mathematical structure called a braid—the forks, mergers, and re-orderings of space over time. Hope springs eternal!

YoshiRulz 2y ago
This sounds suspiciously like Matrix. Does is required buy-in from user agents or will it benefit existing browsers once implemented?
- walterbell 2y ago
  From https://braid.org/ https://braid.org/ Braid is backwards-compatible with today's web, works in today's browsers, and is easy to add to existing web applications.. You can use Braid features in Chrome with the Braid-Chrome extension. Demo of Statebus+Braid sync on existing browsers: https://stateb.us/#demos https://stateb.us/#demos
klabb3 2y ago
Grump take: More complex technology will not fix a business-social problem. In fact, you have to go out of your way to make things this shitty. It’s not hard to build things with few round trips and less bloat, it’s much easier. The bloat is there for completely different reasons. Sometimes the bloat is unnoticeable on juicy machines and fast internet close to the DC. You can simulate that easily, but it requires the company to care. Generally, ad-tech and friends cares very little about small cohorts of users. In fact, the only reason they care about end users at all is because they generate revenue for their actual customers, ie the advertisers.
- pnt12 2y ago
  > Generally, ad-tech and friends cares very little about small cohorts of users. Sure, and it will keep being that way. But if this gets improved at the transport layer, seems like a win. As an analogy, if buses are late because roads are bumpy and drivers are lousy, fixing the bumpy road may help, even if drivers don't change their behavior.
  - meindnoch 2y ago
    >As an analogy, if buses are late because roads are bumpy and drivers are lousy, fixing the bumpy road may help, even if drivers don't change their behavior No. It will make things worse, because now lousy drivers are no longer constrained by the bumpy road, so they will become even lousier. Case in point: software is shittier than ever, despite the 100x increase in computer performance since the 90s.
  - marcosdumay 2y ago
    > fixing the bumpy road may help It really wouldn't. Lousy drivers are a way thinner bottleneck than the roads. But it will improve the services where the drivers are good. If the protocol is actually any good (its goals by themselves already make me suspicious it won't be), the well-designed web-apps out there can become even better designed. But it absolutely won't improve the situation people are complaining about.
  - klabb3 2y ago
    > But if this gets improved at the transport layer, seems like a win. What do you mean? TCP and HTTP is already designed for slow links with packet loss, it’s old reliable tech from before modern connectivity. You just have to not pull in thousands of modules in the npm dep tree and add 50 microservice bloatware, ads and client side “telemetry”. You set your cache-control headers and etags, and for large downloads you’ll want range requests. Perhaps some lightweight client side retry logic in case of PWAs. In extreme cases like Antarctica maybe you’d tune some tcp kernel params on the client to reduce RTTs under packet loss. There is nothing major missing from the standard decades old toolbox. Of course it’s not optimal, the web isn’t perfect for offline hybrid apps. But for standard things like reading the news, sending email, chatting, you’ll be fine.
meindnoch 2y ago
Yes, please! Even more layers of needlessly complex crap will definitely improve things!
- walterbell 2y ago
  > needlessly complex The optional Braid extension can _reduce_ complexity for offline-first apps, e.g. relative to WebDAV, https://news.ycombinator.com/item?id=40482610 https://news.ycombinator.com/item?id=40482610 You might be surprised at just how elegantly HTTP extends into a full-featured synchronization protocol. A key to this elegance is the Merge-Type: this is the abstraction that allows a single synchronization algorithm to merge across multiple data types. As an application programmer, you will specify both the data types of your variables (e.g. int, string, bool) and also the merge-types (e.g. "this merges as a bank account balance, or a LWW unique ID, or a collaborative text field"). This is all the application programmer needs to specify. The rest of the synchronization algorithm gets automated by middleware libraries that the programmer can just use and rely upon, like his compiler, and web browser. I'd encourage you to check out the Braid spec, and notice how much we can do with how little. This is because HTTP already has almost everything we need. Compare this with the WebDAV spec, for instance, which tries to define versioning on top of HTTP, and you'll see how monstrous the result becomes. Example here: https://news.ycombinator.com/item?id=40481003 https://news.ycombinator.com/item?id=40481003

YoshiRulz 2y ago

This sounds suspiciously like Matrix. Does is required buy-in from user agents or will it benefit existing browsers once implemented?

walterbell 2y ago
From https://braid.org/ https://braid.org/ Braid is backwards-compatible with today's web, works in today's browsers, and is easy to add to existing web applications.. You can use Braid features in Chrome with the Braid-Chrome extension. Demo of Statebus+Braid sync on existing browsers: https://stateb.us/#demos https://stateb.us/#demos

klabb3 2y ago

Grump take: More complex technology will not fix a business-social problem. In fact, you have to go out of your way to make things this shitty. It’s not hard to build things with few round trips and less bloat, it’s much easier. The bloat is there for completely different reasons. Sometimes the bloat is unnoticeable on juicy machines and fast internet close to the DC. You can simulate that easily, but it requires the company to care. Generally, ad-tech and friends cares very little about small cohorts of users. In fact, the only reason they care about end users at all is because they generate revenue for their actual customers, ie the advertisers.

pnt12 2y ago
> Generally, ad-tech and friends cares very little about small cohorts of users. Sure, and it will keep being that way. But if this gets improved at the transport layer, seems like a win. As an analogy, if buses are late because roads are bumpy and drivers are lousy, fixing the bumpy road may help, even if drivers don't change their behavior.
- meindnoch 2y ago
  >As an analogy, if buses are late because roads are bumpy and drivers are lousy, fixing the bumpy road may help, even if drivers don't change their behavior No. It will make things worse, because now lousy drivers are no longer constrained by the bumpy road, so they will become even lousier. Case in point: software is shittier than ever, despite the 100x increase in computer performance since the 90s.
- marcosdumay 2y ago
  > fixing the bumpy road may help It really wouldn't. Lousy drivers are a way thinner bottleneck than the roads. But it will improve the services where the drivers are good. If the protocol is actually any good (its goals by themselves already make me suspicious it won't be), the well-designed web-apps out there can become even better designed. But it absolutely won't improve the situation people are complaining about.
- klabb3 2y ago
  > But if this gets improved at the transport layer, seems like a win. What do you mean? TCP and HTTP is already designed for slow links with packet loss, it’s old reliable tech from before modern connectivity. You just have to not pull in thousands of modules in the npm dep tree and add 50 microservice bloatware, ads and client side “telemetry”. You set your cache-control headers and etags, and for large downloads you’ll want range requests. Perhaps some lightweight client side retry logic in case of PWAs. In extreme cases like Antarctica maybe you’d tune some tcp kernel params on the client to reduce RTTs under packet loss. There is nothing major missing from the standard decades old toolbox. Of course it’s not optimal, the web isn’t perfect for offline hybrid apps. But for standard things like reading the news, sending email, chatting, you’ll be fine.

meindnoch 2y ago

Yes, please! Even more layers of needlessly complex crap will definitely improve things!

walterbell 2y ago
> needlessly complex The optional Braid extension can _reduce_ complexity for offline-first apps, e.g. relative to WebDAV, https://news.ycombinator.com/item?id=40482610 https://news.ycombinator.com/item?id=40482610 You might be surprised at just how elegantly HTTP extends into a full-featured synchronization protocol. A key to this elegance is the Merge-Type: this is the abstraction that allows a single synchronization algorithm to merge across multiple data types. As an application programmer, you will specify both the data types of your variables (e.g. int, string, bool) and also the merge-types (e.g. "this merges as a bank account balance, or a LWW unique ID, or a collaborative text field"). This is all the application programmer needs to specify. The rest of the synchronization algorithm gets automated by middleware libraries that the programmer can just use and rely upon, like his compiler, and web browser. I'd encourage you to check out the Braid spec, and notice how much we can do with how little. This is because HTTP already has almost everything we need. Compare this with the WebDAV spec, for instance, which tries to define versioning on top of HTTP, and you'll see how monstrous the result becomes. Example here: https://news.ycombinator.com/item?id=40481003 https://news.ycombinator.com/item?id=40481003