How users find which server they need to talk to? about kinto HOT 16 CLOSED

Potential solutions for this are WebFinger or the Mozilla Token Server (which assigns users to a node).

from kinto.

One thing we had in mind is also to use a kinto interface for storage service providers (such as Box.net/Dropbox, BaiduYun)

from kinto.

After discussion the basic idea would be the following:

• To use your personal bucket, FxA gives you the URL of your personnal storage server (you are always using it)
• You can create a bucket on any server (could be yours) but when you share it you need to share the full URL (including the server hostname)

An idea could be to use a kinto router that gives back HTTP 307 with the right URL for a given personal bucket.

from kinto.

We could first try to hit a webfinger URL and fallback on FxA if no webfinger document is found.

from kinto.

👍

from kinto.

I think discovery in FxA is based on BrowserID? So:

• the user gives their email address [email protected] to a Kinto client
• the Kinto client retrieves https://example.com/.well-known/browserid
• if this resource does not exist for example.com, it falls back to BrowserID's secondary identity provider, from there to Mozilla's default FxA instance, and then to Mozilla's default Kinto instance.

So I think what a user has to do to self-host and be entirely free from any hard-coded Mozilla URLs, is to become their own primary identity provider for BrowserID, plus FxA, plus Kinto?

There is still a difference between remoteStorage and Kinto in that remoteStorage redirects the user to https://remotestorage.io/get/ which lists multiple options for getting an account on a storage provider somewhere, and I think Kinto currently would default silently to Mozilla's instance. So you could insert a page in the UI saying 'You have no Kinto server linked to [email protected] yet, do you want to link Mozilla's server?', and then that would be a point where multiple options could be offered.

Of course, the user experience is easier when defaulting to Mozilla-hosted is silent. But I think the difference boils down only to whether this is silent or not; in itself, BrowserId already implements decentralized discovery.

from kinto.

On Kinto side we are not using BrowserId but Bearer Token for FxA.

from kinto.

Kinto itself is not tied to any authentication mechanism. We are currently supporting FxA via OAuth 2.0 bearer tokens, and could also support BrowserID if needed.

Since the current best practice to connect to FxA is to use OAuth2.0, and this is completely unrelated to how the discovery works, I think we need to find a better way to support that.

Web Finger seems an option here, especially because it's defined in an RFC and easy to implement. I have left to find if there are other easy ways to do this. I'm thinking about DNS TXT records or files that an user could deposit on their domain, but that restricts to people who owns some domains.

In the case we don't find such document, we might also fallback to a repository (operated by mozilla) where users link to their kinto instance.

from kinto.

we might also fallback to a repository (operated by mozilla) where users link to their kinto instance.

It is what I had in mind, we could operate this repository using a Kinto server.

from kinto.

It is what I had in mind, we could operate this repository using a Kinto server.

In any case, this repository should mimics the semantics we're using for user discovery. e.g. if we use webfinger for discovery, then we should have something with the same semantics that runs on our infrastructure.

from kinto.

My take on this, is to be able to talk to any kinto server and access your data.
One way to do so would be to use https://ipfs.io/ Read this article

from kinto.

Right, BrowserID decentralizes identity, but not service discovery, so we still need something like WebFinger.

So WebFinger could announce:

• The URL of the server
• The API of the server (would be nice to keep it generic, so the same mechanism can be used for announcing Kinto-compatible as well as remoteStorage-compatible, CouchDB-compatible, *-compatible servers)
• Any available end-points for getting access through BrowserId/FxA
• Any available end-points for getting access through OAuth2 implicit grant flow

WebFinger links need a "rel" attribute to indicate what they mean. For remoteStorage discovery, we use this: https://tools.ietf.org/html/draft-dejong-remotestorage-05#section-10 - might serve as a basis for something generic enough to also discover servers with <storage_api> == "kinto-v1".

The remoteStorage spec currently used the "http://tools.ietf.org/html/rfc6749#section-4.2" property for announcing the dialog URL for OAuth2 Implicit Grant, but if we want a "discover the user's storage server of any kind" mechanism, we can add a longer list of possible auth mechanisms.

from kinto.

For completeness, here is the proposal I submitted for an outreachy intern:

The Kinto project aims to bring storage instances to everyone,
attached to their Firefox Accounts. It actually supports multiple
authentication schemes, but FxA is integrated with it, and that is
part of the solution we want to deliver.

Currently, Kinto is thought as a centralized server: there is one
instance, and everyone authenticates on this instance. Items are
shared between users of a same instance.

This doesn't resonates well with multiple goals we have: scalability
is harder when there is one endpoint, and it's also not interoperable.
For instance, imagine Alice and Bob. Bob is using Mozilla's servers to
store his data, whereas Alice deployed her own Kinto instance.

There are different use cases:

• Alice wants to use Routina [0], an application that stores its data
  inside a Kinto instance. As such, Routina needs a way to discover
  where it should store its data, and send the requests to this server;
• Bob and Alice want to collaborate on a set of data (think about a
  shared expense webapp). There should be a way for Alice to host
  everything and grant access to Bob to her data. The webapp should be
  able to use the correct server.

Here are the different steps that could allow these scenarios:

• At the moment they authenticate, the client detects the email adress
  used, and relies on the domain part to do a Web Finger request on the
  domain ** and for the specified user.
• In case the identified server doesn't support WebFinger, it uses a
  central repository to lookup where the Kinto server is located.
• Once the Kinto server located, all requests should be issued against
  this server.

** It is also possible to use the same mechanism to discover the FxA
endpoints. But as FxA isn't a federated protocol, users from one FxA
realm would need to be accepted explicitely by the Kinto server, in
its configuration.

In terms of code changes, here is what it looks like (roughtly step
bystep):

• Update the Kinto.js client to find the server location. It should
  first rely on WebFinger;
• Create a central repository. This could be contained in the FxA
  profile server or in a central Kinto collection;
• Update the Kinto.js client to fallback to this central repository in
  case no Web Finger exists;
• Investigate on ways to store this information directly in the web
  browser. It could also be configurable by the javascript client (with
  an UX that looks like what Remote Storage proposes).
• Work on the first user experience: how can client learn they can
  chose which server to use?
• Ship it!

from kinto.

WebFinger scares me a little because it seems to imply to me that the workflow would be a user entering their webfinger identity, and getting back the store for that user. If this interpretation is correct, that may be distributed, but it's very 1:1. What happens when I want to Kinto into some group resource, for example a Shared Calendar?

If we used something like Host Meta - 4.2 Resource-Specific information, a service could let a user log in with their- say- email, and then query whatever hosts they wanted to see if there were <Link rel="application/kinto" href="..."/> (for example) resources on any hosts pertinent to that identity-resource. Multiple resources could be returned. And the host could also enumerate site-level resources available, for discovering group resources.

I suppose each Kinto "resource" could just get it's own WebFinger ID. I'll try to find more time to better consider and understand the proposals above, but I see some mirroring of the concerns I have about tightly coupling identities to Kinto data-pools.

from kinto.

See @oak11's article about how servers will be discovered. http://www.servicedenuages.fr/en/discovery-of-kinto-servers

from kinto.

Archiving old issues.

from kinto.