Signing into a pod using another pods account

This is my own personal user experience case.
After joining and setting up one pod (, I tried to connect with another friend who was on
We could not see each other because of the federation issues.
I expected to be able to sign in to joindiaspora with my username and enter the password.
It just said wrong user/password.
Ideally I expected joindiaspora to to openauth connect me to

While this still may be complicated, as it is related to user migration and other more complex things, one could do one of 2 things:

  • redirect to the signin (generally bad ux)
  • a notification with a link: “Did you mean to sign in to”

Note: This discussion was imported from Loomio. Click here to view the original discussion.

Unfortunately, I don’t think this is how any federated social network is intended to work, at least not right now. The problem is that either the pod would have to store everyone’s login credentials, or it would have to oauth back to your home pod. Both methods are unfortunately non-starters, I think.

I would say that it is more relevant to open up issue #908 “Seed Migration Wizard” is more important and relevant as a function today. It would open up for an easier way out if one’s pod is shutting down, so that one doesn’t lose all that one has done on a pod.

I think this is a really bad idea and a very good way to confuse users when I federated social network is already going to be a difficult concept for a lot of people

Also I thin the solution to the problem you’ve described is to improve D federation

Agree with the points below - the whole concept of Diaspora is to be able to connect seamlessly with anyone else on the network, regardless of which pod you are on and which pod they are on. This is crucial so that you can know where your data reside, and have security that these data won’t be shared outside without your knowledge.

This concept does not currently work properly, because the problems of federation of data between pods caused by this being a decentralised network have not been fully solved.

The answer to this problem, however, is to solve the federation issues by further developing the software, and not to allow people to sign in to different pods using the same account.

Please be patient - this is still experimental software, in development, and not a finished network. If you or anyone you know is in a position to help improve and develop the software that runs Diaspora, please do help, as we need as many people as possible.

I totally agree this is a problem. A lot of my friends who are on don’t even know what is a pod, and when they want to go on diaspora, they search “diaspora” on google and arrive on So they are not able to log in, of course.

I proposed to make a search when the login is unknown on a pod to propose to the user something like “It seems you are on the wrong server, we find you on free-beer, click here to go to this pod”.

But the answer I get is “this can be a privacy issue : everybody will be able to find your handle with that”. For me, it is not a problem…

By the way, I’d love to implement Mozilla Persona on Diaspora, and this will solve everything. But I don’t know ruby right now, so I have to make some research first…

I’ve been taking a look at Dennis Schubert’s work on integrating Mozilla Persona with Devise, the Rails authentication system. Aside from needing to properly call the javascript to make the button work, setting it up would be fairly easy.

However, we still have a fundamental problem with decentralized sign-in, and I have to reiterate the importance of this: not every pod has every user’s credentials. It can’t just look up your login email or username, because the login system will either look for your email address and not find anything in the database, or it’ll look for your username, which always becomes [username here]@[pod url here].

We would have to implement some kind of way to redirect a person to the proper pod, and I’m not sure there’s an easy way to do that when the core principle is that pods don’t hold on to everyone’s data. A pod can’t redirect you if it doesn’t know you.

Surely this proposal would need the users to login not with their username, but with their webfinger-adress.
Persona-support is nice and would contradict to this proposal, I think. Actually I don’t really see the need for this proposal and agree with Goob. The most problems are solved once federation is solved.

When I’m using an email like I also wouldn’t expect to be able to check my mails at hotmail, would I?

Perhaps the log-in page could in some way encourage people to sign in with their entire Diaspora handle. That way, the pod can tell them which pod they belong to if not the one they’re trying to sign in to.

Alternatively, if a user name is not recognised, a message could pop up saying something like

‘Are you sure your account resides on this pod? Diaspora is a decentralised network, and users can only sign in to the pod with which they created their account. You can tell which pod you account resides on by looking at the second half of your Diaspora handle (after the @ symbol). A list of open pods can be found at .’

Something along those lines - so that if someone tries to sign in to the wrong pod, it at least tells them that this is what they’re doing, and prompts them to seek out the right pod.

It must be a fairly small percentage of people who can’t work out what a pod is, or who regularly use a Google search to find Diaspora rather than eg using a bookmark, mustn’t it? I don’t see this as a major issue - a simple error message on failed sign-in might suffice.

When I’m using an email like I also wouldn’t expect to be able to check my mails at hotmail, would I?

I don’t understand your comparison.

Anyway; if we implement Persona, we must not use the Mozilla provider : every user will be forced to register in another service and we don’t want that. The solution is to transform a pod in a Persona provider and to use the handle as the id.

So in every pod, every user will be able to log in using this handle (the same used today). For the moment, if a user log in the wrong pod, we can just redirect him to his pod (he is logged anyway) which we know because the handle contains the good pod.

After, we will certainly be able to do great things in federation thanks to this. And outside of Diaspora, Persona will give us the exact possibilities than Facebook Connect. No need to register on diaspora-project or any other website which implements Persona.

If Github (hard to do) and (possible) implement Persona, everybody will be able to participate to the whole tools of Diaspora with only his Diaspora account. The Dream !!

Flaburgan, I’m not quite sure if I missunderstand you or if I missunderstand persona. But persona is an alternative to oauth, much easier to implement and most likely easier to use for the user. So if a user wants to log into a “wrong” pod, what should happen exactly? Should the user be redirected to the “correct” pod (in this case we wouldn’t need persona actually) or should he/she be logged in using persona? In the latter case I guess he/she would get a completely new account on the “wrong” pod. At least this is how I understand persona.

I think you missunderstand Persona :wink:
This is a way to externalize the authentication.
You can read that :
and if you want to see how it works :

Thanx for the links, Fla. I need some time to reed them. But I believe you (as you are are involved in the mozilla-project) that persona is a little different to a simple alternative to oauth. When I have questions I will post them here again.

Since the new discussion on this topic was closed with reference to this post, I take it we bump a 6 year old discussion in favor of a new discussion.

I would like to point to an option that would make it possible to log in to another pod without the need of exposing profile or credentials of the account that logs in,

In the sysadmin world there is an option to use RADIUS to authenticate. What RADIUS does is asking the original pod if the credentials entered are ok and depending on the return of the original pod, the account gets granted access to the pod.
I think this would be troublesome when authenticating with an email address, since it would be difficult to find the home pod of the account that is signing in, but basically it should be possible to get authenticated this way.
It still would be possible to get your credentials compromised to rogue pod(min)s. This could be solved with some kind of 2 factor authentication… (just brainstorming out loud here)