Global, DHT-based account directory for importing friend lists from other services

[grishka]

Pitch

I suggest adding a global account directory that connects accounts on centralized services, for example Twitter, to Mastodon accounts. Kind of like bridge.joinmastodon.org, but better.

Technical details

• Use DHT/IPFS-like architecture made out of instance servers.
• Somehow encapsulate that as an ActivityPub extension so as to reuse the existing federated network.
• Hash external account IDs with a computationally-heavy hash function such as PBKDF2 and use those hashes for keys. Store Mastodon account handles as values.
• Have each instance use its own OAuth app IDs to avoid this issue.

Privacy considerations

This feature won't impact user privacy in any way because it's opt-in. Also, hashing the external account IDs enforces that you have to know the external account to get the Mastodon account handle, making a reverse lookup (Mastodon -> Twitter) impossible without spending lots and lots of time brute-forcing hashes.

How it would work for the end user

1. Say, you want to connect your Twitter account. You do so through the usual OAuth flow.
2. Your instance gets your Twitter username/ID. It uses a hard to brute-force hash function, for example PBKDF2, to make a hashed representation of it.
3. Your instance stores your Mastodon account name using the hashed Twitter ID as the key.
4. Either the client or the instance server gets the list of accounts you follow from Twitter, hashes each of the account IDs as described above and performs a DHT lookup for each of them.
5. You are presented with a nice list of Mastodon accounts of people you know.

Motivation

All currently popular centralized social media platforms have some sort of global account search:

• VKontakte encouraged you to fill things like your school and university into your profile so people could then search by them. Facebook probably did that too, I never used it much.
• All social media platforms have global search where you could find people at least by their names.
• All social media platforms have a way to import your friend list from other social media platforms.
• Some social media platforms allow you to associate your phone number with your profile and use the contact list from your phone to find people.

Without this, you just sign up and kind of have no idea where to go next. You don't know whether any people you know are on Mastodon and which instances they're on. In other words, there's no efficient, easy way to move your existing social graph into the Mastodon network.

Why DHT?

Because it's the only way I know of of organizing reliable decentralized storage without any additional expenses.

• Blockchains won't work because they're append-only kind of storage, with no easy way to lookup something by a known key.
• Centralized account directory server is against the spirit of this project. It's a single point of failure, and it makes a single entity responsible for the data they store, thus enabling censorship and all other kinds of nasty things that decentralization aims to make technically impossible.

Why on instances?

Projects like IPFS, used naively by making each client an IPFS node, won't work well because users aren't keeping their devices on and online 24/7. P2P networking also doesn't work well over mobile networks, and would consume metered data which is expensive in some regions. And users won't be paying for a pinning service just to have their account associations stored.

The UX has to be as simple as possible, without users needing to dive into the details of how exactly it is implemented. Shifting all the P2P networking to instances makes it client-agnostic and easier for the end user to use.

Besides that, your instance already stores your account in its entirety, so it comes natural for it to store the external associations too.