Hello,
We are working on, “a federated linkedin”. At least, that is how I describe it to those familiar with AP and “federation” etc. It can also be described as “an addressbook on steroids” or “a crm with social features”. Our pitch to users is far from complete.
I’m looking for some early stage feedback, thoughts and ideas. Please don’t hesitate to tell me our idea is dumb either: all feedback is valuable. This is also my introduction, so: Hello!
We don’t have any code other than lots of ugly Proof of Concepts (most using Rails or Rust). We don’t have a name yet.
I’m not entirely sure if this is the correct forum, so please point me in the right direction or tell me off if this is off-topic.
Contrary to the current LinkedIn, Mastodon, PixelFed, PeerTube and so on, our envisioned network is all about your profile. Not the content, images, videos or updates you share, but the (changes to) your profile, are central.
This brings some interesting challenges to the table. Especially with how to play well with other players on the fediverse. First, because we will be sending out a different type of “updates”: things like @jane@example.com, type: ProfileUpdate, "changed email from jdoe@example.com into jane@example.org". Or @jane@example.com, type: Position, title: "Database Engineer at BigTableCo" etc. And second because we have some details that differ with how AP and/or the current implementations handle it.
More specific: we have three types of “things” that we want to federate:
- changes to profile pieces (add, update, delete)
- annotations to profiles
- relationships between profiles
And we have a different take on privacy levels and a different way of handling “followers”.
changes to your profile
Any time you change something (important) that change is distributed as an update. This allows
- other parties to change your profile/data in their local copy (e.g. it allows your addressbook to update the persons’ phone number)
- the fediverse to display interesting updates about people being followed. (e.g. it allows mastodon to show that Jane has a new Job at FooBarCo to the followers of Jane).
I’m very curious to how you think this would work, if at all. Especially the second case.
Annotations
Each user can make annotations and add tags to any other profile. This is our basic CRM functionality.
The annotations and tags can be federated as entity too. @jane@example.com: type: Note, for: @bob@example.org, content: "Bob turned out to be the perfect designer for our ProjectFoo".
In itself, standalone, this could be interesting to the fediverse. A tool where you can annotate, tag or otherwise organize the people you follow. Not?
Relationships
Another interesting challenge and difference to most AP models, is the “follow” or “relationship”.
We envision relations as something rich and annotated. So not a simple user<-user follow model, but a full entity: “Anne is [a teacher] of Bob [from 1-09-2019 to 01-02-2020]”, “Bob is [married to] Jane [from 01-01-2000 to present]” or “Bob [spoke to] Anne [at FooConf2012]”.
The way we currently see this fitting in AP is to make this also into a simple “follow” relation. And to distribute (Create, Update, Delete of) such a relation to the network as entity.
This allows all instances to maintain a network graph and it gives users full control over that network graph. The added metadata allows people to search in more meaningful relations. Most current networks simply have a “x follows y” or, in case of linkedin “Y is relation of Z” which has no weight at all: a colleague that you worked with for 20+ years bears the same weight as a relation that added yo because he picked up your businesscard on a conference. Which current networks like Linkedin then solve with “algorithms” or by asking (stealing) more data like gps-location data, from you.
Privacy model
Another interesting challenge is the privacy model.
Both our envisioned business model (something for another time, another post) and the nature of the federated data needs to be well defined and easy to understand by users.
We currently envision a model where each “item” can be set to “public, private, local”. Where, contrary to the often used model in mastodon et al, there is no model to limit to your social graph (your followers only), but rather the instance your are on. An “item” is basically anything mentioned above from “a specific contact detail”, to “an annotation” to “relation”. You may want to share your phone number with your inner circle but not the world. You may leave an annotation that is fully private to you, or maybe you want to share it with the world. etc.
An important detail (often asked) is that, no, relationships are not reciprocal. Meaning that if @jane@example.com adds a relation “colleague of bob”, bob has, nor shows a relation “bob is colleague of jane”. Making it reciprocal would be unpredictable (other people can change the way you present yourself) would allow spamming and -most important- would be a feature that can be abused to bully. Only the user itself can change anything that makes up her profile.
We are in the early stages, so our exact focus (i.e. the most important features) are not solid yet. But we do know three things: We want it to be privacy-friendly, data-owned-by-users and self-hostable (therefore federated). A place where professionals can do “professional networking” without the recruiter-spam, privacy-issues and “being the product” that current professional networking has.