Finding people with Flockingbird

Many federated social networks have a simple search feature. Kept simple, deliberately, out of privacy and harassment concerns.

Hardly any allow searching through the entire federated network, because this is technically very hard to do.

For Flockingbird, though, searching is crucial. It is one of the four main features. In Flockingbird you keep a list of contacts, like an addressbook: a rolodex on steroids. Contacts are people you follow and who you can tag, add notes, or rich relations to. For example, Bob could add Anne as contact after presenting together on a conference. And Anne has Carol and all her other colleagues at Acme Inc. in her contacts.

Now, if Bob wants to reach the Hiring Manager at Acme Inc, he can search for the phrase Acme Inc., and Anne would pop up: Bob can search within his contacts easily.

Bob can also search the local community, so that he finds that his co-worker in his local community, Daniel, who is fan of Acme Inc., shows up.

But the most important feature, is that Bob can search through his network. He can search the contacts of his contacts. So when Bob searches for the phrase Acme Inc., the colleagues of Anne will show up, because Bob has Anne as contact, and Anne has her colleagues at Acme as her contacts.

Searching will be limited to two degrees: so through contacts of your contacts. But it stops there: you cannot search through the contacts of the contacts of your contacts. The reasons are somewhat technical but mostly humane: It is very human to ask your friend, aunt or colleague for a reference, but not very common to trust a reference of a reference. You know how far you can trust that friend, aunt or colleague, but not how far to trust the people that they then know.

Searching is possible by any data that you have set to be public. So when your job-title is "CEO of Acme." and set public, and you have a publicly listed competence "Business Intelligence", and a privately listed competence of "Excel", people can find you when they search for "CEO", "Acme" , "Business Intelligence" or a combination thereof. But not when they seearch for "Excel". The one doing the searching, must also have at least one person in her contacts that have you as a contact. When you don't want to be searchable, you can tune your public data easily.

For Flockingbird, we want to encourage meaningful contact lists: we want to discourage vanity metrics, where people go around, collecting large follower-counts, just to get that ZAP-AAHH shot. Yet the search is somewhat perpendicular to that. A person with thousands of contacts has a much higher chance of finding a, say Carpenter in their contacts or contacts of contacts, then one who has a few very close relatives and friends as contact. We solve this by limiting the searchable contacts to a number (maybe 80, 100, maybe more, maybe less, possibly configurable by the instance-admin). This is also a technical solution: to avoid indexing millions of contacts when one person has 1 000 contacts whom themselves each have 1 000's of contacts again: 1000*1000 = 1 000 000: a million contacts to index, keep updated, and search is really heavy for an instance. That limit, say 80, keeps the 80 most recently updated contacts in the index, and drops all others.

Technically, we are looking into Elasticsearch or a easier and lighter to host alternative to manage the index.

Both are really good at indexing and even better at giving lightning fast, relevant results. So that you can easily find that person to help you into your next dream job, or to find a reference for someone who can write better blogposts for you.