6 ms·

We're about to release a new braid-text library: https://github.com/braid-org/braid-text/ https://www.npmjs.com/package/braid-text This is the easiest

by toomim 2y ago

We're about to release a new braid-text library: https://github.com/braid-org/braid-text/ https://www.npmjs.com/package/braid-text This is the easiest way to add collaborative editing to a web app. You can add it to any (req, res) handler in your nodejs app. No websocket necessary, since it extends HTTP itself! Plus, it features a new `simpleton` merge-type that requires zero history overhead on the client, and you can implement the client protocol from scratch in just 50 lines of code. There's no reason not to add collaborative editing to every user-editable string in your app now! All the network traffic is just HTTP, with an open, easy-to-read protocol that supports any OT or CRDT (currently defaulting to josephg's Diamond-Types). You can even read and write directly using the Braid-Chrome extension, which adds a devtools panel to view the version history of any Braid-HTTP resource: https://github.com/braid-org/braid-chrome https://github.com/braid-org/braid-chrome. I'm really excited about this library. We were going to announce it tomorrow (at https://braid.org/meeting-86 https://braid.org/meeting-86), but since this hacker news discussion is happening... I can't hold myself back from talking about it now!

notpushkin 2y ago
Neat! Any plans to release a Firefox extension, too? It shouldn't be too hard, IIRC the API is largely compatible.
- toomim 2y ago
  That is cool! Nobody has worked on a FireFox devtool yet, but we welcome contributions.
remram 2y ago
> No websocket necessary, since it extends HTTP itself! What does that mean? How do other clients get notified of remote changes? edit: Braid include its own SSE-like construct, completely incompatible, with a brand-new HTTP status code "209". Seems unnecessary... How does that work with existing servers/proxies/middleboxes?
- toomim 2y ago
  It works just fine. Existing servers, proxies, and middleboxes just pass through the response if they don't understand status 209. The braid.org site itself is running on Braid-HTTP, through a reverse proxy, and everything is peachy keen. SSE doesn't work because it (1) doesn't support binary data, (2) assumes that versioning is linear (which doesn't work in a distributed system), and doesn't provide any way to add new headers to each response. SSE also has an awkward encoding format, but that's neither here nor there.
  - klabb3 2y ago
    > doesn't support binary data But HTTP is a text based protocol. Why do you need binary? > assumes that versioning is linear What does linear mean? Afaict SSE ids are opaque strings. > doesn't provide any way to add new headers to each response XY problem? Do you really need HTTP headers or do you need a way to pass X from server to client? I’m not familiar enough with the specific problem, but it’s always good to reuse as much as possible of existing infrastructure.
    - __david__ 2y ago
      > But HTTP is a text based protocol. Why do you say that? It supports binary content just fine. If that were true images would be horribly inefficient to send, like they are with smtp (which is an actual text based protocol).
      - toomim 2y ago
        Yes, like for images. You can't send image updates over SSE.
      - klabb3 2y ago
        It’s text by default, but you’re right. I would say it’s idiomatic to use text until needed, at least. But if the CRDT payloads allow binary it makes sense to avoid SSE.
  - remram 2y ago
walterbell 2y ago
Braid and Statebus, https://stateb.us/what https://stateb.us/what > Every piece of state has a state:// URL. You can re-use another site's state as easily as linking to a page with today's web. Websites can build on top of one another, and collaboratively outcompete today's centralized monopolies. If multiple businessses are cooperating to process state owned by multiple websites, how does Statebus envision the encapsulation of state for {user, device, app, feature, business}? Could some state be opaque/encrypted? What's the best place to learn more about the use cases below, https://stateb.us/why https://stateb.us/why Built-in offline mode Collaborative editing by default Website internal state is opened Make a new user interface Implement a blockchain on top of the web Enables better Email protocol: decentralized, simpler, realtime, spam-free, encrypted Improves source control: Source code becomes state—replaces git with the web protocol itself Any user can edit source for any website, and have their own version Editable, brancheable, forkable inline
- snthpy 2y ago
  That is wild! I'd also like to learn more about this. The language is a bit, idk superlative, but if it does what it says then it would be great.
  - toomim 2y ago
    Yes, when I wrote that stateb.us/what page, my intent was to express the aspirational vision of statebus. It soon became clear that, in order for the vision to succeed, we needed the network protocol to become a widely-used standard. Thus began my Braid work. I started approaching the IETF to learn how to standardize State Synchronization in HTTP. I ran across this HN comment by JosephG [1] making a call to the same mission. I sent him an email, we decided to team up, and we went to dwebcamp in California and then IETF in Montreal together, and made a presentation to the HTTPWG proposing to extend HTTP into a state sync protocol. We got an enthusiastic reception, and I have been working on it ever since. The HTTP extension is getting into pretty good shape, and we're now manifesting the promises on that /what page. They aren't all production-ready (e.g. no blockchains built on statebus/braid yet), but they are coming true at a steady clip! [1] https://news.ycombinator.com/item?id=19816648 https://news.ycombinator.com/item?id=19816648

by toomim 2y ago

notpushkin 2y ago

Neat! Any plans to release a Firefox extension, too? It shouldn't be too hard, IIRC the API is largely compatible.

toomim 2y ago
That is cool! Nobody has worked on a FireFox devtool yet, but we welcome contributions.

remram 2y ago

> No websocket necessary, since it extends HTTP itself! What does that mean? How do other clients get notified of remote changes? edit: Braid include its own SSE-like construct, completely incompatible, with a brand-new HTTP status code "209". Seems unnecessary... How does that work with existing servers/proxies/middleboxes?

toomim 2y ago
It works just fine. Existing servers, proxies, and middleboxes just pass through the response if they don't understand status 209. The braid.org site itself is running on Braid-HTTP, through a reverse proxy, and everything is peachy keen. SSE doesn't work because it (1) doesn't support binary data, (2) assumes that versioning is linear (which doesn't work in a distributed system), and doesn't provide any way to add new headers to each response. SSE also has an awkward encoding format, but that's neither here nor there.
- klabb3 2y ago
  > doesn't support binary data But HTTP is a text based protocol. Why do you need binary? > assumes that versioning is linear What does linear mean? Afaict SSE ids are opaque strings. > doesn't provide any way to add new headers to each response XY problem? Do you really need HTTP headers or do you need a way to pass X from server to client? I’m not familiar enough with the specific problem, but it’s always good to reuse as much as possible of existing infrastructure.
  - __david__ 2y ago
    > But HTTP is a text based protocol. Why do you say that? It supports binary content just fine. If that were true images would be horribly inefficient to send, like they are with smtp (which is an actual text based protocol).
    - toomim 2y ago
      Yes, like for images. You can't send image updates over SSE.
    - klabb3 2y ago
      It’s text by default, but you’re right. I would say it’s idiomatic to use text until needed, at least. But if the CRDT payloads allow binary it makes sense to avoid SSE.
