Amy Guy

Raw Blog

Showing posts with label remotestorage. Show all posts
Showing posts with label remotestorage. Show all posts

Tuesday, April 29, 2014

On the importance of remoteStorage module reuse

Well, the point of Unhosted modules and being explicit about your data schema in modules is so that other developers can reuse them, to make it possible for users to switch between frontend apps that consume the same kinds of data.

Well, duh*.

But there seem to be loads of people making the same kinds of apps over remoteStorage (mostly todo apps or notetaking kind of things) and making their own modules every time!

If one module doesn't offer everything a dev needs for their new app, they should hook in anyway and extend it with their own module on top. That should be pretty straightforward.

So I love LiteWrite, but for notetaking maybe I need a few more organisational facilities. McNotes looked awesome and I was poised to start using it. Then I saw Laverna offers remoteStorage support and that is pretty much a straight up port of Evernote (but ten times as sexy), with tags and notebooks and everything!

When I switched from Evernote to something to something to Springpad (the ones in between didn't do the job, and I've since forgotten what they were) I had all kinds of mess importing my Evernote data, and a lot of it was done manually due to limitations of the various importers. If I'd actually started storing anything useful in LiteWrite, and wanted to move to McNotes and then to Laverna I would have gone through the exact same process... which is a horrible thought, because that's one of the problems remoteStorage is supposed to solve.

So, please, if you're making an app over remoteStorage, look at the other modules that exist first, and use them. And if you're making a new module, please publish it! Otherwise we're missing a butt-ton of opportunities for giving users choices about their UIs, and for mashing things up in amazing ways.

(On that note, I'm keeping a list of Unhosted mashup ideas).

* Although this is kind of obvious, I explicitly came to this realisation after it occurred to me, when trying to work out how to make schema definitions conform to proper JSON-LD, that you go to all the trouble of defining your data schema in your module, but then there's nothing to stop you just storing any old object. You can validate an object against a schema, but there's nothing to do this by default. So I thought why then do I need to bother with this JSON-LD schema faff if I can just store prefixes at object creation time? Then I remembered other people, and reuse and stuff. It took a surprisingly long time (like an hour of frowning) to get to that though. Especially surprising given that all I've been thinking about this evening is Linked Data. Clearly all this JavaScript is obscuring coherent thought.

Unhosted App Ideas

If people release their models and data schema for remoteStorage apps, we can mash them up with much ease! I'm maintaining a list here of ideas that I may or may not get around to implementing:

  • Notetaking app + bookmarking app = WebClipper functionality and/or annotation of webpages
  • Todo app + calendar app = duh.

Since most of the early Unhosted apps are life-organise-y ones, can we just have a dashboard that combines everything? Can we call it SORT YOUR LIFE OUT?

Monday, February 04, 2013

Gibbering about decentralised networks

Recently I read and brainstormed some things about interesting ways of creating a decentralised network (social or otherwise).

Tent.io is still coming out on top as having the most potential for something I could actually implement and build upon.  Tent server is originally Ruby, but there are already Python and PHP implementations.  PHP might be the most useful as the mostly widely supported by cheap shared hosting providers, reducing the barrier for people wanting to run their own Tent server.  Depot in particular has the goal of targeting the technical lowest common denominator, and making installation and maintenance as easy as possible for a non-expert.

Problems with having nodes of a network, whereby people who don't want to set up their own node can sign up to someone else's node, include ensuring consistent URIs for things.  If someone wants to up and move to another node, what are the best ways of maintaining connections?  Obviously anyone who buys their own domain name and hooks it up won't have a problem, but not everyone can or will.  A centralised permanent URI service like PURL (or just use PURL..)?

Unhosted and their remoteStorage protocol are interesting.  The idea is that a user registers with a remoteStorage provider, then signs into Unhosted apps with that identity.  Unhosted apps are all frontend JavaScript, and no data is sent to a server.  Anything that needs to be stored - content you creating whilst using the app - is sent to your personal remoteStorage account.  There are only two remoteStorage providers listed though, and one of those is a test one that could get wiped at any time.  The other, 5apps.com, doesn't appear to provide an interface for browsing and exporting what you have stored with them.  Obviously this is an early project, and since anyone with a webserver can theoretically set up a remoteStorage service, has lots of potential.  In the short time I spent investigating, I couldn't work out possibilities for sharing data in your remoteStorage, so Unhosted apps might just be useful for personal, non-collaborative activities.  Some examples they have are a simple text/code editor, a really pretty simple writing interface, to-do lists, time management, favourite drinks list.  Oh wait, friendsunhosted.com is like a twitter service.  Because I don't know anyone else using friendsUnhosted, I haven't tested it properly, but it appears to offer a stream of peoples' statuses, which are presumably stored in their personal remoteStorage.  I'll investigate better.  The mailing list is active and the main developer seems to be on top of things, so this is something to keep a close eye on.

Idea: Possible to set up 'remoteStorage' on peoples' own Google Drive accounts, via that API?

I don't know anything technically about peer-to-peer, but it seemed like a good avenue to pursue with regards to very established, very decentralised networks of people and files.

At an extreme end of 'owning one's own data', I'm curious about storing all your files (eg. linked data graphs) locally and sharing them / accessing other peoples' only through a browser interface.  Drawbacks obviously include your files only being available when you're online.

I read a handful of good things about the G3 protocol and API used in FilesWire, by Dreamsoft Technologies.  I got really excited for a little while, before reluctantly giving up because the whole project seems to be old and very dead.  I did track down the developer on LinkedIn and facebook, but I haven't decided yet if it's worth pursuing at all.

I investigated Freenet, and their freesites.  The Freenet network is all about anonymity; any data you upload is broken up and stored on many nodes in the network.  You can't identify where it originally came from, or where you're pulling something from when you retrieve it.  There were some messages from 2000/2001 on a mailing list about RDF on Freenet, but nothing seems to have come of that.  Requires a software download of course.  Again, I don't know enough about the technicalities yet to judge if something like this would be a viable approach for a decentralised linked data sharing network.

I also came across (the now deceased) Opera Unite, which is a webserver running inside Opera that lets people share files and serve webpages without the hassle of paying for or setting up their own server.