… is “both” an option?
Soooo… here’s the thing. Unsurprisingly, I have though about this idea before, and stopped after some time. There are some fairly obvious issues, as well as some really tricky potential blockers.
The obvious point, that service being a central service that knows a lot of personal information, can easily put aside by claiming the service is optional, the users can be informed about the data implications, and even if the service would fail, it would not have an impact on the federating systems. So let’s put that aside.
Another note ahead…
… which is nothing bad. 
Just like software telemetry, there are valid use cases, and ways to implement it in a privacy-friendly, user-respecting way! So let’s not rule out ideas just because they use ideas that can be used to do evil stuff.
I kind of agree that it would be nice to have a… phone book for federation users, let’s call it FederatedBook just for fun. As it would be optional, just like a real phone book, people would have to sign up for that service and provide the data they want to have listed. This could be an email address, a phone number, a profile description, and they might be able to link profiles from other social networks to enable FederatedBook to automagically match people you may know.
As for privacy concerns, FederatedBook would have to make sure it provides clear information what data is stored, and under what circumstances other people might see the data or the resulting matches out of it. Easy stuff.
And then there are the tricky questions. How would suggesting people actually work? Suggesting profiles that already follow each other is easy, but does not lead to really interesting suggestions. Most of the interesting results come from suggestions for people you actually do not have a connection with (yet). Large networks do this by finding intersections with other friends “you follow Bob, so does Alice, you might want to say hi to Alice!”, but this stuff is really, really hard to implement.
Next, and even harder: how do you design the actual sign up process? I mean, ultimately, all the information stored at FederatedBook is linked to a diaspora/friendica/whatevs-ID. How do you authenticate that an entry is actually legit?
diaspora, in theory, can be an OID identity provider, but that would require FederatedBook to implement the full dynamic client registration process to enable talking to all pods. Is Friendica supporting providing identities via OID? Does Socialhome? Implementing this is hard, and some compatible implementations may actually decide not to implement it, since it’s too much effort for them.
Alternatively, you could write something like a diaspora bot, that sends verification messages or exchanges tokens. But again, this would require a lot of implementation on FederatedBooks site, including receiving all kinds of federation events just to check if people share with the account, send and receive messages, … lot’s of overhead.
Since my idea already died at the point of thinking about authentication, I did not think about the technical details of implementing data collection, which for sure has some gotchas as well.
Ultimately, this would be a huge effort to solve a problem that might not be that large at all, I am not sure how many people actually would use it, and in the end, I don’t think the effort would be justified. However, as I said, I never finished that train of thought, I just wanted to share why I did not ride it.