Diaspora is currently a federated system of independently run pods. If a person wants to log into a different pod to start building up their contacts the only option that they have if to create a new account on that independent pod. This makes the user (think the mass plexodus) think that diaspora is not a combined federated system. I would like to propose implementing a federated login. This would allow a user to create an account on one pod, be it mine <shameless_plug>social.tftsr.com</shameless_plug> or pluspura or any number of other pods out there. Then, if the user opts to log into a different pod to see/find new members, they can simply log in with the 1 account that they have already have. This is how a federated system should work. 1 account allows you to log into any/all nodes/pods within the federation. We are already streaming most data across the federation, so importing a central(distributed) login should be something I think the devs should look into, if not already being investigated.
Well, that’s certainly your opinion, but others, like me, will disagree. Allowing users to use their profile on remote pods would require transferring private data to those remote pods, and to me, that’s absolutely not how federated systems should work, and to be quite honest, those “federated identities” are super hilarious to me, and I don’t know where the idea came from. You wouldn’t expect your example.com XMPP account to work on example.net, and neither would you expect your example.com email account to work on example.net, and that’s because those systems are federated in a manner that keeps control over the users data at the users server…
diaspora* is designed to give you maximum control over your data, and this is achieved by allowing the users to host their own instance and by limiting the data that gets distributed to other pods. If we’d enable some kind of remote login, we would need to share some kind of private information (in diaspora*s case, that’s probably the account’s private key, or maybe a second sub-key of that), which would allow the remote pod to create posts that look like posts you made. This, however, would also put that remote pod in a position where it could do actions in your name, without your consent, and you’d lose control over your identity. Giving away personal information just because™ is actually quite the opposite of what federated social networks should do.
We’ve had multiple discussions around this in the past, here and on GitHub, for example here, and you will realize that your point of view is, in fact, not what most people agree on. In the future, please use the search feature first, and make sure there is no thread about your topic already, and if so, continue that thread. There isn’t much of a point having multiple threads about the same topic.
I’m not a technical person, so I won’t try to get into that side of things, but I can say that this won’t happen in Diaspora.
One of your reasons for wanting to be able to log in to different pods is (unintentionally, I’m sure) a straw man:
There’s no need to do this. You can find all members from your own pod. That’s how a federated network such as diaspora* should work. From your one account on one node, you access the entire network. There shouldn’t be any need to hop around to different nodes in order to be able to do certain things. (There are certain occasions where this doesn’t quite happen as it should, but that is where intended federation of data has failed for some operational reason; and diaspora* should be aiming to reduce the number of those occurrences rather than attempting to give people the option to hop around from pod to pod.)
If you really want a network where identity itself is federated, you could look into Hubzilla, whose philosophy is primarily that of decentralized identity.
The way in which identity should be federated is in enabling users to move their account data, and therefore their log-in point, from one node to another. This migration of accounts is essential to a network that wishes to offer ownership of data, and is something that is in the pipeline. But having to log in to different nodes in order to do what you want? No, that’s not what diaspora* is about. You should be able to do everything you want from one account on one node, as if the network were not federated at all but contained on one server. That’s the ideal this project strives for.
Again, the analogue of the email system is a good one. You wouldn’t want to have to use your credentials for one email provider to log in to another provider in order to contact certain people; you should be able to contact anyone using any email provider from your own provider without having to take any additional steps.
Edit: Oh, I see Dennis got in there first. He most likely put things far better than I have.
@denschub Thanks for your reply. I did do a search, but only seen where the request was to redirect the user back to their “home pod”. I did not want to muddy the waters in the other thread even though my suggestion is similar in nature, it is not the same.
In my case, lets say I go to pluspora and want to log in. I would use my ID of sarman@social.tftsr.com. Pluspora would see that the domain in my ID points to social.tftsr.com and would direct me to that pod for authentication. From here, I would be registered as “authenticated” to pluspora and can continue to go about my business. All this can be done without having to pass or share credentials with pluspora.
The benefit of this is I get to maintain 1 identity across the entire federation regardless who’s pod I log into.
In my day job, I support a federated 911 application. Our largest client has 52 independent nodes. All users across all these nodes authenticate to their “home node”, but are allowed to access the node of choice, or least used (load balanced). Diaspora can be configured this way and maintain security. This is a feature request I would like to see implemented, but if the “coders” as you call it are unable, unwilling then that is that. As a System Administrator myself, I know it is possible to be done. I myself am not a programmer or developer, but I do understand the implications of adding features that were never thought of. Sometimes these features are not practical without a complete code rewrite, which is no small task. My company is currently undergoing a major overhaul because of this.
Thanks for taking the time to read the previous discussion that has been linked. 
You really just compared apples to birds. What you describe is a single-sign-in mechanism, and that’s indeed quite common in many application. That’s also the reason why you can use a GitHub account to sign into this Discourse.
Social networks are different. In social networks, you publish content using an identity that is tied to you. This identity has to be protected in some way, as identity theft in a federated network would be super horrible. We do this by using asymmetric cryptography: we distribute your public key to all relevant pods, but keep your private key secret. Pods do, when they receive an item that claims to be you, verify the signature against the known public key, and if that check succeeds, it will get stored and displayed as something you wrote. This is true for all forms of interactions: posts, private messages, and even likes.
If you want to use your social.tftsr.com account on pluspora to interact on posts, you basically have three options:
- Generate an account
sarman@pluspora.comso that pluspora is able to generate valid signature for your interactions. That’s bad, however, as you’d now have two accounts in the diaspora network and your contacts wouldn’t know which one to add to their contacts (or maybe all?). - Ignore signatures altogether and open the door for identity theft, which is not going to happen. Like, no.
- Provide pluspora with either your main private key, or a newly generated private key. Either way, this would put pluspora in a position where it is able to interact with others in the network in your name. This is bad, as it would put an entity you have no control over in a position where it can act as you. This is against every single principle we have, and is also not going to happen.
This has nothing to do with being “unwilling”, but is rather about the thing we claim on our tagline: “The online social world where you are in control”. Giving away your house keys is, most certainly, not staying in control.
And with that, everything has been said. The previous discussion on this topic has been linked and shall be continued if there is anything to continue, I only elaborated here to provide context for people in need of a tl;dr.