remotestorage / remotestorage.io Goto Github PK

We should add a graphic to the frontpage (empty area that's reserved for it anyway) that explains the concept or at least the most important parts of it visually. I'm thinking about something like on http://nimbusbase.com

It should at least explain:

• RS syncs data between different devices
• Different apps can access the same data
• There can be an unlimited number of different remoteStorage servers/services

In order to improve developer marketing/evangelism, I'd like to set up some kind of analytics tool that can tell us how people find the website, where they go, etc.

We (@5apps) could sponsor a site on our Piwik server, and add user accounts for the core team. We can also set it up so that IP addresses are stripped of the last couple of bytes in order to anonymize the logs.

If nobody objects until the weekend, I'll set it all up and create some user accounts.

I just saw that the latest IETF spec breaks with the old W3C wiki one in regards to the precise naming and uses "remotestorage". As this is an important question for presentation and usage, and it seems to have silently changed and, more importantly, be used differently by different people and in different contexts, we should have a proper discussion and decisions on how exactly the term is written and used in all contexts.

I think "remotestorage" looks very wrong in almost all situations, but especially in ones, where you want to refer to the actual storage instead of the protocol or library (e.g. "connect your storage". I vote for that case to just use "remote storage". I don't think it will be an issue with other products, because you'd then normally use the product name (or other open standard name) instead of this seemingly generic term.

In regards to the protocol and libraries, it seems to me that it makes more sense to use the lower camelCase version, as this not only reflects the localStorage standard, but also divides the word visibly. Which looks much less wrong to my eyes, because in English you usually don't have composed words without separative characters.

Like any word, it should always be possible to use it in all caps for logos etc. (and in the current logo it is set in 2 lines, also making it "REMOTE STORAGE" by the way).

We discussed about having a module for »apps« which the storage provider will use to save the apps a person has installed.

It could contain: name, link, icon, token, permissions, etc.

Then when you move from one storage to a different one, all the info about which apps you use, and the permissions, and the possibility to show them like a dashboard, would move with you.

posting here on @jancborchardt 's request. my work is here owncloud-archive/apps#47

what i'm doing now is:

• remove checkboxes from OAuth dialog
• add xss-prevention in OAuth dialog
• add better install instructions into app description
• make litewrite app-first and storage-first coincide
• improve css and polish stuff

the only real Known Bug atm is the OAuth xss, for the rest it's mainly documentation and polishing now. If you're brave and want to try it out, come to #owncloud-dev on freenode, and i'll talk you through it (i'm michiel-irccloud there atm)

I think we should add at least one or two example apps that fulfill an actual purpose to the website. Obviously the first thought is Litewrite. Not sure what others could be at the moment.

(Just transferring @shybyte’s post from the mailing list here because the time tracker is awesome!)

Hi!

maybe you can remember the "Unhosted Time Tracker" prototype I hacked last friday in the great cBase meeting. Thanks again to Niklas for helping me and fixing remoteStorage bugs in realtime.

Like I promised there is now the polished version online:
http://shybyte.github.com/unhosted-time-tracker/

Please remember that you need a remote storage 0.7 account for syncing your data with the app. Syncing by using the remote storage widget is anyway a bit broken currently, which is probably caused by a bug in remoteStorage.js, but syncing by pressing the browsers reload button works fine :-)

I had a lot of task module improvements ideas while developing this app, that I will discuss here or in the remoteStorage.js issue tracker later.

Please feel free to report "Unhosted Time Tracker" related issues here: https://github.com/shybyte/unhosted-time-tracker/issues

Cheers, Marco

The site is a mess on mobiles.

There's one week to go to have a proper remoteStorage.js 0.7.0 release (first stable one ever) party!

There's quite some progress: @nilclass and @silverbucket setup an extensive testing environment to finally iron out the bugs. Known severe bugs reduced to one. I put some hours of work into the widget so we have a stable UI that also doesn't look broken.

We need apps to use the upcoming release candidate 5 to check if all is working in real-world scenarios.

We need to finally come up with a proper website and streamlined docs and examples. A lot of things are almost done but still not finished.

Please help out and let us do this together. Yes, we can ;)

