DIASPORA has a solid foundation, in many ways, but has lacked on adoption in a serious way. I think this may be due to a single root cause.
Our network does not work like other services such as Facebook or Twitter. Due to the centralization of those servers, it is trivial for external applications and services to make API calls to retrieve public data. You make one API call for authentication, then another to manipulate or retrieve data, and they’re always in the same place, at the same domain, and return the same thing. Due to our design, DIASPORA can not work like this. At this time, we are imposing developers to implement a way to do this in their own apps. This is none of our apps are consistent, and IMO why app developers typically “give up” on us.
What we need is a single domain to relay some of this authentication and routing data from a central location to the pod that the user chooses. I want to be able to go to one place, enter in my username/password, and be redirected to my pod, already logged in. To keep true to our philosophy, this application should just relaying information back and forth without saving any authentication data or even tracking who visits the page. Basically it takes in a username/password, parses out the username for its pod address, and routes to the POST /users action on that pod. This logs the user in and redirects them to the pod’s user dashboard, where they are free to use the DIASPORA network just as if they logged into their pod directly. Passwords would be typed in here, but never actually saved, instead they are encrypted and sent securely over the wire to the pod server (designated by the "@poddomain.com" part of the username string). As the SSO app would also be a Rails app, we’d expose the RESTful API so applications can use this server to log in as any user to any pod (provided the correct credentials are given).
Ideally, I’d like http://joindiaspora.com to not be a reference implementation, but where we store the SSO server. So to log in or to make RESTful API calls for authentication, one would simply have to visit joindiaspora.com. This would also encourage community pod adoption and perhaps question whether we need the main reference pod at all. It was always my understanding that the eventual goal of the project was to have the community sustain it, leaving the reference implementation would no longer necessary.
Is this even possible?
Note: This discussion was imported from Loomio. Click here to view the original discussion.
I completely agree about everything you said. If Diaspora is to flourish, it must have single sign on capability. I also envision Diaspora becoming “the” way to sign in to accounts on other websites, much like Facebook is today. I think the centralized domain would work only if Diaspora builds itself as a super legitimate and non-evil Non-Profit internet service taking many cues from The Wikimedia foundation.
Each pod should be an Identity Provider using the browserID protocol and then applications could provide a Signing in using Persona with possibility to fetch data from Diaspora if the user provides a Diaspora account as her identity.
@jonnehaß, I’m all for using an open standard, in fact I’d prefer we use the tried-and-true OpenID if we can use it. Persona is another good suggestion but if OpenID fits our needs, I’d go with that since it’s more “battle-tested” from being around so long and having a presence in the wild.
One concern I have with this SSO method is privacy. I don’t want a central server knowing about what authentication data passes through it. Do either of these services allow us to simply pass the authentication data onward to whatever pod needs to receive it? This is somewhat of a dealbreaker, in order to maintain our privacy policy we need to ensure that the pods, and only the pods, receive authentication data, that way if this server is somehow compromised it won’t be endemic to our entire network.
So, I take it we’re favoring this SSO concept, but implemented with 1 of 2 solutions: Mozilla Persona or OpenID. Let’s hear the pros and cons of each, by those who have researched them.
One of the Tent architects here-- wanted to mention this proposal: http://www.loomio.org/discussions/1522. If Diaspora adopted Tent as a backend, (decentralized) single sign-in is part of the package. We’re also working with the Mozilla Persona team to make sure Tent takes advantage of sites that offer Person signin.
I don’t know to much about tent but now it seems the complexity of this conversation has just jumped. Assuming both Tent and Persona are real options that maintain the privacy policy, then the outcome of the decision would affect whether or not we want to support a major overhaul of the backend. Keep in mind that using Tent was voted down on that discussion link. I feel like we need a onetime big and structured (yet open) visioning process that sets some major priorities for all to see. Sure would make a ton of decisions easier.
@taylormcleod sorry about that. Christmas and my aunt passing away helped me to ignore this Loomio for a minute.
@danielsiders don’t get me wrong, I’ve been hacking on Tent for days now. But it doesn’t really solve our problem. As I said in that Loomio, I’d like to talk with you guys on diaspora-dev or something so we can actually bang out the specifics of a possible partnership between the DIASPORA project and Tent, because ever since I first learned of tent.io I’ve wanted to work with you guys, since I feel we really have some of the same goals. In many ways, I feel that if Tent and DIASPORA joined forces, it would actually get a lot of non-hackers into Tent, because simply by joining a DIASPORA Pod they now have access to the whole Tent network.
Aaaaanyway, I don’t think Tent is an SSO solution because you still need to know which pod to talk to. This is sort-of on a larger scale, you go to logintodiaspora.com and it REDIRECTS you to your home pod, wherever that may be. It’s for APIs and possibly OAuth-like authentication techniques to easily access the network without having to know what pod you’re from all the time. In my opinion, apps and clients of DIASPORA shouldn’t need to know that i’m from s.psychedeli.ca but I’m talking to you on diasp.eu…
@tomscott Persona relies on identity providers. If each pod is turned into a provider, then Persona will contact the right provider when a user enters its credentials.
@erwanguyader interesting. does it support a central location by which people can enter in their information? that’s really what i was looking for here. the way we implement federated auth underneath that concept is somewhat irrelevant right now (when we begin making decisions on HOW this is to be implemented, then we can talk about whether we want OpenID or Persona or whatever).
Additionally, doesn’t Persona feature password-less authentication, entirely handled on the local machine by the browser? That doesn’t seem to fit in with our paradigm, as we do use (secure) passwords to authenticate users, and our authentication logic is handled on the server. Plus, from what it looks like Persona was developed for adding quick user identification and authentication to a site for things like comments or stuff that people shouldn’t have to register an account with a password and all kinds of bullshit information for. It wasn’t designed for systems like DIASPORA, where the primary motivation for using such a product is to have your information stored somewhere that you trust.
Guys, “decentralized” and “federated” are big words. And not just in amount of letters, they’re becoming buzzwords thanks to a growing awareness of both privacy and the practices of large, centralized corporations by the general public. We need to have sharp eyes when looking at new technology, otherwise we might end up driving this project down so many rabbit holes that people will lose interest. It already happened once, I don’t want to see it happen again.
@tomscott What do you mean by central location to enter in information ? If you mean a web page on which people enter their email address and password, yes : login.persona.org
I haven’t played with Persona yet but from what I understand, we wouldn’t handle authentication on Diaspora anymore. Or we would do it by implementing the BrowserID protocol.
I like this idea, but will it be sufficient for API clients? That’s really what I wanted to learn from this discussion. It looks like BrowserID is a fine implementation of distributed identity for the browser, but is this useful on platforms that might not have access to the “whole web” like iOS or Android apps?
@tomscott why wouldn’t they have access to the whole web ? By the way, there is a native implementation of the Persona login for iOS and it works pretty well on Android.
@erwanguyader they do, but sometimes in limited amounts. i know that I find apps to be “clunky” when they require an iOS UIWebView pane to connect to a service, and if we required all apps to connect to DIASPORA that way, all the time, I feel that would be a little annoying.
I searched (for “mozilla persona ios” and “mozilla persona android”), but couldn’t find anything that looked remotely like a library. Do you see anything that we could just tell app developers to use, or perhaps wrap with our own library for authentication purposes? That would be the key ingredient. I’d be down with Persona if we could ensure access for all app (and any other client) developers on practically any platform.
@flaburgan mind joining back into this discussion? persona is looking more and more like a viable option for this. how doable is creating a persona server that actually does require a password when logging into the pod?
Hi ! Sorry, to no answer before. I’m not a native english, so it is hard for me to explain clearly here. I propose to you to go talk with the devs behind Persona on irc.mozilla.org#identity. They are really helpful. I will try to ask someone to subscribe here.
Btw, why do you want to require a password for log in using Persona ? I mean, of course, there will be a password, but you will not need to enter it each time you log in, and this is great, isn’t it ?
But it doesn’t really solve our problem. As I said in that Loomio, I’d like to talk with you guys on diaspora-dev or something so we can actually bang out the specifics of a possible partnership between the DIASPORA project and Tent, because ever since I first learned of