The Flockingbird Privacy Model

Balancing "clear" with "powerfull" to give you a powerfull and privacy-friendly professional social networking.

Flockingbird is a professional social network. We are building a place where you manage your business network. Decentralised, and privacy friendly.

Flockingbird is being built to connect to the Fediverse, with instances that share your profile data with other instances. Flockingbird is all about your profile, and updates and data around those profiles; and not about sharing your thoughts, gifs and video's.

This requires a clear yet powerful privacy model. One that empowers you, as user, but one that is also simple enough so it does not "get in way".

Privacy is a security feature. And security degrades if it gets too complex. The big social networks are famous for introducing confusing "privacy settings", which at best were just poorly designed but at worst really serve to trick you into giving away too much private data. This is why we have "clear" as requirement. Accidentally sharing a meme or video with the wrong audience can be devastating, but accidentally sharing your phone number with the wrong audience is always devastating. Profile and contact-details have extra-stringent privacy requirements.

Privacy empowers people. Empowerment through deciding with whom and what data you want to share. This is why we have "powerful" as other requirement.

Figma Wireframes showing screens with dropdowns with the three privacy options.

On Flockingbird, you will be able to, amongst others, maintain a list of "competences" on your profile. For example, I have the competences "Excel" and "Beekeeping", and I want to share those with different audiences: "Excel" might be something that I only want to share with a select group, but "Beekeeping" is something that I want everyone to know. A competence is one of many profile data. And each individual piece of profile data can get one of three levels of privacy.

  • Only You - Fully private, only visible by the author.
  • Your Community - Visible only to a select group.
  • Everyone - Public.

Only You is especially useful for features such as "notes on profiles", where you can maintain notes on another person's profile. There will be several such features where you often don't want to share a piece of information with anyone. There will also be a few features where you cannot ever choose anything else but "only you"; for example when you add a telephone number on someone's profile.

Your Community is the default for most pieces of information. A "community" is an instance. This serves three goals. Most importantly it keeps it clear and simple. But it also motivates instances to have a strong social cohesion. And to stay small. We envision flockingbird instances to be mostly used in "real life" social networks, such as your coworking-space, a student association or for the employees at a company.

Everyone really means public. Also to search-engines and other anonymous passers-by.

The power lies in that you can choose per-data piece who can access it, from one of these three options. This way you can choose to share the competence "Excel" with only your community, an email-address with the world, and hide a note about a colleague for everyone but yourself.

The simplicity comes mostly from avoiding the hard to control "followers". E.g. with Mastodon, when writing an update (a toot), you can choose Followers-only - Visible for followers only. It does open a lot of ambiguity and requires you to maintain who can follow you, carefully. The ambiguity lies in questions such as "if I post a toot "followers only" in 2019, can someone who starts to follow me in 2020, see that toot?". The complexity gets worse because followers add themselves: "Anne follows Bob"; an action by Anne. But this changes with who Bob now shares his data". This can be mitigated by a setting to "manually approve followers" combined with a feature to block people.

We chose to avoid this altogether. Privacy around "followers only" is just too easy for users to get wrong. And when dealing with sensitive data such as your contact details, that is just too risky.

It does put a lot of responsibility on the moderators and owners of an instance, though. Responsibility to moderate who can register on an instance, for example. But we believe that already a moderator and owner has a great responsibility, by running a server that holds your contact details, for example. This privacy model of "sharing with the instance members only", just makes that required trust even more apparent.

What do you think about this model? Do you see use-cases with a professional network that this privacy model does not cover? Is it too limiting or too complex for your liking? Please leave a comment below or share your thoughts on our mastodon account @flockingbird@fosstodon.org