http://remotestoragejs.com/ still exists and has a very old auto-generated github site on it.

I wrote a small chrom[e|ium] extension to sync bookmarks from the
browser into remotestorage.

You can try it out by cloning the repository and then using "Load unpacked
extension" under chrome://extensions

Code is here

Have fun!

maybe we can add this one to remotestorage.io website?

http://ost.io/

"Ost.io ("open-source talks") is a forum for open-source projects and the best place for discussing project stuff with other users. It is tightly integrated with GitHub.

The main ost.io mission is to replace mailing lists. Mailing lists are broken!. They have ugly interface, most of the time you can't read all messages in a comfortable way (instead, you see a plain-text message). Unfortunately, a lot of open-source projects currently still use mailing lists, because there was no replacement for it. Until now."

What is the state of the 0.7 release? I see lots of issues popping up and my impression is that a release of 0.7 is not in focus any more.

Hi together,

can someone tell me if it's already possible to access a normal remoteStorage provider (like 5apps.com) with node?
As far as I can tell from reading https://groups.google.com/forum/?fromgroups=#!topic/unhosted/kI9DI_9xt28 I have to set the bearer token on the server what I can only do on my own server. So it's not working in the moment?
Do you have any plans for the node support?

Thanks!

Hey everyone.

I'd like to propose a remoteStorage meetup/hackathon May 11th-12th in Berlin.

I will be in town already because of re:publica earlier that week, and my return train ticket is not until the 13th, so it would be really great to meet up with you all in Berlin.

What say you all?

See https://groups.google.com/d/msg/unhosted/2rjmEblRq68/M2hcMeUPCbsJ

We updated http://litewrite.net with the latest version. Please test it and use it!

If you find any issues, please open an issue at http://github.com/litewrite/litewrite/issues

I also kicked off publication to the Mozilla Marketplace and Chrome Web Store, just takes some time to get reviewed.

