Early feedback and presentation of "a federated professional business network"


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.

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?

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.


Very cool! FYI there is an article about Leaving LI trending right now on Hacker News: https://news.ycombinator.com/item?id=23486938

PS. I saw CloutStream mentioned, maybe that’s a good name.

1 Like

This is really interesting to me, not specifically as a LinkedIn replacement but rather as something that federates diffs of a profile! I can imagine there are many uses for this kind of model.

1 Like

Really interesting project. I’ve never worked on my linked profile because I dont think a 3rd party should be the custodian of your working profile

Linked data (the LD part of JSON-LD) is perfectly designed to create profile data in an extensible way.

In fact as far back as 2004 the FOAF network was gaining traction, but it never made it to mainstream, tho at one point in time google did say they were going to implement it. That sadly didnt happen.

Creating a profile is not too hard IMHO. You just extend the JSON (LD) to add the fields you want. Annotations should not be too hard either, you just add extra objects linked from that profile. LD is designed specifically to do that. I’ve read some understandable criticism of JSON vs JSON-LD but this is the use case the LD part was designed for, so if AP is embracing LD there might as well be some benefits!

Relationships between profiles. This is what we used to call the “social graph” back in about 2006. Another great idea which unfortunately didnt take off yet. During the social web working group where AP was developed I argued that the social web was about people, friends and relationships. Something that I considered self evident at the time. To my slight surprise I was almost the only member of the group that had this mind set. The over riding wish was to build out the open microblogging specification which was based on tweets and followers. The message was, “not now” for friending and social networks. Let’s get the micro blogging done then look at other things. There was also a degree to which some folks thought that reciprocal following was like friending.

Linked data is designed through the use of "ontologies’ to give all sorts of different relationships. The most common being foaf:knows, but the idea is just come up with a URI and that describes the TYPE of relationship.

Regarding identifiers. The Solid Project (social linked data) was designed along these lines with friends and profiles in a social graph. In that case the user is identified by their profile URL. In mastodon it uses the @ syntax. I’d like to actually maybe code a server that does both and brings the two projects closer together. It’s possible to put your profile data in a script tag in your page, which is the idea I would like to personally explore.

Regarding privacy, in solid we have a notion of access control. It’s quite complex, so maybe the notion of public/private/local would be a simpler way to go.

Great idea, looking forward to what you come up with!

1 Like

Interesting angle!

I did consider sending “diffs” of some type around, but concluded that AP is just not designed for that and that this would always be a hack. There are far better protocols to handle “diffs”, for me, the syncing in CouchDB is most promising and closest.

So emitting “changes to your profile” would first and foremost have a human audience in mind. The information is meant to be represented in a “timeline” or “notifications” or any message for humans. And not as “information for computer programs to update their local copy”.

I do plan to include just enough metadata to allow programs to update local stuff. But in practice that would probably mostly be:

  1. get a notification in the Inbox about a “unit”. A unit could be ‘the profile’ or ‘work experience 1337’ or ‘photo 42’ etc.
  2. parse and filter that to determine “do we need to take action”.
  3. some worker/listener than uses that information to fetch the full unit from upstream and replace the local copy with the upstream one.

An inefficient, but practical “synching” mechanism. But I think a good tradeoff.

If, in practice it turns out this is too heavy for clients (exp mobile) and we actually have clients using it and having that problem, adding an additional couchdb on top may be a good improvement.

Wow, thanks for taking the time to answer me, I’m honored.

IIR Google dit implement FOAF in orkut, but moved it out after moving to circles. I don’t recall it as a main or even advertised feature, just something that, if you were into it, you could use.

JSON-LD was on my radar as a way to display all the info to clients. I’m old-fashioned though, and have a personal preference for XML, which I think is far better suited serialisation for such data, but JSON is what the industry has moved to, so its what we’ll use…

And about the focus on microblogging: this is why we chose AP and not some json-synching mechanism or document distribution protocol (also see my answer to darius). The idea is that changes to your profile, adding/removing/updating relations and other “units” (such as a position at a company, or an education and so on) are interesting for humans first and foremost.
So the microblogging seems like a really good way for this, but where humans don’t type the “microblogs” but, instead, your actions on the platform do. A "type: Position, from: now, title “Senior Bingo Organizer, org: Acme Inc” is turned into “Bob now works at Acme Inc. as Senior Bingo Organizer. [congratulate] [reply] [boost]”.

So, we envision it mostly as a system to tell others about yourself and about the changes in your life/career, than a system to distribute models/representations of your life/career to other software. Which is why the microblogging seems apt.

I’ll have to read up on Solid and the downsides of JSON-LD. And I’ll be investigating ontologies as a way to present relationships in more detail.

Thanks for your thoughts and information!

One fyi: http://rdfs.org/resume-rdf/

1 Like

See Also


Thanks for pointing out schema.org. As a (former) webdeveloper, I have used schema.org and before that microformats a lot.

It is a bit dizzying, though, seeing all the options and opportunities out there. Some build on top of eachother, some can be used simultaneous, and again others are mutual exclusive.

It looks like there are a lot of people solving the same problem over and over (semantic meaning on the internet) without ever becoming a de-facto standard. Well, other than HTML, that is.

Thanks for the hint. RDFs.org is a weird website; it appears they only have “content” for machines/computers and none for humans. A pity, because having some explanation on what it is, when you can use it and what the options are, would be very useful.

But since resume’s are -indeed- an important piece, I’ve jotted down the resume-rdf as something extremely useful for now.

1 Like