- remram 2y ago

walterbell 2y ago

Braid and Statebus, https://stateb.us/what https://stateb.us/what > Every piece of state has a state:// URL. You can re-use another site's state as easily as linking to a page with today's web. Websites can build on top of one another, and collaboratively outcompete today's centralized monopolies. If multiple businessses are cooperating to process state owned by multiple websites, how does Statebus envision the encapsulation of state for {user, device, app, feature, business}? Could some state be opaque/encrypted? What's the best place to learn more about the use cases below, https://stateb.us/why https://stateb.us/why Built-in offline mode Collaborative editing by default Website internal state is opened Make a new user interface Implement a blockchain on top of the web Enables better Email protocol: decentralized, simpler, realtime, spam-free, encrypted Improves source control: Source code becomes state—replaces git with the web protocol itself Any user can edit source for any website, and have their own version Editable, brancheable, forkable inline

snthpy 2y ago
That is wild! I'd also like to learn more about this. The language is a bit, idk superlative, but if it does what it says then it would be great.
- toomim 2y ago
  Yes, when I wrote that stateb.us/what page, my intent was to express the aspirational vision of statebus. It soon became clear that, in order for the vision to succeed, we needed the network protocol to become a widely-used standard. Thus began my Braid work. I started approaching the IETF to learn how to standardize State Synchronization in HTTP. I ran across this HN comment by JosephG [1] making a call to the same mission. I sent him an email, we decided to team up, and we went to dwebcamp in California and then IETF in Montreal together, and made a presentation to the HTTPWG proposing to extend HTTP into a state sync protocol. We got an enthusiastic reception, and I have been working on it ever since. The HTTP extension is getting into pretty good shape, and we're now manifesting the promises on that /what page. They aren't all production-ready (e.g. no blockchains built on statebus/braid yet), but they are coming true at a steady clip! [1] https://news.ycombinator.com/item?id=19816648 https://news.ycombinator.com/item?id=19816648