Cheers from @jorin-vogel and me! (And thanks to http://5apps.com for the awesome deployment platform!)

i went through the steps in gh:remotestorage/remotestorage.js/doc/release_checklist.md but my roots install is broken on my build server...

can someone who has roots working pull in the changes and run ./deploy?

My remoteStorage has a bunch of old files which make it nearly impossible to use it properly. The biggest problem are probably the docsCollection and pad stuff in the documents module, the legacy Libre Docs stuff.

The remoteStorage browser crashes at loading it, and because there’s no caching it always loads everything over again. Is there a way of manually deleting everything in the documents module which starts with docsCollection or pad, but not deleting anything else (like notes/, which I actually use)?

One of the most important factors for adoption of remoteStorage 0.7 by end users and developers is the availability of user friendly, effortless and reliable remote storage 0.7 providers.

Unfortunately the current situation is not very satisfying.

Therefore and as a little programming exercise I developed this weekend a new remoteStorage server. This new server is written in scala/java from scratch and runs on Google App Engine. It uses google accounts for login.
This means that every one of the 350 million gmail users has now a remote storage address ([email protected]). For more information see https://remote-storage.appspot.com/ and http://github.com/shybyte/remote-storage-gae .

First, it might sound ironic to create a remote storage provider that runs on google's server, but on the other hand it can lower the barrier to use remote storage apps for the existing 350 million google account users. Additional the code could be reused for another scala/java/jvm based remote storage provider.

I tested it only with http://shybyte.github.com/unhosted-time-tracker/ for now.
Is there any automatic test suite that can run against the server in order to make sure that it is remote storage 0.7 compatible?
Should old pre 0.7 apps like shared stuff still run?

Please keep in mind, that the server is currently in early alpha and your data is not safe. In the near future this service will become a user friendly, effortless and reliable remote storage provider for end users.

If you get a webfinger blablabla exception when you try to connect, please try it again, or press reload and try to login again. I'm not sure if this occasional bug is in remoteStorage.js or in the server. Could be caused be the fact the the (https) connection needs sometimes some time to build up.

After yesterday's testing and bugfixing i think we can have 9 apps ready to publish on unhosted.org tonight:

https://github.com/unhosted/website/blob/master/apps/index.html

I tried to use people's own instances in the links, but this was not always possible. in particular, @jancborchardt i think you have accepted the pull request from @nilclass but still need to deploy litewrite to 5apps, could that be? i'm still getting some old version there when i test http://litewrite.net/

(moving from remotestorage/remotestorage.js#52)

cc @michielbdejong
Ref ownCube ticket https://billing.owncube.com/viewticket.php?tid=703324&c=kX8iuHdv
And ownCloud remoteStorage pull request owncloud-archive/apps#448

People on the streets say "5apps storage is soon 0.7". Yes, "at the moment" this is kind of correct as the client-side library and the storage will work together. But that is due to the common protocol they speak. So what we should say and make clear in all communication is that a storage supports a protocol version like for now 2012.04. If there's a new version of remoteStorage.js that still supports 2012.04 there will be confusion otherwise. In addition it would promote that we have an open protocol much better.

The link on http://remotestorage.io/integrate/#examples to 'minimal code example' 404s

The existing apps should be updated to the new stable library 0.7.1:

• Friends#unhosted by @brolund
• Shared Stuff by @shybyte
• gHost photos by @vcuculo
• Unpapered by @Geal

All info you need for that should be on http://remotestorage.io, let us know here if anything is missing or if you need any help.

(Relaying private mail by @michielbdejong)

To test Release Candidate 6, please help to test the following apps. Please all
try to find at least one bug. For every bug you find, you will
receive a free beer at the launch party tomorrow. :)

I deployed the apps to my own 5apps account for now, ones testing
is completed, all bugs fixed, and we have the official release
version of the library, I will send all the app authors pull
requests, and ask them to deploy the working versions of their
apps themselves.

My favorite drinks:

• URL: http://my-favorite-drinks.michiel.5apps.com/
• Author: Martin
• Known bugs
  • favicon missing
  • css warnings

Todo MVC with remotestorage:

• URL: http://todo-mvc.michiel.5apps.com/labs/architecture-examples/remotestorage/
• Author: Michiel
• Known bugs:
  • css warnings
  • updating text of an item doesn't work
  • favicon missing

Time tracker:

• URL: http://unhosted-time-tracker.michiel.5apps.com/
• Author: Marco
• Known bugs:
  • not working yet, please test other apps first
  • css warnings
  • Error: task is null
  • widget not showing
  • favicon missing

Litewrite:

• URL: http://litewrite.michiel.5apps.com/
• Author: Jan & Jorin
• Known bugs:
  • not working yet, please test other apps first
  • css warnings
  • cache.openDoc undefined
  • docs index not showing up in the top left

Music:

• URL: http://music.michiel.5apps.com/
• Author: Francois
• Known bugs:
  • css warnings
  • there is no way to upload binary files
  • favicon missing

Editor:

• URL: http://editor.michiel.5apps.com/
• Author: Michiel
• Known bugs:
  • css warnings
  • favicon missing

Browser:

• URL: http://remotestorage-browser-example.michiel.5apps.com/
• Author: Niklas
• Known bugs:
  • css warnings
  • browsing public/ doesn't work
  • there is no way to upload binary files
  • icon is broken in Firefox
  • favicon missing

Vidmarks:

• URL: http://vidmarks.silverbucket.5apps.com
• Author: Nick
• Known bugs
  • porting to rc6 now, so we'll see.

GroupTabs:

• URL: http://grouptabs.xmartin.5apps.com
• Author: xMartin
• Known bugs
  • Doesn't refresh all parts of the UI on sync.

Thanks for your time!

cc @nilclass @xMartin @silverbucket @skddc

I think @skddc only mentioned it offline or on IRC, so relaying it here:

It would be awesome if you could specify a Creative Commons license to go with all the public stuff on your remotestorage. Like Flickr, Youtube, Soundcloud and http://i-am-cc.org for Instagram it would be great if people could say in bulk »my public stuff is freely licensed«.

This license info could be stored in the profile module. Or directly as property of the element, if that specific one has a different license.

My overwhelming concern with frameworks/libraries like this that provide off-line support is the fundamental limits imposed by using localStorage, which varies between 2.5 and 10MB depending on the Browser. You then halve the number of bytes as strings are UTF-16 which uses 2 bytes per character. These limits are way too small for anything but the simplest of applications. Unfortunately there is no simple solution for local storage

My Favorite Drinks was hosted on GitHub pages (http://remotestorage.github.com/myfavoritedrinks). This obviously has problems as it is not a unique origin so hosting it on GitHub Pages without having a dedicated domain pointing to it is not a good idea. For now I renamed the branch to master and deployed the app at http://myfavoritedrinks.xmartin.5apps.com. Also not ideal as my user name is used but should be fine for now.

just booted into Windows 8 and tried out http://remotestorage.io/ with IE. the first sentence looks like this:

Everything in one place – your place

I will give a workshop on using remoteStorage.js at CampJS.

I already talked to @nilclass about what to do and we thought of taking a simple app like myfavoritedrinks and do a step by step hands-on how to integrate remoteStorage.js. This would be very simple, maybe a bit too simple. So do you have any ideas what I should do?

I just asked how much time I have so I'm not sure about that yet.

I'd start off with a little presentation about unhosted and Remote Storage in general. Any hints on what slides to use? Any topics you want to be added.

@nilclass is so kind to offer assisting me via IRC so let's see how that goes.

Don't know if I can invest that much time but maybe this could be a starting point of some kind of blue print for workshops on Remote Storage in general.

Looking forward to any feedback!

see https://github.com/relet/python-remotestorage
it still needs some install instructions in the readme, but we should mention it on the 'get' page.

How can I share e.g. a todo item with another person only? I don't want to make it public.

one on github:
https://github.com/remotestorage/remotestorage.js#adding-remotestoragejs-v07-to-your-app

one on remotestorage.io:
http://remotestorage.io/integrate/

and one on remotestoragejs.com:
http://remotestoragejs.com/doc/code/files2/howto-include-txt.html#

maybe we should merge those all into one and link to just one place.

(Also transferring @xMartin’s post.)

I talked to someone who is interested in using remote storage as a backend
for his unhosted web app but he was concerned about users being
overwhelmed with the whole Remote Storage topic. He asked if there was a
fallback/default solution for users without a remote storage that he could
host himself. He'd prefer a PHP app but doesn't care that much as long as
it's easy to setup.

I know this is not what we're focussing on but a scenario that we thought
about ourselves earlier. Instead of using the widget, app developers could
provide custom UI to log in preconfigured for their storage.

Just a use case I wanted to put back on the list.

@fkooman Would it be possible to extract such kind of server app from your
code base?

There are a lot of web apps in the wild which use localStorage to store data.

I think it would be great to add remoteStorage to them by a browser extension which just sync the localStorage of the wep apps to the remoteStorage of the user. The browser extension should allow to configure which apps should get synced. This can be done with one mouse click ("Add remoteStorage"/"Remove remoteStorage") on a toolbar button. By default the data would be synced to a directory named like the apps url, but it should be possible for the user to configure the directory optionally.

Clearly an app that gets unhosted in this way will not work as smooth as it could be. For example it might be necessary for the extension to reload the whole app in order to get the data reloaded in the app. But it is better than waiting forever until an app gets unhosted "naturally".

What do you think about the idea?
If you think it's a great idea, I would volunteer to prototype the chrome extension.

please proofread! :)

https://unhosted.org/adventures/7/Adding-remote-storage-to-unhosted-web-apps.html

i think it looks kinda cool to have the JSON schemas on https, but then we do need to get https hosting for it.

so options:

1. get https hosting for https://remotestoragejs.com/ somewhere. @nilclass do you have a free IP address on the heahdk server maybe?
2. same, but moving the specs (and docs) to the (way cooler!) https://remotestorage.io/ domain
3. change the schema base-location to just be on http://remotestorage[js.com|.io] instead of using the current https URIs.

but right now the self-documenting pages we advertise in our schemas don't actually exist. :)

I have prepared another release candidate, which is pretty much a stripped-down version of the last rc, with a lot of bugs fixed on various layers.

The builds are here: https://github.com/RemoteStorage/remoteStorage.js/tree/master/release/0.7.0-rc4

I've added some release notes to the release commit.

There are a few things that need to happen before it can become a final release:

• (most obviously) CSS fixes. Any help / input / fixes here are greatly appreciated, especially for platforms I cannot easily test myself (Mac, (Windows), various mobile). There is a playground with all widget states here If you want to update it, edit "doc/style/widget.css" and commit the changes to the gh-pages branch. If you want to apply the change to the code, run make compile-assets. Help on building can be found in the documentation. @skddc also put the code on cssdesk.
• Removal of debug-tools. This should decrease the size of the final build and increase performance and memory usage (no debug-events and less logging).
• Test the code on various platforms. The release notes contain a list of apps, providers and browsers I've tested so far.

The app-versions used to test are now deployed here:

• http://remotestorage-browser.nilclass.5apps.com/
• http://remotestorage.github.com/myfavoritedrinks/

If you experience any initial problems with the widget, try clearing your localStorage and (forced-) reloading the app.

(And @nilclass’s post.)

Hi,

I wrote a small chrom[e|ium] extension to sync bookmarks from the
browser into remotestorage.

You can try it out by cloning the repository and using "Load unpacked
extension" under chrome://extensions

Code is here:
https://github.com/RemoteStorage/remotestorage-bookmarks-chrome

Have fun!

-- Niklas

This will now be our mailing list. Every discussion thread is an issue, you can also reply by mail, and we can even tag discussion and such. And we’re here anyway, much easier for everyone.

Join in on the fun @nilclass @silverbucket @xMartin @michielbdejong @fkooman @skddc @shybyte @peacekeeper @brolund @elf-pavlik @Epic720 @azul @jcoglan @jorin-vogel @vcuculo @tantaman @mk-fg @aykevl93

(Please no replies, because everyone will get them. Just start posting here and use neither librelist nor riseup anymore.)

TL;DR? This message is about changing the way modules work in remoteStorage.js. To skip the intro, search for "A) " in this message.

To recap, this is currently how modules work:

• Modules are defined through remoteStorage.defineModule. They consist of a name and a builder function.
• The name corresponds to a directory node directly below the storage root, as well as to an entry in the "scope" used to claim access.
• The builder function receives two BaseClient instances, corresponding to the private and public root of the module respectively.
• Modules return (amongst other things) an object called "exports", which is the public interface of the module, as seen by apps.
• Once a module is defined, it's "exports" object can be accessed via the remoteStorage object as remoteStorage[moduleName].

To illustrate this, here is what a module may look like:

remoteStorage.defineModule('bottles', function(privateClient, publicClient) {
  // declare which paths to use
  privateClient.use('');
  publicClient.use('');

  function generateId() {
    // (code ommitted)
  }

  return {
    exports: {
      add: function(content, size) {
        var id = generateId();
        return privateClient.storeObject('bottle', id, {
          content: content,
          size: size,
          id: id
        });
      },

      remove: privateClient.remove,

      getPublished: function() {
        return publicClient.getObject('publishedItems');
      },

      updatePublished: function(object) {
        publicClient.storeObject('published-items', 'publishedItems', object);
      },

      publish: function(id) {
        var published = this.getPublished();
        publicClient.storeObject('bottle', id, privateClient.getObject(id));
        published[id] = new Date().getTime();
        this.updatePublished(id);
      },

      unpublish: function(id) {
        var published = this.getPublished();
        publicClient.remove(id);
        delete published[id];
        this.updatePublished(id);
      }
    }
  }
});

This leads to a number of restrictions in writing apps:

1. In order to write an app, you need to write a module, unless you only depend on core-modules. This is even true for apps in which the module doesn't do anything that the BaseClient wouldn't be able to do on it's own.
2. The module determines the only public API that the app can use to access storage. This means that even very basic methods, such as getting / storing / deleting / listing objects or files, need to be implemented or explicitly delegated to the baseClient(s) by the module. Thus the structure and naming of the public API varies greatly between individual modules.
3. The separation of access to the "private" and "public" area through individual BaseClients makes it the module's responsibility to connect the two. Thus it becomes very hard to establish conventions for publishing and sharing, as those conventions cannot be implemented of the remoteStorage.js core code.
4. There is no defined way to extend a module. The public remoteStorage[moduleName] object can be extended like any other JavaScript object, but the syntax for this varies greatly from the regular module definition through defineModule().
5. Modules have no mechanism to access another person's storage.

In order to overcome these restrictions and reduce the amount of boilerplate code required to start with an app, I would like to make some changes.
Most of the following suggestions are the result of various discussions in the channel (#remotestorage on freenode) and at other places (such as issue #100). But before starting to actually implement those changes, I'd like to give everyone a chance to add to, criticize or approve with any of this. So go ahead :)

A) Drop the public client, enhance the BaseClient

As can be seen in the example above, the code to publish objects is very generic. In fact, quite similar code is already part of the "root" module.
As publishing and sharing are the most common usecases for public data, it makes sense to have them as part of the BaseClient.

I propose to add the following methods to BaseClient:

• publishObject(path) - adds the given path with the current timestamp to the "publishedItems" object and copies the object found at "path" to public/{moduleName}/{path}
• shareObject(path, secret) - copies the object found at given path to public/{moduleName}/shared/{secret} and returns the absolute path to it as a String.
• getPublicClient(path) - retrieve a copy of the BaseClient that works on the "public" area. This would be for backwards compatibility with the current publicClient, as well as for custom operations done in the public area.

B) Expose the BaseClient to the app

