Grimwire: A RESTful Browser OS that does Peer-to-peer over WebRTC | Hacker News Reader

Grimwire: A RESTful Browser OS that does Peer-to-peer over WebRTC

blog.grimwire.com

44 pointsedtechdev8 comments

When they say it doesn't support Safari, they mean it: I can't even read the readme file!

> The backend is written on NodeJS and Redis, and will include Web APIs for users, permissions, email, and application storage with the remoteStorage protocol.

Is grimserver a hard dependency, or just an implementation of some example APIs? Could one disconnect the client and depend on different providers for auth, email, chat, etc.?

That decision was actually deprecated. Grimwire will have no backend dependencies, so it can be used anywhere.

Kudos to the author of grimwire, and many thanks for making this project open to everyone

Does someone has a vision on what will be possible to do with Grimwire OS?

I'm not the author of this, and I'm still trying to wrap my head around how it works, but one potential use for it in the future might be essentially a browser-based application platform. Visitors could run, edit, create, and host their own web applications. But it's still very early in development - there isn't a security model yet, other than sandboxing user-generated scripts using Web Workers. There are some sample apps like an RSS reader and so forth here: http://grimwire.github.io/grimwire/#_apps There was also an article on Mozilla about it a couple months ago: Building User-Extensible Webapps with Local https://hacks.mozilla.org/2013/03/building-user-extensible-w...

PageForest is another site that lets people create their own javascript applications, hosted on appengine: http://www.pageforest.com/ And other sites that let visitors create and host their own apps or games include http://pixieengine.com/ http://www.playmycode.com/ and http://scratch.mit.edu/

There's some more info about Grimwire here: http://grimwire.github.io/grimwire/

Hi edtechdev. I'm the author of grimwire - thanks for posting.

You have it pretty much covered. The intent is to use REST as a unified interface for remote services and local programs, much like Plan9 did using the file-system. The Worker programs should be compact, stateless Webservers that can be reconfigured into multiple use-cases. You can compose by doing things like embedding (UIs should be self-contained) hypermedia discovery (using programmatic link navigation) and proxying. I'd like for it to be possible to take (eg) an inbox interface program and attach it to a bash-piping backend (rather than a webmail host) to create an in-browser CLI. Not sure if that's a good idea or not, but you get the idea - a good grim app can bend.

The other major goal is to detach the Web app frontend from the back - to improve privacy, to let users improve their Web software, and to enable decentralized architectures (which I talk about in the article). A major factor in doing that is the security model, which would have to become more fine-grained than the single-origin policy. Web Workers make it possible to run untrusted code, and privacy policies can be built by monitoring HTTP traffic (all of which go through the document) but I should make it clear that there's a lot of work to do on security still, so stay away from untrusted code when you use grim 0.1.

I've still got about a month of shaping up to do, including doc-writing and getting some pre-freeze feeback from devs. The only documentation that's current is in the build (http://grimwire.github.io/grimwire/) and it's in progress. Please ignore everything else, including the stuff in the GitHub readme and wiki.

If you're in Austin, I'll likely be speaking at next month's JS/Node meetup (http://www.meetup.com/noders/) so please join us.

Dup (38 days previous): https://news.ycombinator.com/item?id=5498900

Reply on news.ycombinator.com