Hacker News Reader

Comment by mirimir | Hacker News Reader

Finally, a cogent explanation.

Edit: But missing a key issue, perhaps.

> Because Mastodon uses a collection of Instances, you’re not at the beck and call of one site owner. If you don’t like the direction an Instance is taking, you can pack your virtual bags and go. Mastodon even has an import/export tool that allows you to migrate the people you follow from one account/instance to another.

That sounds great. But if you do "pack your virtual bags and go", is there any way to map foo@bar.net to foo@baz.net? In the email analogy, there's clearly not. You need to tell all correspondents.

View on HN

With e-mail there is a way to migrate without losing your identity, if you own your own domain, and point its MX records at your provider (who is a real e-mail provider and not a "free" walled garden like GMail or AOL). Unfortunately owning a domain is not as accessible for 95% of the population as it ought to be.

This concept of digital identity mobility is important to ensure that one's digital life is not tied to a single service provider. XMPP provides this capability as well, through SRV records. Bizarrely, given its aim to free users from walled gardens, Mastodon does not support SRV records [1]. The developers give some excuses about the WebFinger protocol, which basically means that if I want to own my own Mastodon identity, I must run my own server (either Mastodon or a WebFinger redirect).

Apparently Diaspora made the same shortsighted decision [2]. I'm surprised and saddened that the concept of identity mobility is seemingly not well understood by those developing decentralized social platforms.

[1] https://github.com/tootsuite/mastodon/issues/1931

[2] https://github.com/diaspora/diaspora/issues/1109

Yes, I know that. But email was just the analogy ;) For Mastodon, that would be running your own instance, I guess.

Which is unfortunate. I consider myself a highly skilled technical user, and the burden of running and maintaining my own Mastodon server, or even my own Nginx server to redirect WebFinger requests somewhere else, exceeds the free time I have to devote to the problem. (Keeping another VM alive, updated, and configured through the years costs mental energy, time, and money.)

Whereas, adding an SRV record to my existing DNS server? That's trivial, comes at no marginal cost to me, and doesn't leave me with the constant mental burden of worrying whether my Mastodon or WebFinger server is available, secure, etc.

Owning my own digital identity should be easy. Simplicity encourages adoption, and widespread self-ownership of one's digital identity is key to hindering the growth of walled gardens. Mastodon does not make ownership of one's digital identity simple.

I totally agree. And it seems like Mastodon devs are starting to take the issue seriously. So perhaps there's hope.

To the best of my knowledge they have always taken account migration seriously. But it's a hard problem, and there are many, many issues to be sorted. As a result it has been and is being discussed in detail in the background while other features have been implemented and rolled out.

Some of those other issues were contentious exactly because there was insufficient prior discussion, so the question of account migration is taking its time. As I say, it's hard, so it won't be happening in the immediate future.

But it is happening.

Thanks, that's good to know.

I interpreted some comments on that ticket as dismissing account migration as almost frivolous. But maybe that's because it's an old and difficult challenge, and I didn't have the context to understand the comments.

I don't understand why these federated social networks don't use standard email addresses for identity.

Well first and foremost, people usually don't want their email published everywhere. Especially in this decentralized context, that'd be a gold mine for spammers.

Why couldn't you create an email identity specifically for social networking.

Right. I probably have at least 100 email addresses. Most of them I've abandoned, however.

It's easy from the one direction: There's nothing stopping instance hosts from also hosting email addresses that match user account names. It might even be a good idea for some instances, in keeping a trust relationship, if your Mastodon instance was also your email provider of choice.

From the other direction is tougher, because you have a many-to-many relationship to try to consider. It's a variation of the problems of OG OpenID and/or Mozilla Persona (RIP to both). If I want to use example.account@gmail.com, how do you map that to a "main" instance if you can't ask gmail.com because Google doesn't currently care about WebFinger or ActivityPub? Do you use a central database somewhere? Does that defeat the goals of decentralization you were going for in the first place?

Hm, I had a dream last night and the wild idea that the URI application of DDDS [1] could be used to replace or augment WebFinger for the process of associating Mastodon IDs with URLs. DDDS is already used for telephone number portability for both ENUM and SIP, so it would be an appropriate use case.

Of course, this (and SRV records, for that matter) would preclude pure web clients from being able to look up IDs, but that's not a problem an HTTP DNS proxy couldn't solve.

[1] https://www.ietf.org/rfc/rfc3404.txt

Some interesting discussion here:

https://github.com/tootsuite/mastodon/issues/177

It seems possible!

Yes, it seems that every user already has a private|public key pair. It's just that instances are apparently storing users' private keys. And that, for what it's worth, seems like a horrible idea.

But whatever, if users had control of their private keys, they could easily move. As long as routing depended on public key hash (as with Tor .onion sites) instead of user@instance. More of a web model, instead of an email model ;)

That seems like an overly complex scheme to solve a problem that XMPP solved years ago with SRV records.

I think this is a good use case for keybase.io

It aggregates known (proven) identities, allows all currently verified identities to prove ownership of your next new one.

I thought of that too. But just keybase.io wouldn't be acceptable, because it's centralized. However, I vaguely remember language about Keybase being a protocol, and not just a site. But I've never used anything but keybase.io and indeed haven't heard about federation.

But then there's https://keybase.io/kbpgp/ so ???

The Keybase verifications (sigchain) are also encoded into the Bitcoin blockchain in addition to stored on their servers if you wanted a more distributed way to check them. https://keybase.io/docs/server_security/merkle_root_in_bitco...

Keybase

Reply on news.ycombinator.com