Mastodon: Suggestion: Let me "delegate" a username to another Mastodon instance

Created on 8 Apr 2017  路  8Comments  路  Source: tootsuite/mastodon

In #1202 I talk about wanting to be able to have e.g. [email protected] as my username but https://mastodon.example.com as the actual Mastodon instance. The use-case here is allowing me to use my email address as my username.

An alternative approach, that might actually be better, is allowing me to "delegate" my username to another Mastodon instance, using some sort of /.well-known/foo response. This way I can set up [email protected] as my username and have it "delegate" to e.g. [email protected], so that way people can follow me as [email protected] and, under the hood, it really follows [email protected]. This approach is attractive in that a) I don't have to run my own Mastodon server, and b) I don't end up with the problems that a single-user server has (e.g. local and federated timelines being useless, see #1127).

Of course, there are potential issues here, such as how do other people know that [email protected] and [email protected] are the same account. So #1202 might be the more straightforward way of handling this. But I really would prefer not to have to run my own Mastodon server just to have my email address be my username.

Most helpful comment

After thinking about it some more, I think I'd prefer an approach where my single-user server can effectively "subscribe" to another server to see that server's local and federated timelines (and, ideally, participate in that server's local timeline), so my data is still under my control but I get the experience of belonging to another server.

All 8 comments

I don't like this idea. I think people should have the right to have a username on their own server that is like yours. There's lot's of steve's in the interwebz butha. So, I think we need to see about getting real authentication. I mean like a verifying system. I spoke on this before. Have a well thought out robust system of verification like some dating apps have to increase trust level. But you have to be careful about the methods this could be exploited. If you'd like to talk more about this idea I have so much more to speak of that you'd likely enjoy hearing :)

@siganon I don't understand your objection. It's a given that I'd only be able to "delegate" my username to another instance if I control that username on the other instance. So I'd only be able to "delegate" [email protected] to [email protected] if I control [email protected] already.

After thinking about it some more, I think I'd prefer an approach where my single-user server can effectively "subscribe" to another server to see that server's local and federated timelines (and, ideally, participate in that server's local timeline), so my data is still under my control but I get the experience of belonging to another server.

@kballard please voice your opinion on #1589 :)

Nice, someone thumbed me down for sharing an opinion... nice. Anyways @kballard perhaps I misunderstood you. I thought that people wanted to have the ability to control their credentials across other servers that they aren't actually connecting to. The reason for this is to avoid catfishing etc.. That's why I suggested real verification. It's voluntary and I can't think of a better way tbh. I wanted to talk about this with anyone who was interested in it but I don't want to get another thumb up the butt from someone who takes things WAY too serious.

If you want to control your credentials across other instances, make an account on those instances with the credentials in question.

see #2668 and #897

This is superseded by a more technical #2668, let's move this discussion there.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

svetlik picture svetlik  路  3Comments

lauramichet picture lauramichet  路  3Comments

sorin-davidoi picture sorin-davidoi  路  3Comments

marrus-sh picture marrus-sh  路  3Comments

hidrarga picture hidrarga  路  3Comments