To make trivial access to remotestorage as simple as possible, it should be possible to gain access to a BaseClient instance without having to define a module.
This would work through a method called remoteStorage.getClient, which receives a moduleName:

var client = remoteStorage.getClient('bottles');
client.getObject('...');
client.publishObject('...');

C) Make modules extensions of BaseClients instead of independent objects

Once (A) is implemented, our module boilerplate would have changed to:

defineModule('bottles', function(client) {
  return {
    exports: {}
  }
});

Then once (B) is implemented, all the generic methods from the module could disappear. All that remains is "add".
Now the situation is a bit weird, as some methods (such as remove, publishObject, ...) have to be called on a client, while "add" still has to be called on the module.

So instead of making assigning the "exports" object to remoteStorage[moduleName], the module could serve as an extension for the BaseClient.
The BaseClient in turn would be cached, so getClient('bottles') will return that modified BaseClient instead of a fresh one.

Thus once a module 'bottles' has been defined, the following lines become equivalent:

remoteStorage.bottles;
remoteStorage.getClient('bottles');

Note that in this case, the module would better name the "add" method "addBottle", to clearly distinguish it from adding other objects.

This would also enable modules to be extended, so a module that has been defined in the core, can be extended from an app by calling defineModule() again, without having to copy the entire module to the app.

