24 ms·

I dont get it. What would I use this for? (Honest question. Im probably not smart enough to get it)

by victorbjorklund 2y ago

chronicler 2y ago
same reason you'd use HTTP, it's a superset of HTTP
- toomim 2y ago
  Yes, and to elaborate — for any HTTP usage with dynamic state. HTTP was invented for static pages, that were written by hand, and rarely changed. But today's web has dynamic pages, driven by javascript and databases, and users expect them to update in realtime. Braid-HTTP adds support for dynamic state to HTTP.
- victorbjorklund 2y ago
  I still dont get it. Is this to sync two servers between each other?
  - whilenot-dev 2y ago
    From the article: > Together, these features enable a web resource to synchronize automatically across multiple clients, servers and proxies, and support arbitrary simultaneous edits by multiple writers, under arbitrary network delays and partitions, while guaranteeing consistency using an OT, CRDT, or other algorithm. So, you'd use it if you want to "support arbitrary simultaneous edits by multiple writers, under arbitrary network delays and partitions, while guaranteeing consistency", for example for apps that want to support collaborative editing. Braid wants to turn state transfer (like in RESTful API designs - Representational State Transfer) into a kind of synchronization transfer for state. Currently, state synchronization is handled on the state management layer of each individual application, and API calls just transfer that state, but Braid wants to have it solved as an extension to HTTP libraries on the API layer of an application AFAICS.
    - toomim 2y ago
      Yes, or even more simply: Let's say that your client runs GET /some-json, and that JSON gets updated, and the client wants to get the updates. Right now, your options are: 1. Re-run the GET /some-json again from the client (polling) 2. Start a websocket, and invent some custom protocol over the websocket to let the client subscribe to /some-json. With Braid, you just do: GET /some-json Subscribe: true And the client will automatically get the updates, within HTTP. The Braid-HTTP ponyfill library abstracts the details behind a normal fetch() for you, until browsers implement it. Today, we tend to use HTTP for static assets, and then switch to a websocket or SSE or something whenever things get dynamic. That sucks! We lose the standard of HTTP! Braid lets you keep using HTTP, even for your dynamic assets. It also solves issues in caching. Instead of using max-age heuristics, we have actual real versioning! And yes— the protocol generalizes all the way to full-peer-to-peer multi-writer CRDT/OT algorithms. But start simple!
      - whilenot-dev 2y ago
        Frankly, your explanation isn't any simpler, quite the contrary. > That sucks! We lose the standard of HTTP! Why does this suck? WebSockets or SSEs are also standardized. > the protocol generalizes all the way to full-peer-to-peer multi-writer Why "peer-to-peer"? While Braid can be used in a local-first setting and probably do peer-to-peer, that isn't the focus here. The focus is to help application developers to not get into the shenanigans of CRDTs and distributed algorithms etc., but solve those things already via polyfills.
        toomim 2y ago
        WebSockets and SSE are standards in the same way that TCP is a standard -- if you use them, you are still defining an ad-hoc protocol on top to subscribe to state and publish new state. HTTP is a standard on top of TCP. It provides a higher-level abstraction than a socket -- the abstraction of State Transfer. When you use a WebSocket, you're back to a low-level socket, and have to redefine "state", and the methods to get it, put it, and subscribe to it. Since each web programmer defines those methods in a different way, his state gets hidden behind his own non-standard protocol. There is no way for website A to re-use the state on website B, for instance, without learning website B's custom WebSocket protocol and re-implementing it perfectly. CDNs and other caches cannot handle WebSocket traffic. But if you use a standard like Braid-HTTP, they can cache your dynamic assets along with your static assets.
  - toomim 2y ago
    You could sync two servers. Or you could sync a server with clients. Braid is transitioning HTTP into a peer-to-peer world, where the distinction between clients and servers doesn't matter.
    - victorbjorklund 2y ago
      Could you call it websockets without websockets?
      - toomim 2y ago
        In some sense, you could! The reason is that almost every use WebSockets is actually for Synchronizing State. What you really want to do is to synchronize state. Braid is a protocol for doing just that. So you don't need to turn to WebSockets anymore!
        victorbjorklund 2y ago
        I wonder if Braid could be a transport layer for Phoenix Liveview. It uses Websockets but falls back to long-polling if websockets isnt available.
        toomim 2y ago
        Yes! Phoenix Liveview is very similar to the Statebus project (https://stateb.us https://stateb.us) that inspired Braid. Braid was the protocol that Statebus needed, and Phoneix Liveview is one of the most exciting projects in the Statebus space that I know! I think we are working from a common inspiration!
laminatedsmore 2y ago
I didn't get this either until I looked at the linked doc, which breaks it down more obviously imo (section 6.1 for examples). Looks interesting to me, seems nice to be able to handle refreshing content with pure http as described here rather than with web sockets. https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http#section-6.1 https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-b...
sesm 2y ago
From what I understood, it's a protocol for exposing a tree of files for synchronization and concurrent editing, similar to WebDAV.

I dont get it. What would I use this for? (Honest question. Im probably not smart enough to get it)

chronicler 2y ago

same reason you'd use HTTP, it's a superset of HTTP

toomim 2y ago
Yes, and to elaborate — for any HTTP usage with dynamic state. HTTP was invented for static pages, that were written by hand, and rarely changed. But today's web has dynamic pages, driven by javascript and databases, and users expect them to update in realtime. Braid-HTTP adds support for dynamic state to HTTP.
victorbjorklund 2y ago
I still dont get it. Is this to sync two servers between each other?
- whilenot-dev 2y ago
  From the article: > Together, these features enable a web resource to synchronize automatically across multiple clients, servers and proxies, and support arbitrary simultaneous edits by multiple writers, under arbitrary network delays and partitions, while guaranteeing consistency using an OT, CRDT, or other algorithm. So, you'd use it if you want to "support arbitrary simultaneous edits by multiple writers, under arbitrary network delays and partitions, while guaranteeing consistency", for example for apps that want to support collaborative editing. Braid wants to turn state transfer (like in RESTful API designs - Representational State Transfer) into a kind of synchronization transfer for state. Currently, state synchronization is handled on the state management layer of each individual application, and API calls just transfer that state, but Braid wants to have it solved as an extension to HTTP libraries on the API layer of an application AFAICS.
  - toomim 2y ago
    Yes, or even more simply: Let's say that your client runs GET /some-json, and that JSON gets updated, and the client wants to get the updates. Right now, your options are: 1. Re-run the GET /some-json again from the client (polling) 2. Start a websocket, and invent some custom protocol over the websocket to let the client subscribe to /some-json. With Braid, you just do: GET /some-json Subscribe: true And the client will automatically get the updates, within HTTP. The Braid-HTTP ponyfill library abstracts the details behind a normal fetch() for you, until browsers implement it. Today, we tend to use HTTP for static assets, and then switch to a websocket or SSE or something whenever things get dynamic. That sucks! We lose the standard of HTTP! Braid lets you keep using HTTP, even for your dynamic assets. It also solves issues in caching. Instead of using max-age heuristics, we have actual real versioning! And yes— the protocol generalizes all the way to full-peer-to-peer multi-writer CRDT/OT algorithms. But start simple!
    - whilenot-dev 2y ago
      Frankly, your explanation isn't any simpler, quite the contrary. > That sucks! We lose the standard of HTTP! Why does this suck? WebSockets or SSEs are also standardized. > the protocol generalizes all the way to full-peer-to-peer multi-writer Why "peer-to-peer"? While Braid can be used in a local-first setting and probably do peer-to-peer, that isn't the focus here. The focus is to help application developers to not get into the shenanigans of CRDTs and distributed algorithms etc., but solve those things already via polyfills.
      - toomim 2y ago
        WebSockets and SSE are standards in the same way that TCP is a standard -- if you use them, you are still defining an ad-hoc protocol on top to subscribe to state and publish new state. HTTP is a standard on top of TCP. It provides a higher-level abstraction than a socket -- the abstraction of State Transfer. When you use a WebSocket, you're back to a low-level socket, and have to redefine "state", and the methods to get it, put it, and subscribe to it. Since each web programmer defines those methods in a different way, his state gets hidden behind his own non-standard protocol. There is no way for website A to re-use the state on website B, for instance, without learning website B's custom WebSocket protocol and re-implementing it perfectly. CDNs and other caches cannot handle WebSocket traffic. But if you use a standard like Braid-HTTP, they can cache your dynamic assets along with your static assets.
- toomim 2y ago
  You could sync two servers. Or you could sync a server with clients. Braid is transitioning HTTP into a peer-to-peer world, where the distinction between clients and servers doesn't matter.
  - victorbjorklund 2y ago
    Could you call it websockets without websockets?
    - toomim 2y ago
      In some sense, you could! The reason is that almost every use WebSockets is actually for Synchronizing State. What you really want to do is to synchronize state. Braid is a protocol for doing just that. So you don't need to turn to WebSockets anymore!
      - victorbjorklund 2y ago
        I wonder if Braid could be a transport layer for Phoenix Liveview. It uses Websockets but falls back to long-polling if websockets isnt available.
        toomim 2y ago
        Yes! Phoenix Liveview is very similar to the Statebus project (https://stateb.us https://stateb.us) that inspired Braid. Braid was the protocol that Statebus needed, and Phoneix Liveview is one of the most exciting projects in the Statebus space that I know! I think we are working from a common inspiration!

laminatedsmore 2y ago

I didn't get this either until I looked at the linked doc, which breaks it down more obviously imo (section 6.1 for examples). Looks interesting to me, seems nice to be able to handle refreshing content with pure http as described here rather than with web sockets. https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http#section-6.1 https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-b...

sesm 2y ago

From what I understood, it's a protocol for exposing a tree of files for synchronization and concurrent editing, similar to WebDAV.