I've been working on-and-off on such a thing, and was hoping this would provide a useful bit of technology. Sadly, when I scrolled to the bottom it seems like they haven't got the WebRTC part working, which has always been the hardest part - it's not easy to run something like a web server in the browser.
Author here, that's correct, we haven't implemented the WebRTC binding yet. The way grim's communication works, we put REST semantics and protocol over messaging transports. We've already done it over Web Workers' postMessage API, and don't expect any trouble doing the same over WebRTC's DataChannels. In fact, the blog post's content is served by a Worker server which proxies out to a markdown file on the remote host, converts to HTML using https://github.com/chjj/marked, and responds.
Comments
I've been working on-and-off on such a thing, and was hoping this would provide a useful bit of technology. Sadly, when I scrolled to the bottom it seems like they haven't got the WebRTC part working, which has always been the hardest part - it's not easy to run something like a web server in the browser.
Author here, that's correct, we haven't implemented the WebRTC binding yet. The way grim's communication works, we put REST semantics and protocol over messaging transports. We've already done it over Web Workers' postMessage API, and don't expect any trouble doing the same over WebRTC's DataChannels. In fact, the blog post's content is served by a Worker server which proxies out to a markdown file on the remote host, converts to HTML using https://github.com/chjj/marked, and responds.