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:

fediverse.blog/~/Flockingbird/

@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?

Follow

@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 Those are some really good questions. Let me answer them one-reply a time:

The search-problem is hard. But proof of concept shows that pushing updates from contacts (following) into an index is easy. Pushing the updates from their followings is possible. We'll need to just try, and see if this causes flooding, overflowing or if it works. We expect it to work.

@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: lemmy.ml/docs/about_features.h
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 @madnificent pls. also check out the model of @mobilizon they allow users of an instance to be part of different entities (i.e. groups or organizations) which are not connected on the front end.

This would allow me to track a special interest group of a new career goal (e.g. project managers) while not disclosing it to me current connections.

See the #otwsu
invidious.snopyta.org/watch?v=

@flockingbird I've read that now, thank you! I doubt the "bot" approach at lemmy.ml/docs/print.html#feder 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

@flockingbird @madnificent What if an organization (e.g. #fsf) hosts an instance for all its members or employees and the a member moves to another organization?

@nurinoas AP has "moving" in it's protocol. E.g. mastodon has "moving instances" as a feature implemented (albeit still somewhat less userfriendly).

That would suffice, won't it?

@flockingbird @nurinoas Doesn't moving imply that you're still only part of one group? As in: if I'm at a conference I'm not at my company.

Not sure if this is common, but my personal and work life intermingle extensively and it'd be unpractical to have them on separate accounts. I also cater for multiple hobbies and a lot of value comes when there's accidental bridges between them. I'd consider these to be multiple networks.

This is a general #activitypub problem, I suppose?

@madnificent @nurinoas obviuosly you can connect with anyone you know the handle(URL) of. Connecting, following, leaving notes, tagging etc is all federated. You don't need to be on 'the conference instance' to connect to other conference participants.

The conference might have an instance for the volunteers, though. On which you have an account for that group. Maybe even for the duration of that conference only.

Similar to how a conf has a wiki, forum etc.

@madnificent We'll spend another blogpost explaining why "group == instance" though. That is a topic with far too much details to fit in a toot or reply. It's on the to-blog-list.

@flockingbird Makes sense. Especially because it's something we'll have to experience and try.

Really appreciate the work you're putting in this and can hardly wait to try it.

@flockingbird PS. your git is currently unavailable:

"The site at git.webschuur.com/flockingbird has experienced a network protocol violation that cannot be repaired."

(trying with FF/ubuntu from NL)

@madnificent

@humanetech Thanks for the headsup. We really need to migrate this server to caddy. Let'sencrypt and Nginx are an unfortunate combination.

@flockingbird have heard good things about Caddy.

Nginx + LE may work fine, but are a bit of a hassle to maintain and such, especially when having multiple services behind the proxy.

@humanetech in our case it's cause by our Ansible which needs to be generic and support provisioning of new services on -indeed- a shared nginx as well as updates an also -in the case of gitea- somewhat customised nginx configs.

Sign in to participate in the conversation
Fosstodon

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