5 ms·

I cant help but think that this feels like webDav on steriods, and webdav never really caught on. I kind of think sometimes it makes more sense to layer on top

I cant help but think that this feels like webDav on steriods, and webdav never really caught on. I kind of think sometimes it makes more sense to layer on top of http instead of extending.

mike_hearn 2y ago
It kind of is layered on top, no? WebDAV didn't really catch on, but the general product space of remote drives did. The problem with WebDAV is that like most Web* tech (and maybe Braid) it's design by committee in the abstract. To make remote drives work well for the end user requires a fairly complicated protocol with tons of ugly edge cases. The interoperable standards from committees approach tends to fail in those situations, whereas hard driving startups that use proprietary protocols they can iterate quickly tend to win. Iteration speed > openness, when there's nothing to copy from. Standardization tends to be about bigger companies trying to commodify their competitors.
- 0x006A 2y ago
  many proprietary protocols iterate themself out of existence, just because some of them survive does not mean its the better model. Look at the video codec space, proprietary codes have long lost and have gone the way of Real Media, Windows Media Video and many others. While H.26X which is the result of design by committee are used everywhere.
  - treyd 2y ago
    It might be a different scenario with (modern) codecs where to get good use out of them it helps a lot to ship dedicated hardware. That's not true of file sync protocols.
- giovannibonetti 2y ago
  > Standardization tends to be about bigger companies trying to commodify their competitors. Didn't you mean to commodity their complements? Like when Microsoft (software company) commoditied the hardware on top of where their OS ran.
  - mike_hearn 2y ago
    No, I meant commodify their competitors. Big company has moved up the value chain and doesn't want others following them, so they standardize the tech at the level below. Now competitors are all implementing the standard and thus can't get an edge over each other, so they end up driving margins to zero via price competition and have nothing left over for innovation, whilst simultaneously reducing the bigger firm's cost by turning the lower levels they still rely on into a commodity.
toomim 2y ago
WebDAV was really complex, and required (ugh) locking for concurrent edits, which really sucks. Let's compare WebDAV with Braid for something simple like looking up the current version of the resource. In WebDAV, you have to: - Send a PROPFIND request to the URL of the resource you want to check. In the request body, specify the DAV:version-controlled-binding property you want to retrieve, using a custom XML syntax. Here's an example: PROPFIND /path/to/resource HTTP/1.1 Host: example.com Depth: 0 Content-Type: application/xml <?xml version="1.0" encoding="utf-8"?> <propfind xmlns="DAV:"> <prop> <version-controlled-binding /> </prop> </propfind> - The server responds with a 207 Multi-Status response, with XML to parse: HTTP/1.1 207 Multi-Status Content-Type: application/xml <?xml version="1.0" encoding="utf-8"?> <multistatus xmlns="DAV:"> <response> <href>/path/to/resource</href> <propstat> <prop> <version-controlled-binding> <href>/path/to/version/history</href> </version-controlled-binding> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus> This does not yet give you the version -- it tells you a separate URL that contains the version history. So now you have to query that for the version: - Send a REPORT request to that url, and in the request body, specify the DAV:version-tree report you want to retrieve: REPORT /path/to/version/history HTTP/1.1 Host: example.com Content-Type: application/xml <?xml version="1.0" encoding="utf-8"?> <version-tree xmlns="DAV:"> <prop> <version-name /> <creator-displayname /> <creation-date /> <comment /> </prop> </version-tree> - The server responds with a 207 Multi-Status, with more custom XML for you to parse: HTTP/1.1 207 Multi-Status Content-Type: application/xml <?xml version="1.0" encoding="utf-8"?> <multistatus xmlns="DAV:"> <response> <href>/path/to/version/1</href> <propstat> <prop> <version-name>1.0</version-name> <creator-displayname>John Doe</creator-displayname> <creation-date>2023-05-26T10:00:00Z</creation-date> <comment>Initial version</comment> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> <response> <href>/path/to/version/2</href> <propstat> <prop> <version-name>2.0</version-name> <creator-displayname>Jane Smith</creator-displayname> <creation-date>2023-05-27T14:30:00Z</creation-date> <comment>Updated version</comment> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus> You can find the versions in there, and if you then parse and filter to the most recent version, you can see that the current version is 2.0. That was a LOT of work! Now let's see it in Braid. To get the current version, just do a normal GET or a HEAD, and look at the Version: header in the response: Request: GET /path/to/resource HTTP/1.1 Response: HTTP 200 Ok Version: "2.0" <body of resource> That's it! It's that simple! Braid is this simple because it is baked into HTTP. It turns out that HTTP itself is already very close to a State Synchronization protocol -- it just needs a few headers, and the ability to stream updated responses when a resource changes. I encourage you to check out the spec, and see how easy it is to do things that were complicated or impossible in WebDAV: https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-b...