D) Apply modules to ForeignClient instances as well

Another new thing in the upcoming 0.7 release is the ForeignClient. It is basically a read-only BaseClient that is associated with another person's storage.
Once (C) has been implemented, the module's "exports" object can additionally extend any created "ForeignClient" for the same scope / moduleName.
To provide an example, consider a method "totalSize" for the example above. It would iterate over all "bottles" and add their "size" attributes. If the same method is applied to the ForeignClient, it can be used to perform the same operation on another persons published "bottles".

Ok, that's all for now. If I forgot anything, please add.

-- Niklas

Due to problems with localStorage (primary quota), the local cache, that is currently implemented through localStorage will be changed to use another DB option.

As most DBs in browsers use asynchronous interfaces (IndexedDB has synchronous interfaces as well, but those are about to be deprecated), this also means that the synchronous versions of the data access methods (getObject, storeObject, getFile, storeFile, remove) will no longer be supported. Instead those methods will probably return promises in the future, if they are called without a callback.

Databases other than localStorage are not fully supported by all targeted browsers. Currently the blocking requirement of remoteStorage.js is CORS, which is supported by the following browser versions:

• IE >= 10
• FF >= 15
• Chrome >= 22
• Safari >= 5.1
• Opera >= 12
• iOS Safari >= 3.2
• Android Browser >= 2.1
• Blackberry Browser >= 7.0

