Author here. I haven't done much with the code in about 3 years. But I still have lots of plans for it.
The big thing is I want to write my own UDP protocol for it. It'll be similar to MoSH's in the sense it's optimised for text, only sends diffs and supports network roaming. But it'll be different in the sense that Browsh is a _document_ viewer first and secondly a live-updating UI. Basically, you shouldn't have to wait for a roundtrip to scroll the contents of the page.
Then with this protocol, there can of course be multiple clients. Including JS in normal browsers! (I don't know how well UDP is supported in browsers, so maybe it falls back to TCP). I think I want Browsh to be mainly a text-based browser that actually runs in normal browsers. That might sound counter-intuitive, but recall that the Browsh server runs _remotely_, the actual downloading and native rendering of a webpage is done by Firefox/Chromium in a healthy datacentre in some big city.
Hopefully I can find a way to fund a nice big farm of Browsh servers to provide a free tier. With that and the JS client, you won't even need to download an app to use Browsh, just a few Kbs of JS in any normal browser.
> The big thing is I want to write my own UDP protocol for it.
In theory WebTransport could solve both the problem of a UDP like transport (it deals with encryption and sessions as it's QUIC based, you could still do mosh like things inside it) and browser support... Sadly as https://web.dev/webtransport/#try-it-out says:
"The best way to experiment with WebTransport is to start up a compatible HTTP/3 server locally. (Unfortunately, a public reference server compatible with the latest specification is not currently available.)"
It's one of those things Google hasn't quite finished and it's unclear if they care enough to.
While what you're doing is much more appealing to mainstream as it interacts with real internet I wanted to share a loosely related PoC I've been working on for a terminal browser and custom gRPC protocol for serving terminal user interfaces over the wire.
For the terminal use-case, what would your stance be on exploiting modern terminal functionality for e.g. high-res images (cf. kitty protocol, notcurses, sixels)?
I was for a long time against that, simply because it can't be represented as text. But now I understand that sixels are just more text-based ANSI escape codes! So I'm on board again, but I'm not so personally interested in it, so it's not a priority at the moment.
> The big thing is I want to write my own UDP protocol for it. It'll be similar to MoSH's in the sense it's optimised for text, only sends diffs and supports network roaming.
Why not just run it over mosh? What's the advantage to baking it into Browsh?
The best example is the scrolling one. MoSH scrolls the buffer on the _remote_ machine and tries to send the _UI_ diff. I want my protocol to send the whole document (or at least many pages worth of it), so that scrolling can be done locally, as you would expect with a normal browser. Browsh's protocol would still send diffs, but for JS-triggered changes to the _document_ (not the UI), like for new messages in a Slack chat, or a new email in an Inbox.
> you shouldn't have to wait for a roundtrip to scroll the contents of the page
I run into this when using a large (2k) mosh terminal. Scrolling through a file is painfully slow: it seems to redownload the whole screen, even though only a small number of lines are new. Any insight?
That's exactly what I mean. It's annoying seeing as in theory the diff should have been small. But I guess it's just MoSH's algorithm not being quite clever enough. I wonder what can be learnt from video codecs in this respect?
The big thing is I want to write my own UDP protocol for it. It'll be similar to MoSH's in the sense it's optimised for text, only sends diffs and supports network roaming. But it'll be different in the sense that Browsh is a _document_ viewer first and secondly a live-updating UI. Basically, you shouldn't have to wait for a roundtrip to scroll the contents of the page.
Then with this protocol, there can of course be multiple clients. Including JS in normal browsers! (I don't know how well UDP is supported in browsers, so maybe it falls back to TCP). I think I want Browsh to be mainly a text-based browser that actually runs in normal browsers. That might sound counter-intuitive, but recall that the Browsh server runs _remotely_, the actual downloading and native rendering of a webpage is done by Firefox/Chromium in a healthy datacentre in some big city.
Hopefully I can find a way to fund a nice big farm of Browsh servers to provide a free tier. With that and the JS client, you won't even need to download an app to use Browsh, just a few Kbs of JS in any normal browser.