2012/02/24 pfraze
Making meaningful interactions between distributed networks is an interesting problem. There are a couple existing projects, including shared protocols like tent.io, and shared software like diaspora. Local is focused on an approach that hasn't received a lot of attention yet: the browser's program model.
their applications and apply security policies by domain. It's safe, but it keeps programs from composing on the client-side. There's no pipe in the browser. With client-side composition, networks could deliver software to proxy to them. Rather than get everybody on the same protocol, Local puts them in a shared environment which the user can configure.
The advantage is that the user can control the software. If a service doesnt match the program, the user can introduce a go-between. If they don't like the site, they can replace the UI and data services. You're not stuck with what you're given. This improves privacy; users can choose private back-ends. Third-party apps can also run on a host without involving another remote service, which is good for applications like Mint.
After a year of development, Local has been released, along with a preview version of a web desktop environment called Grimwire. Here's a quick breakdown of how it works, and what you can do with it.
you need a sandbox on the page which won't pollute trusted code. It's not enough to use iframes or Caja, because they share the thread with the document. That leaves Web Workers, but Workers don't have access to the DOM, so you need a good messaging protocol to work with them. That's complicated further by the async-only of postMessage; to my thinking, you can't finagle a worker to behave like a typical client-side app.
Fortunately, it turns out these conditions are a lot like a web host– detached, and passing messages over a wire. The wire's just a lot shorter here. So Local sets up a protocol which works like HTTP, and provides an ajax library that can target it. That ends up handling a lot of the problem; many questions can be answered by asking, "how does the Web solve it?"
HTTP is the unified interface to Local's architecture. Behavior is composed using links and forms, like in the Web. Among many things, this keeps you from event-binding: links and forms target app URLs, and apps serve HTML back. More broadly, it makes HATEOAS the foundation of the environment, which is important for composition.
Unfortunately, this choice limits the richness of the app, because there's effectively no client software. How do you write a color picker, for instance? You need to modify individual elements, and servers can only respond to requests. The first thing I tried was a UI server hosted from the document-- basically the same thing that Xwindows does. That really confused the flow (your app would make requests to render) which is the complaint I heard about X. So I dropped that and instead created a "common client," which adds a few behaviors and directives to the HTML. It is still less rich than direct document access, but it's able to do things like realtime updates, so I think it'll work. The constraint is interesting anyway; with CSP blocking inline CSS and JS, the challenge becomes making a strong declarative UI library to leverage. Because the common client is moddable by the host, there's room to experiment.
Security policies are handled by the document, which has a hook function to route traffic. If an origin is trying to reach a restricted target, the document sends back a 401 or 403. Header cleaning can happen here too-- the environment can pull out the cookies and manage sessions itself. To load an app, you post to the app server. Client regions track the domain which served their content, so security decisions can be made by that. In the case of app loading, the appserver gives a confirmation interface, which the environment has as the only trusted executor of an app load.
The software to this is packaged under Local. You can use it to run user applications, or just as a way to structure your client-side. You can find documentation here.
is a general-purpose environment for Local. The software's not ready, but it's previewable. It's meant to be an easy-to-setup, easy-to-use web desktop which users can mod, customize, and configure into a distributed network.
WebRTC makes it possible to communicate horizontally between clients, allowing networks to be built off of launching points (the announcing services). By binding a datachannel as a local server, users can contact the apps running on their peer's browser. This enables communication without having to develop an intermediary service, and further reduces the load for service hosts. In this configuration, logging is not required; because the data is pushed to the clients, there's no need to store it on a single server until a pull. The clients can choose whether to store it or not, on a host of their choosing (including local storage or, soon, the file-system).
Because we're combining software from different origins, it becomes important to elegantly configure them into a cohesive whole. The primary tool for this is the Intent, which is represented by draggable icons. Intents are a bit like pre-formed requests; the user configures which app handles it, and then you drag the intent onto a context to form the rest of the request. That means your apps don't need chrome or any secondary UIs-- no like or share buttons, no comment boxes, etc. Instead, the user drags "Like," "Share," or "Comment" onto the interface, and the liking, sharing, or commenting programs start. Apps can fill the Link headers of their responses to provide more contextual information. Eventually, intents will be stackable; Clone+Fetch Source+Edit would be a way to view an app's source from a new region.
Grimwire is v0.1, only an alpha preview for interested developers. If you want to join the project, email me at pfrazee@gmail.com and tell me what your area of interest is. On the roadmap for the coming versions:
- An extended standard UI library, built off of Bootstrap
- Visual styling and animations
- Capability permissioning for programs
- User storage in Couch, including environment configs, script serving, personal data, and relevant data permissioning
- Core applications, including all social tools (mail, feeds, photo-sharing, etc) and the IDE
to contact me for help and to discuss the roadmap. If you find a bug, please log an issue, then refer to that issue if submitting a pull request.
You can find relevant links below. Thanks for reading, and happy computing. ~pfraze
Primary sites:
Repositories: