Finding people, companies and references is most crucial for a professional social network.

Here is how we plan to tackle this for Flockingbird: Decentralised and Privacy-friendly:

@flockingbird Doubt this would support the way I used LinkedIn: make connections and look them up when following up. Very common.m

I often land in new groups/contexts with no connections yet and this approach would make finding the first connection very very hard.

Connecting should be super lightweight, discovery easy. A public (slow?) search spanning many many instances might help? Perhaps allow many 'local' contexts (eg: a conference, organisation or topic) rather than one?

@madnificent As for connecting, that is a good subject for another post. I'm sorry if the blogpost implies that searching is the only way to connect.

I'm not sure if I understand your comment about it "making finding thefirst connection [..] hard". Do you mean that without groups, discovery is hard?

Geographic, or local discovery is a neat idea, It's on the list now. We need to think this through very well, though, because it also is a potential privacy nightmare.

@flockingbird It's easy talking from my lazy chair, but the search problem is hard.

The first connection in a new group would be very hard to find. You most often find people by name, not because they shared their URL (especially so when the network is still smaller).

Regarding privacy: it could make sense to *choose* to make some info publicly available perhaps?

Regarding "local": I'd want to be on multiple federated instances in an integrated way. I cater to multiple groups. 🤔

@madnificent Regarding groups: there are no groups planned in Flockingbird.

Your instance is your group.

Finding on-instance people is easy: that is just an index of the instance-users.

The moment that your fellow-instance-user Bob connects to Jane on another instance, all (public) data and updates of Jane's profile are pushed onto your instance. Jane is now indexed on your instance.
If Bob is in your contacts, Jane will now pop up in your searches, without the need to look up remote data.

@flockingbird I understand this. It would be cool if you could be part of multiple instances as a unified entity. People can have many aspects (Green + Foodie + Location + Art) to choose an instance by.

I may be missing some understanding of the Fediverse, so this might be a no-brainer. 😊

@madnificent We'll get back with this in a future blogpost. Promised. Post is in Draft, but, spoiler alert, it is a much more complex topic than one would think. Fediverse and Activitypub don't offer anything for this.

Lemmy has something like this, but it greatly complicates their moderation model:
And it avoids privacy-issues by assuming everything is public always. You cannot have a "this is only visible to members of a community".

@flockingbird I've read that now, thank you! I doubt the "bot" approach at translates automatically to Flockingbird. However, auto-resend to all peers could be replaced by a caching search engine. Also a bot. Such engine, with optional approval, could allow people to share with a group and find others based on that data. This might help build many small search indexes?

@madnificent I looked through the lemmy docs and code for this issue indeed.

From what I can see, the main difference is also the hardest to fix: permissions. With lemmy, AFAICS, a group is "merely" a label that groups stuff, and very little with permissions. E.g. a post in group X is still visible to someone in group Y.

We would need to guarantee strong privacy, that a post in group X can never leave that group, not by accident, nor by wrong federation and so on.

@flockingbird Perhaps strong privacy can be optional? This makes the first case easy.

For some (most) groups, I wouldn't care sharing that I'm part of the group nor what I posted in it. For others (the hard case), a user would have to be allowed into the group, and an access token (or something like it) could be shared to allow for search? I doubt fedi tech has something for this?


@madnificent as noted in the blogpost, AP does not have cross-instance-groups covered. It's possible with shared inboxes and such.

But far easier is to have 1) easy to boot instances and 2) SSO over those instances. That would also solve nearly all "group" issues.

@flockingbird I have to let that sink in.

At first sight, it would not allow a user to share their handle across instances? It would require smarter clients. It would also only allow flat groups. But it would fit in current tech more easily....

Thanks for the ideas and good argumentation. Can't wait for Flockingbird to become something

Sign in to participate in the conversation

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.