I cant help but think that this feels like webDav on steriods, and webdav never really caught on. I kind of think sometimes it makes more sense to layer on top of http instead of extending.

mike_hearn 2y ago

It kind of is layered on top, no? WebDAV didn't really catch on, but the general product space of remote drives did. The problem with WebDAV is that like most Web* tech (and maybe Braid) it's design by committee in the abstract. To make remote drives work well for the end user requires a fairly complicated protocol with tons of ugly edge cases. The interoperable standards from committees approach tends to fail in those situations, whereas hard driving startups that use proprietary protocols they can iterate quickly tend to win. Iteration speed > openness, when there's nothing to copy from. Standardization tends to be about bigger companies trying to commodify their competitors.

0x006A 2y ago
many proprietary protocols iterate themself out of existence, just because some of them survive does not mean its the better model. Look at the video codec space, proprietary codes have long lost and have gone the way of Real Media, Windows Media Video and many others. While H.26X which is the result of design by committee are used everywhere.
- treyd 2y ago
  It might be a different scenario with (modern) codecs where to get good use out of them it helps a lot to ship dedicated hardware. That's not true of file sync protocols.
giovannibonetti 2y ago
> Standardization tends to be about bigger companies trying to commodify their competitors. Didn't you mean to commodity their complements? Like when Microsoft (software company) commoditied the hardware on top of where their OS ran.
- mike_hearn 2y ago
  No, I meant commodify their competitors. Big company has moved up the value chain and doesn't want others following them, so they standardize the tech at the level below. Now competitors are all implementing the standard and thus can't get an edge over each other, so they end up driving margins to zero via price competition and have nothing left over for innovation, whilst simultaneously reducing the bigger firm's cost by turning the lower levels they still rely on into a commodity.

toomim 2y ago

WebDAV was really complex, and required (ugh) locking for concurrent edits, which really sucks. Let's compare WebDAV with Braid for something simple like looking up the current version of the resource. In WebDAV, you have to: - Send a PROPFIND request to the URL of the resource you want to check. In the request body, specify the DAV:version-controlled-binding property you want to retrieve, using a custom XML syntax. Here's an example: PROPFIND /path/to/resource HTTP/1.1 Host: example.com Depth: 0 Content-Type: application/xml <?xml version="1.0" encoding="utf-8"?> <propfind xmlns="DAV:"> <prop> <version-controlled-binding /> </prop> </propfind> - The server responds with a 207 Multi-Status response, with XML to parse: HTTP/1.1 207 Multi-Status Content-Type: application/xml <?xml version="1.0" encoding="utf-8"?> <multistatus xmlns="DAV:"> <response> <href>/path/to/resource</href> <propstat> <prop> <version-controlled-binding> <href>/path/to/version/history</href> </version-controlled-binding> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus> This does not yet give you the version -- it tells you a separate URL that contains the version history. So now you have to query that for the version: - Send a REPORT request to that url, and in the request body, specify the DAV:version-tree report you want to retrieve: REPORT /path/to/version/history HTTP/1.1 Host: example.com Content-Type: application/xml <?xml version="1.0" encoding="utf-8"?> <version-tree xmlns="DAV:"> <prop> <version-name /> <creator-displayname /> <creation-date /> <comment /> </prop> </version-tree> - The server responds with a 207 Multi-Status, with more custom XML for you to parse: HTTP/1.1 207 Multi-Status Content-Type: application/xml <?xml version="1.0" encoding="utf-8"?> <multistatus xmlns="DAV:"> <response> <href>/path/to/version/1</href> <propstat> <prop> <version-name>1.0</version-name> <creator-displayname>John Doe</creator-displayname> <creation-date>2023-05-26T10:00:00Z</creation-date> <comment>Initial version</comment> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> <response> <href>/path/to/version/2</href> <propstat> <prop> <version-name>2.0</version-name> <creator-displayname>Jane Smith</creator-displayname> <creation-date>2023-05-27T14:30:00Z</creation-date> <comment>Updated version</comment> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus> You can find the versions in there, and if you then parse and filter to the most recent version, you can see that the current version is 2.0. That was a LOT of work! Now let's see it in Braid. To get the current version, just do a normal GET or a HEAD, and look at the Version: header in the response: Request: GET /path/to/resource HTTP/1.1 Response: HTTP 200 Ok Version: "2.0" <body of resource> That's it! It's that simple! Braid is this simple because it is baked into HTTP. It turns out that HTTP itself is already very close to a State Synchronization protocol -- it just needs a few headers, and the ability to stream updated responses when a resource changes. I encourage you to check out the spec, and see how easy it is to do things that were complicated or impossible in WebDAV: https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-b...