The idea:
Allow users login in any diaspora server.
Users will login in any diaspora server with username@registredserver.tld
Username is his/her username.
Registredserver.tld is his/her server where is user registred.
This solution can access user to registredserver and show data on new server.
I think this would be great step for diaspora.
Technically this can be done. But the developers can say what are they thinking about technicalls problems.
Any questions about this place there, thank you.
Note: This discussion was imported from Loomio. Click here to view the original discussion.
Such feature would be a major privacy/security issue as nothing is preventing a rogue pod to log your credentials as you login and get your data then store it.
@erwanguyader Maybe me explain is not clear.
What do you mean exactly?
Say me difference between security risk in current pod and new pod which can do secure authentification on other server with SSL and good designed API?
I do APIs many years and there can be this feature done preatty secure and maybe better security as current connection on pod.
Actually, Friendica Red provides something similar to this, with one major difference: you can log into any Red server using remote authentication, but your posts and personal information are stored on the site that you created your account on. I think Pump.io might provide something similar as well.
Provided a robust security mechanism is provided for authentication, this could be set up to be neither a privacy issue nor a security one. The question boils down to whether we want this in Diaspora or not.
I vote for yes
Anyway I hate creating new and new accounts on new and new diaspora servers.
For me is enough one account on all diaspora servers.
There is other advantages also, becouse some data can be accessed from registred pod. In me eyes really big step for diaspora project.
BTW: the login with diaspora button can be easy implemented in this solution
What would be the point of it? If you’re going to enter your full Diaspora ID, you know which pod you’re registered with (it’s the second part of the ID), so you might as well sign in to that pod, mightn’t you? What would be the benefit in signing in to another pod?
If it’s to deal with cases in which someone sends you a link to a profile or post which has another pod’s domain name in the URL, I think better forwarding back to the user’s home pod is the way forward.
I don’t think we should encourage ignorance over where you enter your credentials. You should only enter your credentials to the service you registered to and you should pay attention to do so. I also see no benefit, if all data is pulled from your home pod anyway, you still entirely depend on the availability and speed of it.
Login with Diaspora is a totally different game, it’s authentication delegation, that is as a service I rely on a third party to authenticate a user for me. That does not imply access to the data on the third party for my service (beyond some basic profile data in most cases).
I guess we could put something in the code so that if someone enters a Diaspora ID, and the domain is not that of the pod on which they’re trying to sign in, a message pops up saying ‘You need to sign in to [domain name]’.
Anyway I hate creating new and new accounts on new and new diaspora servers.
Why would someone want to do that? Diaspora is a decentralized social network so the basic idea behind diaspora* is to use only one server to talk to all other servers in the diaspora* network.
I am with @goob that the only thing we could provide in this direction is to show a notification when someone tries to log in with a diaspora ID of another pod. But this should be a general warning notification saying something like “never enter your password on a foreign server”.
Anyway I hate creating new and new accounts on new and new diaspora servers.
Why would someone want to do that?
I can only think of two situations in which someone might want to do this:
Because they didn’t understand the nature of a distributed network. In which case the answer is better education, not a system of logging in to remote pods.
Because the imperfect state of federation in diaspora* meant they were missing out on posts they wanted to see on their home pod, and felt that signing up to another pod was the best way to deal with this. In which case the answer is to improve federation (work which developers are already trying to achieve), rather than a system of signing in to remote pods.
Ok, i will answer the questions.
When I sad about login in any diaspora pod i think about make the diaspora network better and more stronger.
When somebody go to diaspora pods he don’t want speculate about which diaspora pod is better for he.
There is many servers and some with closed registrations.
This can access to closed pods too and improve the experience.
How is it possible access to closed pods without registration?
Anyway, when i will create the account on diaspora i must collect many data as: is there chance close this pod?, will this pod be stabile for me?, is the design and UX good for me?, and many more questions…
Now i have closed doors to some pods, but why we can’t open the doors for any pod user, why we have there possibility to deny users to some pods?
Max, I think you misunderstand the nature and philosophy of the Diaspora network. The way each pod is run is the choice of the person who runs that pod. If someone wants to run a pod just for themselves and so does not open registrations, that is their right and we have to respect their choice. We can’t justify to force them to accept signins from people they don’t know, can we?
The beauty of a distributed network is that there are many pods, and within those many pods there will be pods run in all sorts of ways, so there are options suitable for everyone.
Your problem seems to be that it is difficult for a new user to find a pod which suits them, and which they can be sure is stable and going to stay open for a long time. The answer to this, as I said above, is better information to help people choose. We’ve got a page on our wiki about choosing a pod, and podupti.me lists how long a pod has been running, which can help find a stable, long-term pod.
What we really don’t need is some technically complex method for enabling bad practice in users, which also brings many privacy concerns.
@goob let me add another reason from the German speaking diaspora* community to your list:
Privacy concerns.
Since Germany seems to be involved in certain kind of surveillance against the citizens, one user opted to switch to a pod placed in Armenia (no comment, please).
In this case, moving the account details would be fine, too.
Oh, and a fourth reason comes to my mind:
Forgot login credentials/hacked account.
I remember a user, who created another account (on a different pod) out of this reason.
But @ryunoki, neither of your examples touch on this at all.
In your first example what that person wants is for their account data to be moved in their entirety to the new pod - they wouldn’t want their account data to be retained on the old pod in Germany. That is account migration - it’s not what’s being proposed here, which is for the account data to remain on one home pod but to be able to sign in to that account from another other pod.
In your second example, if you couldn’t sign in to your home pod because you had forgotten your sign-in details, what use would be the facility to sign in to another pod using those same details that you had forgotten? No, what you need is a means of recovering those sign-in details, not the means to sign in to other pods using those same details.
@goob thank you for explain.
Maybe me idea isn’t an same line as project, but I respect the roadplan. And of course other users.
Second point: podupti.me is really bad site for check the pods.
Why?
The are security issue with location, maybe bad data about location when is used anonymisation service and other issues.
Design isn’t good, but this is me opinion. (maybe for someone other is ok)
I don’t understand the ad there. (But maybe when is there need of ad, it will be at bottom…) Me opinion too.
Maybe there would be nice the change, i mean other idea of finding pod.
The information about pod can be stored in pod and when admin enable sending the information to information central, the pod can send the data there.
Or second type, there can be special meta tag or json file which will inform the page about running pod.
When admin setup the file and add pod to the database, the page can be informed as well.
This will be more nicer as current status…
