My LinkedIn timeline is slowly but surely deteriorating, esp the Dutch part. It's about where my Facebook timeline was 3 years ago. Apparantly ones professional reputation is less of a filter for people than I thought it was. Struck the LinkedIn timeline from my information intake.

@ton @VictorVenema We're moving forward, but not enough to "move to flockingbird", no. There's working software, but far from alpha even. Let alone that it's running somewhere in production.

@ton Reading your blogpost, I'm wondering if you are in need of a place where there's a timeline and comments but without the "q-anon".

Or whether you are in need of a place that has no timeline and/or comments at all.

@flockingbird Good question, I don't know the answer. The timeline at L is ineffective in the same way FB's is: it does not show me what my contacts are posting, it's algorithmically manipulating what I see. (evidenced by e.g. getting served week old posts as if new, and posting something to a network of several thousand people being 'seen' a few dozen times at most, whereas plenty content _not_ from my direct network is being shown.) Yet, I also see some use for the timeline, .. 1/2

@flockingbird e.g when contacts are posting about job and funding opportunities. I suppose it's not about the timeline per se at all. It's about LinkedIn throwing out all friction for interaction, including healthy friction (i.e. increased friction with increased social distance), and power assymmetries favoring the algo and the controversial.

@flockingbird I'm now leaning to separating out 3 parts: me keeping track of subjective notes about connections myself, having a general way of quickly getting an impression about someones background (LinkedIn's profile pages or other online CVs), and having a mechanism for introductions via existing connections (e-mail likely can suffice, but is higher friction than maybe needed) Also see

@ton Very interesting ideas there.

The subject is so broad, the implications of all choices so big, that we are working and thinking hard to get beyond an initial MVP.

We want to avoid shipping features that paint us into a corner we can never get out of (a timeline, for example) but also want to offer users enough to be able to actually use the network (maybe people won't use it if we don't have a timeline).

Feedback as you posted and your blogposts really help with perspective, though.

@flockingbird I'm currently in a beta app called 'Cooper' which is based on introductions. But that then leaves you with no place to start from. And the number of times you actually need an introduction, and the times you are open to receiving one are limited in my opinion. Even legitimate requests in my mail are experienced as spammy if they come at the wrong moment e.g., or seem based on misinterpreting my/the recipients role/position.

@flockingbird no prob, these are indeed tough questions to crack. I think a federated approach can be meaningful. It might bring it down to solving the questions for specific professional circles/communities, not for 'everyone'. Like an online equivalent of local business round tables / sectoral / role based 'clubs', professional peer networks etc, which can be bridged because it's federated. Then you have a meaningful difference between personal, local and overall timeline

@flockingbird that would mean you'd not have just Flockingbird, but a manifold of flockingbird instances.

@ton yes! This is exactly what we want and envision.

Though, for that to become the norm, or even usable in the fediverse, we'd need a "federated SSO" of some sort.

It would be very impractical if you have 5 different circles that you operate in professional, and for that have 5 different registrations, 5 logins, 5 accounts-in-apps, 5 tabs open, and so on.

But the benefits do outweigh that downside, IMO.

@flockingbird @ton OpenID should, if I understand things correctly, take care of the federated SSO bits, yes?

That'd leave the multiple FlockingBirds (FlockingFlocks, if you will) for the content.

@doenietzomoeilijk @flockingbird @ton OpenID Connect still has autodiscovery, but you'd still need to enter your ID. We would need a trusted single point of contact or a browser plugin to circumvent that, I think.

@madnificent @doenietzomoeilijk @ton I would imagine that this single point of contact would be decentralized. Part of your browser, indeed, or a selfhostable app.

This does not exist, yet, for the fediverse. And I'm not sure if in practice it is better than a generic password manager.

I read some ideas on this at the hosted forum. But cannot find the links (on mobile). So people are working on it. But it may never get solved properly.

@flockingbird @madnificent @ton

> And I'm not sure if in practice it is better than a generic password manager.

I'd argue it isn't, at that point it's just a proxy for the password manager.

