Interapp API, Connecting instances

[micflan]

A discussion on connecting instances, following from the idea proposed here:
https://github.com/grand-decentral-station/concept/blob/master/concept/apis.md#connecting-instances

Technically that might be sound but in terms of experience, if we're talking about 'applications for everyone', I think we've already lost the majority at step one – "Joe puts the URL...".

If I can dream a more elaborate dream, how about we offload as much of this authenticating as possible to the browser. Authenticate Joe at the browser level, perhaps through or along with a browser plugin, and allow for near-one-click connections and interactions on other GDS sites and services.

It would have positive implications across the board but specifically in terms of social networking, I think anything less would be too much a step backwards compared to existing centralised networks.

I'd only have half an idea myself on where to start looking for solutions to these ideas, so I'm just putting it out there for now. It strikes me as a problem that's worth looking into.

[janl]

Mozilla is working on browser log in :)

[micflan]

Yeah, that's right! I've not looked into it yet but might be a good place to start. I wonder how compatible it would be, assuming that Joe needn't be logging in to Rick's GDS instance in the traditional sense, more arriving and saying "hey, I have one of these GDS things too! Let's share some stuff!"

[lukasbestle]

What about something really simple like this:

1. Rick wants to share some of his photos with Joe
2. Rick adds the user id of Joe ([email protected]) to the list of people with access and can give him write or only read privileges.
3. Rick's GDS pings the GDS of Joe at the domain domainofhisgds.tld
   • If there is a GDS living under the domain domainofhisgds.tld, Joe gets a message telling him he has access and can then see the content from Rick's GDS just like it would be stored on his own one
   • If there is no GDS living there (= normal email address), Joe gets an email telling him that he can now interact with Rick's data using a secret (and long) share URL pointing right to Rick's GDS
4. Done

[micflan]

Sounds good! At the very least it's a more concise outline of the approach :)

A reverse scenario should also be allowed for. Perhaps:

1. Joe arrives at Rick's social profile / website / service and wishes to connect
2. Joe pushes the 'connect' button. As a pre-authenticated GDS user ([email protected]), a connect request is sent automatically to Rick.
3. Via email or web interface, Rick can accept or deny Joe's request.
4. Done

[bastianallgeier]

Those kind of interaction flows is exactly what we need. This is the stuff that either makes it easy for people to use the system or which frustrates them and keeps them away. We should start a dedicated place for such interaction flows and graphs soon.

[lukasbestle]

A possible problem of this approach could be spam bots hitting that "connect" button all the time.
That's a reason why you can only invite people into shared Dropbox folders.

[augustl]

Perhaps sharing data between GCD instances should use APIs that aren't specific to GCD. Let's say that the calendar app the user has installed implements CalDAV. Then all that's needed is an authenticaton mechanism for other GCD instances, or any app be it web or native that talks CalDAV.

For APIs that doesn't have well specified standards such as CalDAV, we could specify them as part of the GCD project, such as a file sync API (there's no commonly used spec here that I'm aware of at least).

[micflan]

@vis7mac spam, of course, is a concern :(. Facebook style "discoverability" options could be available, such as only allowing friends of friends, or members of certain social groups, to make requests.

[lukasbestle]

That's a bit complicated for the user to control.
The most simple solution would be to control user permissions on your own.
Of course, there could be ways to take some workload from the user when doing that, but the base "give users permission" instead of "let the users request permission" is the easiest to understand.

[sternenseemann]

@micflan A function to block GDS-Instances might be also useful in case of spam

[micflan]

I'm not sure of the complication from a user point of view. Importing an existing contact list is an acceptable step 1 of any 'sign up' process, after which friends-of-friends is an acceptable default to have. Presenting a single option to switch instead to "invite only" shouldn't confuse things either.

Hopefully not short sightedly, but I'm really thinking in terms of the Facebook style casual status and photo sharing application. I want that stuff under my control, and I think even non-technical friends could be convinced that's a good idea, but it's not going to fly if making connections is more difficult than the current social networking standard.

[lukasbestle]

Jep, a simple toggle is definitely a nice idea!

[augustl]

Are there existing protocols for distributed auth token stuffs that we can reuse? OAuth comes to mind, but that's mostly for giving users access to their own stuff from 3rd party services.

[lukasbestle]

I guess the notion of public and private keys (asymmetric encryption) would be quite perfect for that as @lx4r already proposed.
Every GDS should have a public accessible key to send encrypted messages to it.

[augustl]

Pub/priv keys would be great :) If that's part of the core protocol, one could even implement a "3rd party" messaging app that isn't e-mail but just sends encrypted messages to GDS instances you've connected with, using APIs that doesn't let you access the private key itself (the private key should definitely only be accessible to the GDS "kernel", not apps), but decrypt data with it.

[lukasbestle]

Jep, that would be totally cool!!

[waaaaargh]

I like the idea, it could also solve some of the usability issues that GPG/PGP has at the moment.

One other thing, though. I think you can in fact use SSL Client certificates for logging into websites. CACert (http://cacert.org) offers that. Implementing that could be kind of a pain, though.

[lukasbestle]

Yeah, you could use client certs. But I don't think they are convenient enough:
If you get a new PC or your hard drive crashes, the certificate and private key are lost if you don't know how to migrate them - this could be too complicated for quite a lot of people.

[waaaaargh]

If you get a new device, you login with your password and generate/install a new cert. If you lose a device, you disable/delete the public key on the instance. You could probably do the crypto stuff without the user even noticing it, just tell them, "you have to register your device in order to use GDS".

[lukasbestle]

Hm, but if there is a possibility to login using the password - why are the client certs making it more secure?

[augustl]

The client certs means we get asymmetric crypto, so the password is never transmitted over the wire, for GDS-to-GDS comms.

[augustl]

Note that client certs are mostly glorified public keys. I don't think GDS needs a concept of a certificate authority and expiration dates. If GDS just uses pub/priv keypairs directly, that should be sufficient me thinks.

[lukasbestle]

We could just use SSL for the client communication, right? :D
Inter-GDS: Yeah, every GDS has a public/private key pair.

[janl]

SSL also has client and server certs and could be used for server2server communication :)

[augustl]

Shameless self promotion (kind of), I did a talk where I explain (among other things) how you can use plain ol' RSA keys. About 34 minutes in. http://vimeo.com/74406482 It should demonstrate why plain pub/priv keys is all we need. Unless of course we want "central" (?) certificate authorities and expiration dates, where X509 certificates excel.

[lukasbestle]

Yeah, basically, it’s the same.

What I mean:

• GDS-GDS: Every GDS has a public key to encrypt data so it can only be encrypted by the „GDS kernel“.
• GDS-Client: Normal HTTPS