As WebSQL is deprecated, the only other databasese we can switch to are IndexedDB and Filesystem.

The Filesystem API only works fully on Chrome >= 23 and Blackberry Browser >= 10.0, so it is not an option. Also using IndexedDB would give us indexes for values, so we don't have to implement them on top of the remotestorage data tree.
However, IndexedDB is also not supported in all target browsers, especially in the mobile section.
This is a list of target browsers that don't support IndexedDB:

• Safari
• Opera
• iOS Safari
• Android Browser
• Blackberry Browser < 10.0

For those browsers the localStorage implementation could remain as a fallback. That means additional features of IndexedDB cannot be used until all target browsers are supported.
However all those browsers that don't support IndexedDB support WebSQL, so we could also implement a WebSQL storage backend as a fallback. That way SQL indexes could be used in place of IndexedDB indexes and those benefits remain.

So, I'm interested in what you all think about this. Especially regarding the previous paragraph.

It's a bit last-minute, but thanks to Brandwatch we now have a location for our Remotestorage Hackday! It's their office at Gutenbergstraße 77a, inner yard: http://www.meetup.com/stuttgartjs/events/85910042/

If you happen to be in Stuttgart, come by! If you're not, retweet: https://twitter.com/stuttgartjs/status/259345793423650816

See you!

