Grimwire/Local.js 0.4 beta released

[Paul Frazee]

Hey guys,

I mentioned a few threads back that I had a p2p chat web application that unhosted could use. The software to back that (grimwire and localjs) are tagged 0.4 for public beta, so the chat app is usable now (though it certainly needs some features still).

Release post for grim/local: http://blog.grimwire.com/posts/grimwire0.4

and the chat app: http://chat.grimwire.com/

Let me know if you run into any bugs or have any usability suggestions. I'm going to whip together a server framework soon. It would be fairly trivial to implement the remote storage spec on a peer-server and try hosting to other apps over webrtc. If that seems interesting, I can put together a proof of concept once my framework is done.

Cheers,

Paul

[Paul Frazee]

I went ahead and made a small proof-of-concept.

Go to http://testapp.grimwire.com/example/grim/

for your remotestorage user, put pfraze@localpage

you'll be redirected to remotestorage.grimwire.com to do auth - use "asdfasdf" as the password

When you get back, you'll be getting/putting to a server running on the page. You can verify that by watching the network tab - no traffic. It stores the data in localstorage.

You could extend the concept further to host remoteStorage over webrtc, if anybody's interested. The benefit of that would be, instead of running reStore, you could open a remoteStorage host app in the browser and let it be the provider for other tabs and devices. There'd be some rough edges to smooth - eg redirecting for oauth wouldnt work - but it's a possibility.

Here's the commit diff for this.

https://github.com/pfraze/remotestorage.js/commit/93443867722de1f64bd84efb66c6a9014a2a4ff6

In addition to localjs, I used servware, which is the framework I mentioned I was whipping up.

I'll keep the demo running for a week or so.

Paul

[pir...@gmail.com]

Could you explain more in detail about how do you think remoteStorage over WebRTC would be done?

--
 
---
You received this message because you are subscribed to the Google Groups "Unhosted Web Apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unhosted+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Paul Frazee]

Sure. I'll break it into usability and technical.

Technical.

The first task would be to replace XHR with localjs so that RTC peers could be targeted. It looks like remotestorage.js does binary data, which localjs doesn't fully support yet, so I'd need to finish implementing that.

The second task would be to implement the a localjs server for the remotestorage spec. Not too hard.

The third task would be dealing with incompatibilities -- this would need some consideration ahead of time, because there might be a blocker. Like I said, the OAuth redirect wouldn't work. Localjs also assigns webrtc peer URIs using a scheme that looks like this: "httpl://us...@relayhost.com!apphost.com". That would make the login a bit awkward - pfraze@pfraze@grimwire.net!remotestorageapp.com? Probably not a good idea. That said, Grimwire/Local.js have auto-configuration tools that might make that login unnecessary (explained below).

After all that, most of the software should work as before. The localjs servers are drop-in replacements for traditional web hosts, so remotestorage would continue to work with http servers and the new httpl servers.

Usability.

Grimwire is a traditional http webhost -- you have to have it for webrtc signalling. It distributes tokens for 3rd-party app access, and has a widget that's actually pretty similar to the remotestorage.js one. (Instead of redirect though, I used a popup and window.opener.postMessage(token, thirdPartyAppOrigin), which I *think* should be secure but I'll be interested to hear if otherwise.)

You would open the remoteStorage application in your browser, then connect to your relay. The auto-configuration tool is similar to webfinger, but based on RFC 5988: basically rel-typed links kept in a registry on the relay and sent down in response headers. The remoteStorage app would register a link to itself with the "remotestorage" reltype, as you do already in the webfinger (assuming remotestorage gets into the iana registry - otherwise you'd need to use a URL reltype like "remotestorage.io/provider" to stay compliant with 5988).

Then, the user would open other applications and connect them to the relay. If the apps use remotestorage, it'd query the registry's links, find the open app, and then go through some authorization process (perhaps a permission popup in the remoteStorage tab.) After that, it would work as it does now.

The remoteStorage app would have to stay active in the browser to remain available. It would be accessible from other devices, so you could open it on the desktop and leave that running for your other devices.

Paul

--
 
---
You received this message because you are subscribed to a topic in the Google Groups "Unhosted Web Apps" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/unhosted/8R2npBpI1NI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to unhosted+u...@googlegroups.com.

[Scott Elcomb]

On Thu, Nov 7, 2013 at 3:58 PM, Paul Frazee <pfr...@gmail.com> wrote:
> The remoteStorage app would have to stay active in the browser to remain
> available. It would be accessible from other devices, so you could open it
> on the desktop and leave that running for your other devices.

I wonder if the app could be hosted in a headless environment (as a
background process) - perhaps with phantom.js and webrtc.io?

--
Scott Elcomb @psema4
http://psema4.com/pubkey.txt
http://www.pirateparty.ca/

[Paul Frazee]

In browsers that support shared workers, you can put the server there, but shared workers are (as far as I know) restricted to pages from the same origin.