I just talked to the grnet guys (who run the federation of Greek
universities), and the same issue came up as with surfnet: "Why use
user addresses to discover storage?"
We need the user to tell the browser where her storage is, and where
the app is she wants to use. The design choice we made is that the
user types her user address into the app. There are however other
options.
First of all, we eventually want the app to not see who the user is
logging in as. This should between the user and the browser or device.
Logging in to the browser is probably not going to be mainstream for
another two years or so, but i think it's what we should design for.
Also, although each user has their own storage, it doesn't necessarily
need to be announced per-user, it's probably good enough if it can be
announced per-domain. In other words, the 'user' part of 'user@host'
probably influences the discovery process a lot less than the 'host'
part.
Then, typing in user addresses is a nuisance, especially on small
touch screen devices. We could also make the user visit their storage
first (Francois' storage-first scenario), log in there, and then have
a web intent registered that apps on other tabs can invoke.
So this is all still quite speculative, but it could influence the
remoteStorage spec at some point (maybe using webintents instead of,
or in addition to, webfinger).
I'll discuss it further with surfnet and grnet and also experiment a
bit with webintents, and maybe we can come up with an improvement in
this area.
can it easily be decoupled, such that anybody can create an extension which provides the main unhosted lib with the address of the storage to use? if so it may be an optimal approach, then you can support any configuration / flow both now and in the future. And is much better than Or.
Michiel de Jong wrote:
> I just talked to the grnet guys (who run the federation of Greek
> universities), and the same issue came up as with surfnet: "Why use
> user addresses to discover storage?"
> We need the user to tell the browser where her storage is, and where
> the app is she wants to use. The design choice we made is that the
> user types her user address into the app. There are however other
> options.
> First of all, we eventually want the app to not see who the user is
> logging in as. This should between the user and the browser or device.
> Logging in to the browser is probably not going to be mainstream for
> another two years or so, but i think it's what we should design for.
> Also, although each user has their own storage, it doesn't necessarily
> need to be announced per-user, it's probably good enough if it can be
> announced per-domain. In other words, the 'user' part of 'user@host'
> probably influences the discovery process a lot less than the 'host'
> part.
> Then, typing in user addresses is a nuisance, especially on small
> touch screen devices. We could also make the user visit their storage
> first (Francois' storage-first scenario), log in there, and then have
> a web intent registered that apps on other tabs can invoke.
> So this is all still quite speculative, but it could influence the
> remoteStorage spec at some point (maybe using webintents instead of,
> or in addition to, webfinger).
> I'll discuss it further with surfnet and grnet and also experiment a
> bit with webintents, and maybe we can come up with an improvement in
> this area.
well, we have some flexibility inbetween the app (or rather, the
library modules) and the storage provider.
The app should not have to care whether data is stored locally or
remotely, just like a desktop app doesn't care if your home directory
is on a hard disk or on a mounted network drive.
so we just assume some sort of get-set-remove storage is available,
build our modules on top of that, and then build the apps on top of
the modules.
Storage providers should mainly provide a screen that issues tokens,
and a read-write-web-server that accepts these tokens as http bearer
tokens.
Right now, we say the tokens should be available over OAuth2 implicit
grant, and that discovery of both the OAuth end point and the
read-write-web-server itself should be made possible via webfinger.
This allows us to use the widget we use, which appears inside the app
(no need for browser plugins) and takes the user's user address as
user input.
Apart from the confusion of people who have their email on gmail, but
their storage on OwnCube, there is the concern that the app should not
need to know my email address, and also the fact that in GrNet for
instance, some students don't even have email addresses related to
their SAML identities - they have for instance client-side
certificates.
What is new is that webintents now work natively in Chrome, and there
is a fallback for other browsers i think.
The limited user testing Jan and I did on the widget throughout the
year has shown that it's far from trivial for users to understand what
is expected from them. I think with web intents we can improve this.
it would give a user two options:
- visit an app, click the remoteStorage logo, and have a web intent be
fired. this can then display a list of options based on what the user
has installed (so the user can have an in-browser app that reminds
them who their storage provider is), and if none is installed, the
browser will display what the user's app store of choice recommends.
- visit their remoteStorage provider first, log in, then visit the
apps they want. This can be made even easier if the storage provider
displays a link to 5apps, saying 'go to the apps'
I think the webintent could even establish a postMessage channel, then
that makes the implementation of a storage provider even easier. it
would also fit in better with other webintent-based or webapi-based
services for the same types of data (pictures - device camera;
contacts - device addressbook).
On Tue, Jun 26, 2012 at 5:38 PM, Nathan Rixham <nrix...@gmail.com> wrote:
> can it easily be decoupled, such that anybody can create an extension which
> provides the main unhosted lib with the address of the storage to use? if so
> it may be an optimal approach, then you can support any configuration / flow
> both now and in the future. And is much better than Or.
> Best,
> Nathan
> Michiel de Jong wrote:
>> I just talked to the grnet guys (who run the federation of Greek
>> universities), and the same issue came up as with surfnet: "Why use
>> user addresses to discover storage?"
>> We need the user to tell the browser where her storage is, and where
>> the app is she wants to use. The design choice we made is that the
>> user types her user address into the app. There are however other
>> options.
>> First of all, we eventually want the app to not see who the user is
>> logging in as. This should between the user and the browser or device.
>> Logging in to the browser is probably not going to be mainstream for
>> another two years or so, but i think it's what we should design for.
>> Also, although each user has their own storage, it doesn't necessarily
>> need to be announced per-user, it's probably good enough if it can be
>> announced per-domain. In other words, the 'user' part of 'user@host'
>> probably influences the discovery process a lot less than the 'host'
>> part.
>> Then, typing in user addresses is a nuisance, especially on small
>> touch screen devices. We could also make the user visit their storage
>> first (Francois' storage-first scenario), log in there, and then have
>> a web intent registered that apps on other tabs can invoke.
>> So this is all still quite speculative, but it could influence the
>> remoteStorage spec at some point (maybe using webintents instead of,
>> or in addition to, webfinger).
>> I'll discuss it further with surfnet and grnet and also experiment a
>> bit with webintents, and maybe we can come up with an improvement in
>> this area.
So this is basically the same problem that OpenID had had for a while..
1. Yes you can ask the user to manually type their identifier and then
perform discovery on it (e.g. Webfinger)
2. Yes it should be enough for the app to ask the user for their
remoteStorage provider, rather than for their entire identifier.
They only type their identifier and password once they arrive at their
provider.
In OpenID, this used to be called "Identifier Select".
3. You could have a centralized service where the app can look up the
user's currently selected provider:
http://xauth.org/info/
4. You could have a list of "common" remoteStorage providers and ask the
user to click on the logo of their provider (NASCAR problem).
> I just talked to the grnet guys (who run the federation of Greek
> universities), and the same issue came up as with surfnet: "Why use
> user addresses to discover storage?"
> We need the user to tell the browser where her storage is, and where
> the app is she wants to use. The design choice we made is that the
> user types her user address into the app. There are however other
> options.
> First of all, we eventually want the app to not see who the user is
> logging in as. This should between the user and the browser or device.
> Logging in to the browser is probably not going to be mainstream for
> another two years or so, but i think it's what we should design for.
> Also, although each user has their own storage, it doesn't necessarily
> need to be announced per-user, it's probably good enough if it can be
> announced per-domain. In other words, the 'user' part of 'user@host'
> probably influences the discovery process a lot less than the 'host'
> part.
> Then, typing in user addresses is a nuisance, especially on small
> touch screen devices. We could also make the user visit their storage
> first (Francois' storage-first scenario), log in there, and then have
> a web intent registered that apps on other tabs can invoke.
> So this is all still quite speculative, but it could influence the
> remoteStorage spec at some point (maybe using webintents instead of,
> or in addition to, webfinger).
> I'll discuss it further with surfnet and grnet and also experiment a
> bit with webintents, and maybe we can come up with an improvement in
> this area.
> Then, typing in user addresses is a nuisance, especially on small
> touch screen devices. We could also make the user visit their storage
> first (Francois' storage-first scenario), log in there, and then have
> a web intent registered that apps on other tabs can invoke.
My initial idea for this was that the app gets launched with a
storage_server parameter in the fragment that is used to direct the user
to the correct storage server for authorization. Then it can skip the
entire webfinger discovery.
> So this is all still quite speculative, but it could influence the
> remoteStorage spec at some point (maybe using webintents instead of,
> or in addition to, webfinger).
Maybe it is nice to support three ways: webfinger, webintents, query
parameter indicating storage server...
> I'll discuss it further with surfnet and grnet and also experiment a
> bit with webintents, and maybe we can come up with an improvement in
> this area.
webintents seems also very nice, but maybe a bit hard to discover "feature"?
On Tue, Jun 26, 2012 at 10:49 PM, Markus Sabadello
<markus.sabade...@gmail.com> wrote:
> So this is basically the same problem that OpenID had had for a while..
> 1. Yes you can ask the user to manually type their identifier and then
> perform discovery on it (e.g. Webfinger)
that would probably be the worst one of the options.
> 2. Yes it should be enough for the app to ask the user for their
> remoteStorage provider, rather than for their entire identifier.
> They only type their identifier and password once they arrive at their
> provider.
> In OpenID, this used to be called "Identifier Select".
yeah, asking the user for their username upfront is illogical in some
ways. for instance, if the storage provider uses Persona, then the
user will have to type their email address a second time. also, if the
provider uses a client-cert-based identity, or for instance
VPN/IP-address-based, then you cannot even type it into the app if you
wanted to. :)
> 3. You could have a centralized service where the app can look up the user's
> currently selected provider:
> http://xauth.org/info/
yes, i think it's clear that we need cooperation from the browser. we
were trying to make it work with browserid on the app side, but that
didn't really make sense (the app has no resources to protect, so
logging in to it is silly). webintents are the other new way in which
browsers can help one app communicate with another whenever the user
chooses to allow this. see also
https://groups.google.com/d/topic/mozilla.dev.identity/gD-Kt4EtfSA/di...
> 6. Maybe the work of the OpenID Account Chooser working group is also
> relevant:
> http://openid.net/wg/ac/
yeah, but isn't that meant to go into the RP's login page? i think we
should not design for login pages, but for logging in with your
browser. so the case where you have a Boot2Gecko device or similar,
and your session on the device is directly equivalent with your
session in the cloud. of course it has to be inside the app for now,
but i consider that a shim.
> On Tue, Jun 26, 2012 at 4:29 PM, Michiel de Jong <mich...@unhosted.org>
> wrote:
>> I just talked to the grnet guys (who run the federation of Greek
>> universities), and the same issue came up as with surfnet: "Why use
>> user addresses to discover storage?"
>> We need the user to tell the browser where her storage is, and where
>> the app is she wants to use. The design choice we made is that the
>> user types her user address into the app. There are however other
>> options.
>> First of all, we eventually want the app to not see who the user is
>> logging in as. This should between the user and the browser or device.
>> Logging in to the browser is probably not going to be mainstream for
>> another two years or so, but i think it's what we should design for.
>> Also, although each user has their own storage, it doesn't necessarily
>> need to be announced per-user, it's probably good enough if it can be
>> announced per-domain. In other words, the 'user' part of 'user@host'
>> probably influences the discovery process a lot less than the 'host'
>> part.
>> Then, typing in user addresses is a nuisance, especially on small
>> touch screen devices. We could also make the user visit their storage
>> first (Francois' storage-first scenario), log in there, and then have
>> a web intent registered that apps on other tabs can invoke.
>> So this is all still quite speculative, but it could influence the
>> remoteStorage spec at some point (maybe using webintents instead of,
>> or in addition to, webfinger).
>> I'll discuss it further with surfnet and grnet and also experiment a
>> bit with webintents, and maybe we can come up with an improvement in
>> this area.
<Francois.Koo...@surfnet.nl> wrote:
> My initial idea for this was that the app gets launched with a
> storage_server parameter in the fragment that is used to direct the user
> to the correct storage server for authorization. Then it can skip the
> entire webfinger discovery.
yes, we can defend this sort of setup if we make it part of the 'shim'
instead of part of what the app should implement
>> So this is all still quite speculative, but it could influence the
>> remoteStorage spec at some point (maybe using webintents instead of,
>> or in addition to, webfinger).
> Maybe it is nice to support three ways: webfinger, webintents, query
> parameter indicating storage server...
not so sure... but we can hide all this inside the modules so apps
don't have to know which one is used
>> I'll discuss it further with surfnet and grnet and also experiment a
>> bit with webintents, and maybe we can come up with an improvement in
>> this area.
> webintents seems also very nice, but maybe a bit hard to discover "feature"?
did you try out http://berjon.com/contacts-intent/ ? i think it's
quite easy to discover. if an app triggers an intent for which no
handler is registered amongst the currently installed apps, a search
is done in the web app store, suggesting possible handlers. i don't
know what storage providers would have to do to be listed in those
suggestions, and i think for Chrome these suggestions are curated by
Google, but maybe we can shine some light on that as we go
experimenting with it
I brought it up before, and I still don’t know why it’s inferior to
needing to type in your user address:
Just offer a choice of providers.
Then that person is redirected to their provider. If they are signed
in, they just need to auth. If they are not, they need to sign in+auth
(the storage provider should have a one-page flow for that, like
Twitter).
This is the so-called »Nascar effect«.
First of all, for us it’s not that bad yet, because it’s OwnCube,
5apps or Dutch students (or own server, if you’re hardcore). So it
would only be a stop-gap solution anyway until sign in is directly in
the browser.
Also, the Nascar effect is often cited as one of the negative parts of
OpenID. But the main reason why OpenID did not succeed is that people
don’t see »identity« as something they need to get a new provider for.
We see the Nascar effect everywhere now, where apps provide sign in
with Facebook, Twitter, Github or BrowserID (or LinkedIn, or OpenID
still, etc etc.). And it actually helps people to sign in.
It’s definitely better than now, where people
1) have to know their »user address«
2) have to know that it’s not an email address
3) have to know where to type it in
4) have to type their user name twice (once before the @, then again
on the storage site to log in)
One solution that was proposed is plastering the remoteStorage logo
(with text) everywhere, and I think this is not a good solution / will
not catch on properly. Instead of pushing the protocol name forward,
we should push providers forward. The Nascar effect is just a
perceived bad solution from a theoretical interface design point of
view, but it actually works pretty well.
On Tue, Jun 26, 2012 at 2:37 PM, Michiel de Jong <mich...@unhosted.org> wrote:
> On Tue, Jun 26, 2012 at 10:57 PM, François Kooman
> <Francois.Koo...@surfnet.nl> wrote:
>> My initial idea for this was that the app gets launched with a
>> storage_server parameter in the fragment that is used to direct the user
>> to the correct storage server for authorization. Then it can skip the
>> entire webfinger discovery.
> yes, we can defend this sort of setup if we make it part of the 'shim'
> instead of part of what the app should implement
>>> So this is all still quite speculative, but it could influence the
>>> remoteStorage spec at some point (maybe using webintents instead of,
>>> or in addition to, webfinger).
>> Maybe it is nice to support three ways: webfinger, webintents, query
>> parameter indicating storage server...
> not so sure... but we can hide all this inside the modules so apps
> don't have to know which one is used
>>> I'll discuss it further with surfnet and grnet and also experiment a
>>> bit with webintents, and maybe we can come up with an improvement in
>>> this area.
>> webintents seems also very nice, but maybe a bit hard to discover "feature"?
> did you try out http://berjon.com/contacts-intent/ ? i think it's
> quite easy to discover. if an app triggers an intent for which no
> handler is registered amongst the currently installed apps, a search
> is done in the web app store, suggesting possible handlers. i don't
> know what storage providers would have to do to be listed in those
> suggestions, and i think for Chrome these suggestions are curated by
> Google, but maybe we can shine some light on that as we go
> experimenting with it
> I brought it up before, and I still don’t know why it’s inferior to
> needing to type in your user address:
> Just offer a choice of providers.
> Then that person is redirected to their provider. If they are signed
> in, they just need to auth. If they are not, they need to sign in+auth
> (the storage provider should have a one-page flow for that, like
> Twitter).
> This is the so-called »Nascar effect«.
> First of all, for us it’s not that bad yet, because it’s OwnCube,
> 5apps or Dutch students (or own server, if you’re hardcore). So it
> would only be a stop-gap solution anyway until sign in is directly in
> the browser.
> Also, the Nascar effect is often cited as one of the negative parts of
> OpenID. But the main reason why OpenID did not succeed is that people
> don’t see »identity« as something they need to get a new provider for.
> We see the Nascar effect everywhere now, where apps provide sign in
> with Facebook, Twitter, Github or BrowserID (or LinkedIn, or OpenID
> still, etc etc.). And it actually helps people to sign in.
> It’s definitely better than now, where people
> 1) have to know their »user address«
> 2) have to know that it’s not an email address
> 3) have to know where to type it in
> 4) have to type their user name twice (once before the @, then again
> on the storage site to log in)
> One solution that was proposed is plastering the remoteStorage logo
> (with text) everywhere, and I think this is not a good solution / will
> not catch on properly. Instead of pushing the protocol name forward,
> we should push providers forward. The Nascar effect is just a
> perceived bad solution from a theoretical interface design point of
> view, but it actually works pretty well.
+1 I came to the same conclusion in my account chooser
If you have a WebID you're logged straight in, no password, no fuss, it's
like having a global cookie.
If not you can login with Facebook / Gmail / BrowserID as I figure that
covers a lot of bases.
I dont really love the NASCAR effect, but it's something I can live with.
What I havent yet seen a great solution is the data storage sign up
process. I think that would take some skill in design. Perhaps we have a
similar problem like choosing a default browser, that some operating
systems make you do.
> On Tue, Jun 26, 2012 at 2:37 PM, Michiel de Jong <mich...@unhosted.org>
> wrote:
> > On Tue, Jun 26, 2012 at 10:57 PM, François Kooman
> > <Francois.Koo...@surfnet.nl> wrote:
> >> My initial idea for this was that the app gets launched with a
> >> storage_server parameter in the fragment that is used to direct the user
> >> to the correct storage server for authorization. Then it can skip the
> >> entire webfinger discovery.
> > yes, we can defend this sort of setup if we make it part of the 'shim'
> > instead of part of what the app should implement
> >>> So this is all still quite speculative, but it could influence the
> >>> remoteStorage spec at some point (maybe using webintents instead of,
> >>> or in addition to, webfinger).
> >> Maybe it is nice to support three ways: webfinger, webintents, query
> >> parameter indicating storage server...
> > not so sure... but we can hide all this inside the modules so apps
> > don't have to know which one is used
> >>> I'll discuss it further with surfnet and grnet and also experiment a
> >>> bit with webintents, and maybe we can come up with an improvement in
> >>> this area.
> >> webintents seems also very nice, but maybe a bit hard to discover
> "feature"?
> > did you try out http://berjon.com/contacts-intent/ ? i think it's
> > quite easy to discover. if an app triggers an intent for which no
> > handler is registered amongst the currently installed apps, a search
> > is done in the web app store, suggesting possible handlers. i don't
> > know what storage providers would have to do to be listed in those
> > suggestions, and i think for Chrome these suggestions are curated by
> > Google, but maybe we can shine some light on that as we go
> > experimenting with it
<melvincarva...@gmail.com> wrote:
> If you have a WebID you're logged straight in, no password, no fuss, it's
> like having a global cookie.
not exactly, a global cookie would be bad. WebId still asks the user
if they choose to reveal the identity of their device. it's opt-in.
> If not you can login with Facebook / Gmail / BrowserID as I figure that
> covers a lot of bases.
> I dont really love the NASCAR effect, but it's something I can live with.
> What I havent yet seen a great solution is the data storage sign up
> process. I think that would take some skill in design.
yes. although take into account that sign-up is not always done
just-in-time. A lot of people will get their account when they enter
university or when they join a company or other organization, or when
they buy their freedombox etc.
> Perhaps we have a
> similar problem like choosing a default browser, that some operating systems
> make you do.
i also thought about that, but the big difference is that there, there
is no long tail. that changes it a lot.
On Wed, Jun 27, 2012 at 12:58 AM, Jan-Christoph Borchardt
<h...@jancborchardt.net> wrote:
> Just offer a choice of providers.
only make the ones that we like work, and exclude the others? That's
not an option. Anybody should have the right to become a storage
provider without permission of some centralized decision makers.
> First of all, for us it’s not that bad yet, because it’s OwnCube,
> 5apps or Dutch students (or own server, if you’re hardcore).
i don't think we should design for that temporary situation. At least
you should take into account what it will look like if we add Google
Drive, Dropbox, Iris Couch, Greek students, and freedombox. Especially
in the case of freedombox, the user will have to type something to get
to their own freedombox.
> So it
> would only be a stop-gap solution anyway until sign in is directly in
> the browser.
and then what? how will people sign in directly in the browser? with
nascar? with a user address? with a web address? We shouldn't design a
system we know will break in two years.
"user address" and "web address" are terms we invented ourselves. A
user address is something that looks like an email address. A web
address is a http(s)-based URL. Sorry for the confusion. :)
<perpetual-trip...@wwelves.org> wrote:
> Excerpts from Jan-Christoph Borchardt's message of 2012-06-26 21:58:39 +0000:
>> I brought it up before, and I still don’t know why it’s inferior to
>> needing to type in your user address:
> s/user/account/ ?
Excerpts from Michiel de Jong's message of 2012-06-27 07:14:49 +0000:
> "user address" and "web address" are terms we invented ourselves. A
> user address is something that looks like an email address. A web
> address is a http(s)-based URL. Sorry for the confusion. :)
i wanted to say that IMO technically we always refer just to an account, sometimes calling a person using such account an (account) 'user', a single person can use multiple accounts, many people can use same account, or account can just have digital agent using it... often we identify a person by an account this person uses online to interact with us but I like to keep it clear that on technical level we deal with accounts :)
btw i really dislike term 'user' and myself tend to work with terms like 'userAccount', 'person', 'profile', 'accountHolder' etc.
On Wed, Jun 27, 2012 at 9:13 AM, Michiel de Jong <mich...@unhosted.org> wrote:
> On Wed, Jun 27, 2012 at 12:58 AM, Jan-Christoph Borchardt
> <h...@jancborchardt.net> wrote:
>> Just offer a choice of providers.
> only make the ones that we like work, and exclude the others? That's
> not an option. Anybody should have the right to become a storage
> provider without permission of some centralized decision makers.
Then we’ll add them. Are there any providers we miss? There needs to
be some curation anyway. Yes, anyone has »the right« to become a
storage provider, but if their interface is, say, really shitty, or
their terms are super bad, then they should probably not be featured
in the widget. As it is now, it’s just OwnCube, 5apps (only counts 1/2
as it’s for devs) and, if you’re a student (Dutch or maybe Greek in
the future) your email address.
I don’t know if I made this clear, but of course it will always be
possible to fall back to just type in your user address if all the
recognizing images is too hard and you prefer remembering text. (Fun
fact: recognition is better than recall.) The nascar stuff just helps
people put in their right address – there have been several, also
tech-savvy people who put in @owncloud.com instead of @owncube.com,
which is a ridiculous issue, and it’s our fault.
>> First of all, for us it’s not that bad yet, because it’s OwnCube,
>> 5apps or Dutch students (or own server, if you’re hardcore).
> i don't think we should design for that temporary situation. At least
> you should take into account what it will look like if we add Google
> Drive, Dropbox, Iris Couch, Greek students, and freedombox. Especially
> in the case of freedombox, the user will have to type something to get
> to their own freedombox.
1) Yes, we should design for a temporary situation. We don’t know how
long it will be that way.
2) I’ll just guess that it will take some time until Google Drive and
Dropbox will be added. And then, people can easily identify the logos.
No issue there.
3) Iris Couch is an edge case (not many users) and we can decide
further when it actually works.
4) Same for Freedombox, that will probably take a bit.
We had this discussion a while ago, and two whiles ago also. Not much
changed since then in the landscape of providers – mostly the
students, for whom it is a simple catch-all: »use your university
email address«.
>> So it
>> would only be a stop-gap solution anyway until sign in is directly in
>> the browser.
> and then what? how will people sign in directly in the browser? with
> nascar? with a user address? with a web address? We shouldn't design a
> system we know will break in two years.
Ok, just cut that last sentence.
Point is, expecting people to remember a specific user address and
letting them type it in is acceptable if the audience is reasonably
tech-savvy. If not, then remembering provider icons is more adequate
(limiting those to the most used / popular, and providing a fallback
user address input field for the rest).
We have to curate this a bit, otherwise people will be confused and
get the hell out.
if we stop thinking about the in-app widget for a moment, then we have
much more options.
On Wed, Jun 27, 2012 at 11:30 AM, Jan-Christoph Borchardt
<h...@jancborchardt.net> wrote:
> On Wed, Jun 27, 2012 at 9:13 AM, Michiel de Jong <mich...@unhosted.org> wrote:
>> On Wed, Jun 27, 2012 at 12:58 AM, Jan-Christoph Borchardt
>> <h...@jancborchardt.net> wrote:
>>> Just offer a choice of providers.
>> only make the ones that we like work, and exclude the others? That's
>> not an option. Anybody should have the right to become a storage
>> provider without permission of some centralized decision makers.
> Then we’ll add them.
who is 'we'? (serious question)
the problem with using icons is that it centralizes power on the big providers.
storage-first is much better in that respect. teach people to first go
to their storage provider (they already know how to go to a website,
no need for us to re-engineer that!). So teach users "first, go to
OwnCube". they'll say "ok, i know how to do that (and probably type
'owncube.com' into google ;). once they're on there, it's easy to make
them log in or sign up first, and then go to the app. This also ties
in with there the apps-launch home screen is related to the
OAuth-revoke screen.
the only situation where this doesn't work very well is if people
encounter an app and want to start using it. but there's pros and cons
to all options. in that case, we could still make the widget appear.
for the spec this might mean we would require a grant endpoint and a
revoke endpoint instead of requiring a whole dialog and interface.
actually the whole remoteStorage.js library could be an in-browser app
that talks to the remoteStorage server via webintents + http POST, and
to the app via webintents + postMessage. i'll try to put together a
prototype of that and then we can decide if that's a viable future
direction.
to be clear, this discussion is about something we might decide in the
future, for now nothing will change! All app developers should still
just start using the v0.7 branch of remoteStorage.js during the coming
month (the sync doesn't work yet but you can already see how the
module api will be), and storage providers should still just implement
http://www.w3.org/community/unhosted/wiki/RemoteStorage - this is a
brainstorm discussion and "business as usual" is not affected. :)
Michiel de Jong wrote:
> if we stop thinking about the in-app widget for a moment, then we have
> much more options.
> On Wed, Jun 27, 2012 at 11:30 AM, Jan-Christoph Borchardt
> <h...@jancborchardt.net> wrote:
>> On Wed, Jun 27, 2012 at 9:13 AM, Michiel de Jong <mich...@unhosted.org> wrote:
>>> On Wed, Jun 27, 2012 at 12:58 AM, Jan-Christoph Borchardt
>>> <h...@jancborchardt.net> wrote:
>>>> Just offer a choice of providers.
>>> only make the ones that we like work, and exclude the others? That's
>>> not an option. Anybody should have the right to become a storage
>>> provider without permission of some centralized decision makers.
>> Then we�ll add them.
> who is 'we'? (serious question)
> the problem with using icons is that it centralizes power on the big providers.
> storage-first is much better in that respect. teach people to first go
> to their storage provider (they already know how to go to a website,
> no need for us to re-engineer that!). So teach users "first, go to
> OwnCube". they'll say "ok, i know how to do that (and probably type
> 'owncube.com' into google ;). once they're on there, it's easy to make
> them log in or sign up first, and then go to the app. This also ties
> in with there the apps-launch home screen is related to the
> OAuth-revoke screen.
> the only situation where this doesn't work very well is if people
> encounter an app and want to start using it. but there's pros and cons
> to all options. in that case, we could still make the widget appear.
> for the spec this might mean we would require a grant endpoint and a
> revoke endpoint instead of requiring a whole dialog and interface.
> actually the whole remoteStorage.js library could be an in-browser app
> that talks to the remoteStorage server via webintents + http POST, and
> to the app via webintents + postMessage. i'll try to put together a
> prototype of that and then we can decide if that's a viable future
> direction.
So roughly (from my personal standpoint):
1) The user should have the ability to specify a remoteStorage endpoint
2) The remoteStorage endpoint should have the ability to specify it's comminication protocol (like simple-webdav) and it's auth* mechanisim
3) Automatic endpoint discover (via linked data, web finger, whatever) could/should be bolted on after, if required.
Use-cases / Requirements:
I can quickly make a 'site' which has web-dav enabled, then auth by basic-auth, digest-auth, webid (ssl client cert) and hook in to ldap at the back end if I want to.
As a user of my own would-be applications I want to specify my own storage endpoint quickly and painlessly without using additional technologies I don't want or shouldn't need to.
As a would-be developer of multi-user applications I'd like the ability to automatically assign storage to users, to let them specify their own, or in some cases to select from a pre specified list (perhaps ones which have been deemed to be secure, or support only certain protocols, like only https).
I may wish to use oauth with a multi-user storage provider I create to delegate auth over to twitter/google etc, and have their dialogues popped up from an unhosted application - but this is on an application by application basis, and I'd need it to be completely decoupled from the storage functionality, such that I can swap out how auth is handled and how remote storage endpoints are specified at any point, in any app, without changing the application layer code.
I'd also like the ability to use non authenticated anonymous storage.
In all cases, I do not want the user, or myself, to be _required_ to have a special login / profile provider which specifies their remoteStorage endpoint(s), or even to have this notion of "logged in".
As an aside, personally I know that I'll mainly use AmazonS3, simple webdav storage, and possibly git/svn although I'd much prefer whatever techs were behind the http(s) interface to be of no concern.
On 27 June 2012 09:14, Michiel de Jong <mich...@unhosted.org> wrote:
> "user address" and "web address" are terms we invented ourselves. A
> user address is something that looks like an email address. A web
> address is a http(s)-based URL. Sorry for the confusion. :)
I know I say this often, but just a reminder of the first axiom of web arch:
> On Wed, Jun 27, 2012 at 2:31 AM, elf Pavlik
> <perpetual-trip...@wwelves.org> wrote:
> > Excerpts from Jan-Christoph Borchardt's message of 2012-06-26 21:58:39
> +0000:
> >> I brought it up before, and I still don’t know why it’s inferior to
> >> needing to type in your user address:
> > s/user/account/ ?
> On Wed, Jun 27, 2012 at 1:30 AM, Melvin Carvalho
> <melvincarva...@gmail.com> wrote:
> > If you have a WebID you're logged straight in, no password, no fuss, it's
> > like having a global cookie.
> not exactly, a global cookie would be bad. WebId still asks the user
> if they choose to reveal the identity of their device. it's opt-in.
> > If not you can login with Facebook / Gmail / BrowserID as I figure that
> > covers a lot of bases.
> > I dont really love the NASCAR effect, but it's something I can live with.
> > What I havent yet seen a great solution is the data storage sign up
> > process. I think that would take some skill in design.
> yes. although take into account that sign-up is not always done
> just-in-time. A lot of people will get their account when they enter
> university or when they join a company or other organization, or when
> they buy their freedombox etc.
> > Perhaps we have a
> > similar problem like choosing a default browser, that some operating
> systems
> > make you do.
> i also thought about that, but the big difference is that there, there
> is no long tail. that changes it a lot.
Yes good points, the process of signing up for a storage provider is UX
challenge. It's potentially only a one time hit tho. After that you can
link it to your identity and "follow your nose"
> I just talked to the grnet guys (who run the federation of Greek
> universities), and the same issue came up as with surfnet: "Why use
> user addresses to discover storage?"
> We need the user to tell the browser where her storage is, and where
> the app is she wants to use. The design choice we made is that the
> user types her user address into the app. There are however other
> options.
> First of all, we eventually want the app to not see who the user is
> logging in as. This should between the user and the browser or device.
> Logging in to the browser is probably not going to be mainstream for
> another two years or so, but i think it's what we should design for.
> Also, although each user has their own storage, it doesn't necessarily
> need to be announced per-user, it's probably good enough if it can be
> announced per-domain. In other words, the 'user' part of 'user@host'
> probably influences the discovery process a lot less than the 'host'
> part.
> Then, typing in user addresses is a nuisance, especially on small
> touch screen devices. We could also make the user visit their storage
> first (Francois' storage-first scenario), log in there, and then have
> a web intent registered that apps on other tabs can invoke.
> So this is all still quite speculative, but it could influence the
> remoteStorage spec at some point (maybe using webintents instead of,
> or in addition to, webfinger).
> I'll discuss it further with surfnet and grnet and also experiment a
> bit with webintents, and maybe we can come up with an improvement in
> this area.
I came across a great quote from timbl
"“On the initial design of the web, you didn’t see the http:// when you
were a user. You just read text and you clicked on links,” Berners-Lee
tells Wired. “In the original web browser, you had to bring up a special
link inspector to see addresses. That’s why I wasn’t worried about
http://being ugly. No one would really see it.”
actually we could use https://host/.well-known/remote-storage instead
of webfinger. it would make remoteStorage discovery basically
per-domain instead of per-user. i drafted how the unhosted.org website
could look if we would do that ("appsapp(host)" here means launch an
apps dashboard with launch icons, preconfigured to launch each app
with #remote-storage=host, which could then be picked up by
remoteStorage.js to immediately initiate the OAuth dance, basically
removing the need for the 'connect your remote storage' widget
altogether)
> On 27 June 2012 09:04, Michiel de Jong <mich...@unhosted.org> wrote:
>> On Wed, Jun 27, 2012 at 1:30 AM, Melvin Carvalho
>> <melvincarva...@gmail.com> wrote:
>> > If you have a WebID you're logged straight in, no password, no fuss,
>> > it's
>> > like having a global cookie.
>> not exactly, a global cookie would be bad. WebId still asks the user
>> if they choose to reveal the identity of their device. it's opt-in.
>> > If not you can login with Facebook / Gmail / BrowserID as I figure that
>> > covers a lot of bases.
>> > I dont really love the NASCAR effect, but it's something I can live
>> > with.
>> > What I havent yet seen a great solution is the data storage sign up
>> > process. I think that would take some skill in design.
>> yes. although take into account that sign-up is not always done
>> just-in-time. A lot of people will get their account when they enter
>> university or when they join a company or other organization, or when
>> they buy their freedombox etc.
>> > Perhaps we have a
>> > similar problem like choosing a default browser, that some operating
>> > systems
>> > make you do.
>> i also thought about that, but the big difference is that there, there
>> is no long tail. that changes it a lot.
> Yes good points, the process of signing up for a storage provider is UX
> challenge. It's potentially only a one time hit tho. After that you can
> link it to your identity and "follow your nose"
> "user address" and "web address" are terms we invented ourselves. A
> user address is something that looks like an email address. A web
> address is a http(s)-based URL. Sorry for the confusion. :)
> On Wed, Jun 27, 2012 at 2:31 AM, elf Pavlik
> <perpetual-trip...@wwelves.org> wrote:
>> Excerpts from Jan-Christoph Borchardt's message of 2012-06-26 21:58:39 +0000:
>>> I brought it up before, and I still don’t know why it’s inferior to
>>> needing to type in your user address:
>> s/user/account/ ?
> 3) Automatic endpoint discover (via linked data, web finger, whatever) > could/should be bolted on after, if required.
Little quibble, linked data and webfinger aren't mutually exclusive. You can deliver linked data via webfinger too. It's really important that we think of linked data as being URI scheme agnostic where the only requirement is that URIs resolve to Web accessible resources that bear URI referent descriptions.
Webfinger is HTTP based re. actual data access. Its descriptor resource preference is an XRD document, that doesn't mean said document doesn't bear content in entity-attribute-value or subject-predicate-object graph form etc..
To you larger point: yes, CRUD endpoints should be discoverable.
> On 27 June 2012 09:14, Michiel de Jong <mich...@unhosted.org > <mailto:mich...@unhosted.org>> wrote:
> "user address" and "web address" are terms we invented ourselves. A
> user address is something that looks like an email address. A web
> address is a http(s)-based URL. Sorry for the confusion. :)
> I know I say this often, but just a reminder of the first axiom of web > arch:
> Any resource of significance should be given a URI.
+1000....
Kingsley
> On Wed, Jun 27, 2012 at 2:31 AM, elf Pavlik
> <perpetual-trip...@wwelves.org
> <mailto:perpetual-trip...@wwelves.org>> wrote:
> > Excerpts from Jan-Christoph Borchardt's message of 2012-06-26
> 21:58:39 +0000:
> >> I brought it up before, and I still don’t know why it’s inferior to
> >> needing to type in your user address:
> > s/user/account/ ?