Here's my take on it: if I choose to have several personas on Flockingbird instances, it's mostly out of separation of concern. I might have an account on a PHP-centered one, an account that's Dutch folks, one that caters to old curmudgeons complaining about the internet going to hell, and so on. 1/2

@flockingbird @madnificent @ton

One of these, or maybe my account on Masto here, is my "main" persona. If the various instances can use each other for authentication, I only need to keep track of *one* set of login credentials, and have the other instances piggyback off of that - I'm not sure what methods to that end exist right now, but I believe oauth is pretty common. I might be wrong here, though, so don't take my word for it.

Wouldn't that solve it, without needing more moving bits? 2/2

@doenietzomoeilijk @flockingbird @ton That would work, and your Masto provider could be an OpenID provider at that point.

The site you're using must know your OpenID ID/URI for auto-discovery to work.

- auto fill ID based on a browser plugin (which can know your persona)
- user enters their ID manually
- trusted redirect service (boo!)

The rest, except for a single "yup, this is fine" click for the first login), can be done through OpenID Connect.

@doenietzomoeilijk @flockingbird @ton Just from my experience, not from extensive studies, OpenID Connect is very very common at this point. I don't know of applications doing OpenID Connect Discovery [1].

OpenID Connect Discovery allows you to supply a URL as your own identifier, and the consuming application will automatically discover the provider. Whether that provider is trustworthy is a separate issue but pain-relief exists.


@doenietzomoeilijk @madnificent I'm having a hard time seeing the practical benefits of this, though.

1. It won't sync your account details over, b/c you might want to keep those separated. A feature, not a limitation.
2. It doesn't help in discovering other instances.
3. It does not help in keeping up-to-date with all instances b/c it doesn;t do inboxes/notifications pushing to a single inbox (or if so, to which one?)


@doenietzomoeilijk @madnificent

What remains, are:

1. a single username/password that allows login on all your instances. I.e. what a password manager does for you too.
2. replacing the hurdle to register-then-validate-your-email flow with a less familiar, (but theoretically easier) flow to authenticate with your ID provider.

Are those all the benefits and is that worth all the effort?

@flockingbird @madnificent To some, it might be, to others it might not matter.

You're correct (or at least we agree) that all it'd do is take away signup/signin friction, and I agree that this could also be shifted to password managers.

For the folks who somehow haven't caught on to PMs, though, it's a decent amount of friction to take away, so maybe the question is not just "is it worth it", but "do we expect to deal with a lot of people for who this would be worth it".

@flockingbird @madnificent Then there's also the role of the parties hosting instances - every login shifted to a different instance is a set of credentials you can now no longer leak in case of Bad Stuff happening. Personally, that'd be of interest to me if I were to host something like this.

@doenietzomoeilijk @flockingbird Not sure if I understand correctly. Are we both advocating for a single authentication provider for multiple instances?

@ton @flockingbird This is an excellent idea. A person’s timeline is essentially either 1. their group associations, 2. who they are following 3. or a mix of #1 & #2. Nothing more. That in itself is useful (and achievable).

@ton @flockingbird The fundamental issue here is just what you said - that LI (and most social networks) intentionally show you the most controversial content to amplify engagement on their platforms, not to serve you the most relevant content based on your interests and peer group.

Many people leaving legacy social networks are migrating to alternative platforms for that very reason. Simply because they can actually see the people they follow and content / topics they care about.

Another way to achieve this may be to follow a list of topics based on related hashtags across Flockingbird instances. The only filter might be newest / most engagement from people you follow.

Filtering out unwanted engagement is already baked in at the account and instance admin level, so no need to reinvent the wheel there.

I also see the value in private / invite only groups - as this could facilitate project based collaboration and a form of federated work groups.

Using OAuth & OpenID to facilitate group permissions would require every instance to essentially be both an OAuth & Identity server (perhaps something like Ory HYDRA - & Kratos -, which would significantly add to the complexity of running an instance.

There is an Ory Ruby client available - - but I have not tested it. Perhaps this could be considered as a feature in the roadmap after the MVP is stable and @flockingbird out of the alpha phase.

Sign in to participate in the conversation

Ton's personal Mastodon instance