While looking through some notes I found 2 apps from a 10kb Javascript competition which are quite nice and could use remotestorage:

• Feedreader: http://10k.aneventapart.com/1/Entry/127
• Sketchboard: http://10k.aneventapart.com/1/Entry/129

If you want to dive into remotestorage but don’t have an app yet it might be a good entry point to try and get remotestorage.js working with those two apps. :)

see remotestorage/remotestorage.js#476 (comment) for more details

See http://lanyrd.com/2012/hackerbeach/scchmf/ - I added Basti, "Bungalow Ten" and myself to the event as "speakers". :)

@jancborchardt i walked your reply back from the restaurant to @skddc and his reply is: the svg on the usb stick was just the logo, not the diagram yet for the remotestorage.io front page.

What he meant was a drawing like the one in the slides, so that the front page has something to look at and is not only text. Do you still have time to get that ready? You can also come over to the TTT reception area and talk directly to Basti about it. :)

Jorin (@jorin-vogel) and I worked hard on getting Litewrite in proper shape, also at the Remotestorage Hackday last Saturday in Stuttgart. And @nilclass helped us iron out the kinks in remotestorage support.

Now we need you to give the development version a good testing before we deploy to litewrite.net – try it out at http://litewrite.github.com/litewrite
We use remotestorage.js 0.7 so you need a 2012.04 remotestorage, currently those are http://heahdk.net and http://5apps.com (they just updated, yeah!)
The app is responsive and has a mobile view, so also try it on your smartphones!

Please open an issue for anything you find, tech issues, usability problems and more! We also have some issues we are already aware of: https://github.com/litewrite/litewrite/issues
Mainly annoying is the cursor misplacement: litewrite/litewrite#50 if you have any pointers on how to fix it that would be a-awesome.

Future plans include inline Markdown support and the possibility to publish documents, so you could basically run a blog off Litewrite, or just quickly share like Pastebin: litewrite/litewrite#19

Any help is appreciated, we also hang out in the #unhosted and #remotestorage IRC channels as jorin and jancborchardt.

Cheers!

As of today, the latest version of the remotestorage spec is http://www.ietf.org/id/draft-dejong-remotestorage-00.txt so we should update remotestorage.io and other documentation to reflect that.

It is NOT necessary to deprecate 2012.04, so existing storage providers can keep using that without problems.

you should all be in the 'Acknowledgements' section, i hope i didn't forget anyone, that would be awkward... anyway, it feels as quite a milestone, at least to me :)