remoteStorage spec version 12.04 - discovery

[Michiel de Jong]

On Sun, Mar 11, 2012 at 11:19 AM, Michiel de Jong <mic...@unhosted.org> wrote:

7) fakefinger - we have been using fakefinger on Libre Docs. It's basically just unhosted's own central user database where /if/ you don't have webfinger (this is only a fallback of last resort), you create a record pointing to your remoteStorage, on the basis of BrowserID. I think it's time to write down what we're doing there. we could also add other alternatives to webfinger, like swd and xmpp disco and maybe dev-identity will propose a 'persona profile' standard at some point, although i doubt whether that's actually useful for anything.

that sentence was ambiguous, what i meant to say is i doubt whether it's useful to add so many different options into our spec.
 

people should just implement webfinger, always. i'll write a separte thread about this.

so the idea is as follow:
1 - ideally, your storage is provided to you by the same domain who provide your email address. then, it's easy to remember which user address you should use to log in - it will be just your normal email address.
2 - it can also be that the two providers are different. in that case, you have two options:
    2a- remember two user addresses, and remember you have to log in as user@server on client-side apps, even though your still log in with your normal email address on most other websites. so this can be confusing for a user. How much so? we haven't really tested that much yet, but we will do so soon, and then we can see the looks on people's faces when we explain it to them.
    2b- set up a forward on proxy.unhosted.org, that points from your email address to the user@server address.
3- it can be that the storage you want to use is not compatible with remoteStorage, and you access it through proxy.unhosted.org. For instance, we're working on a proxy for Dropbox, which will allow people to use their Dropbox account as remoteStorage, even if Dropbox haven't succumbed to the inevitable conclusion yet that they should themselves start to offer a remoteStorage interface.
4- it can be that the app provider wants unhosted to make an educated guess about where the user wants to store their data. so far we have two examples of this: gmail addresses -> GoogleDocs, and Dutch university addresses -> surfnet.

now if we don't want to use a centralized user database, and your storage provider is different from your email provider, you could just remember your username at the remoteStorage provider. downside: this will lock you in to the provider because people will address you by that user address. This is already happening for shared documents in Libre Docs. If i choose to switch providers, all people who have saved documents i shared with them, will get 404s there. so at least i should leave the old account open, saying 'i moved there'. this is not the end of the world, this is what people have always done on the web. some academics move positions so often that you sometimes have to click through 5 'i no longer work here' home pages before getting to their home page. on the up side, since all apps will use the same 'contacts' category, you could send a notice to all your contacts, and their addressbook app could make the change once, and all links will be updated.
the positive thing about using the user address '@' the storage provider, even if this is not the same as the email address you usually use on the web, is that it makes clear where your data is. you can see the name of the storage provider each time you type it in, and that way feel more control over it, and more transparency.

then there's the people who go through proxy.unhosted.org, which is currently IrisCouch users (until we can get BrowserID for server admins and the cors module activated, we still have to proxy it to make it work), and will soon be Dropbox. Google storage, when we get round to implementing it, will also probably be proxied through proxy.unhosted.org at first, pending this thread:
https://groups.google.com/d/topic/google-documents-list-api/LIqDZapXksU
for these people we could just give out user addresses @proxy.unhosted.org. it's a bit annoying, but it's also transparent. and it avoids centralization.

then there is only the 'educated guess' ones (gmail addresses -> GoogleDocs, and Dutch university addresses -> surfnet), but those can go into our client-side remoteStorage.js library and don't have to be done on the server-side. so then there is no need to explicitly talk about proxy.unhosted.org in the spec. but we can say "in the absence of webfinger data for a certain user address, RPs MAY make an educated guess about the user's remoteStorage provider".

so anyway, i was going to say that we should add a reference to proxy.unhosted.org, but while writing, i changed my mind, and i think we can get away with not mentioning it.

we'll see how users react to their user@server addresses. there are about 100 people who have a fakefinger account now, but they're mainly Libre Docs testers, we can deprecate them. for instance if they log in again show a message 'this was the last time we let you use that email address, from now on you're b...@proxy.unhosted.org'.

TL;DR: let's not use a centralized fallback, but instead add a sentence: "in the absence of webfinger data for a certain user address, RPs MAY make an educated guess about the user's remoteStorage provider", to cover cases where we want the remoteStorage.js library to do that.

Comments welcome!


Cheers,
Michiel