New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How users find which server they need to talk to? #125

Open
almet opened this Issue Jul 8, 2015 · 15 comments

Comments

Projects
None yet
4 participants
@almet
Member

almet commented Jul 8, 2015

We need to find a way to have users chose which server they want to use.

There are a lot of exploration to do here around this idea, but thinking about that while it's not too late and that we don't have a completely centralized service would prevent us from redoing the same error some other projects did.

@almet

This comment has been minimized.

Member

almet commented Jul 8, 2015

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

@almet almet changed the title from Explore how to deploy kinto in a decentralized way to How users find which server they need to talk to? Jul 8, 2015

@Natim

This comment has been minimized.

Member

Natim commented Jul 8, 2015

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

@Natim

This comment has been minimized.

Member

Natim commented Jul 8, 2015

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.

@almet

This comment has been minimized.

Member

almet commented Jul 8, 2015

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

@Natim

This comment has been minimized.

Member

Natim commented Jul 8, 2015

👍

@michielbdejong

This comment has been minimized.

Contributor

michielbdejong commented Aug 25, 2015

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

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 me@example.com 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.

@Natim

This comment has been minimized.

Member

Natim commented Aug 25, 2015

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

@almet

This comment has been minimized.

Member

almet commented Aug 25, 2015

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.

@Natim

This comment has been minimized.

Member

Natim commented Aug 25, 2015

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.

@almet

This comment has been minimized.

Member

almet commented Aug 25, 2015

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.

@Natim

This comment has been minimized.

Member

Natim commented Sep 10, 2015

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

@michielbdejong

This comment has been minimized.

Contributor

michielbdejong commented Sep 10, 2015

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.

@almet

This comment has been minimized.

Member

almet commented Sep 10, 2015

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!
@rektide

This comment has been minimized.

Contributor

rektide commented Dec 14, 2015

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.

@almet

This comment has been minimized.

Member

almet commented Dec 23, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment