It is very convenient to be able to find immediately the accounts of your friends in a social network when you register.
The secure way to do this is generally to store an hash of the email addresses of the user’s contacts.
Couldn’t we imagine (or maybe it already exist ?) a protocol like WebFinger which takes an email hash and return the corresponding account in the instance (if it exists) ? This way, friends discovery could work even accross decentralized networks !
I was going to explore doing this, except as a DHT that works across all participating instances.
It’s certainly a problem that users can’t discover known persons through the fedi. It’s important because they miss connections, are I think more likely to feel alone and forget to use this stuff thereby having a good reason to go back to big tech. I think they may also lose the opportunity to discover shared interests.
Hashing emails is secure to a point but not terribly hard to enumerate the major domains. That’s perhaps an interesting sub-problem to solve.
Edit: Started an issue to define and value: Problem: It’s hard to find friends, colleagues, people you know on the Fediverse
Indeed hasing email is not 100% secure.
Maybe security could be improved by only allowing “friend instances” to request this service ?
@grishka Please keep us updated about your explorations. I’m probably going to need this kind of service in the coming months, and I would prefer to use a standard solution rather than a hack.
We explored this idea at length back in 2011 and there really wasn’t any way (at all) to secure it, and it opened up a number of new and unique exploits. Anybody can hash an email address or a public list of email addresses and cracked password archives are only exponentially growing in size. I’m sure one or more fediverse projects will want to try it, and unfortunately I’ve lost all copies of that conversation to dissuade them; but I for one won’t be touching it.
The only way we found that offered any chance of success is a callback arrangement - so that the search returns failure, but records the identity of the requestor. So if you look at a list of those who have tried to find you recently and recognise any of them, you might or might not be willing to initiate contact from your side. Since anybody can scrape Facebook pages and create gmail accounts and fediverse acccounts based on them, I wouldn’t personally touch this one either.
Thinking about this more, the security part isn’t just verifying that an email is on the fediverse. I don’t think any of us expects our email addresses to stay private for long. As developers emails get into git commits and emails if not passwords are proceeds of virtually all hacks. So I just want to clarify that it’s not the knowing that an email exists that’s a problem, but being able to discover which servers have an account with that email.
I like @macgirvin’s thought about an offsite data object that contains requestors of interest. It reminds me of the couple who communicates through the optional placement of a flower pot in a window.
it’s not the knowing that an email exists that’s a problem, but being able to discover which servers have an account with that email.
While I agree with this statement, my site and project members have entrusted their personal information to the service we provide. We need to respect that trust and defend it to the best of our abilities. If I sign up with a service where the project developers or site admin dismiss my privacy concerns because “it’s inevitable” - I’m outa’ there.
It reminds me of the couple who communicates through the optional placement of a flower pot in a window.
It’s actually modeled on common social behaviour. If somebody I’ve never met comes to my door and demands to know where my daughter is, I’ll take their name and number and tell them to go away. I don’t presume this is a friend and I’m certainly not going to let them know how to contact her. I’ll tell my daughter and she can get hold of them if she wants.
I was thinking of that — the idea is that, first and foremost, I want to associate fediverse accounts with centralized social media accounts. You’d import your friend list from VK/Twitter/whatever (not Facebook, they don’t give you real friend lists and user IDs any more through the public API). It would then look up your friends and add DHT entries for each of them. To make it more secure, I suggest that each key would be a hash of something that would contain the IDs of both users. To prevent impersonation, you could ask them to put a unique string derived from their fediverse profile (public key hash for example) somewhere on their centralized profile, that you would retrieve and compare against what came from the DHT.
Wait, I’m being dumb. Why do we need the DHT if we could just ask people to put links to their fediverse profiles on their centralized profiles and vice versa? When you have links going both ways, it’s reasonably verified.
Though you still can’t get friend lists out of Facebook even by scraping the website, I just tested. Though I did find an account that’s a fake me? Should probably report it.
Another idea that is potentially viable is to use actor tag fields to identify your other social network identities. Some projects already do this. If your profile is discoverable, and these tags are standardised, other sites could then index this info as most of them cache actors they’ve seen. This at least puts privacy/discoverability under your control. The only real concern I have about this is the proliferation of tags because there are only a few million “social media” sites these days. And I might want to indicate my former Facebook identity, but since I haven’t had one for around a decade it would be nice to have a way to indicate this is “formerlyKnownAs”. That would make the information spoofable, but as long as people understand this is “buyer beware” it’s certainly achievable, and not nearly as distasteful as providing novel ways to leak email addresses.
Then I noticed while typing this that you replied with essentially the same idea. 
This is only indirectly related, but in this issue I suggested to Keyoxide to consider if there are any viable use cases for federation.