I am thankful that I do not need to say „thankyou“ to #Bluesky, the company and its investors for the verification of accounts or to ask them for changes in their configuration so that my social media platform is working.

It shows how dependent #Eurosky and #ATProto still is on Bluesky. They are at the mercy of them. And I do not trust Eurosky to be ever free and fully independent, even if I really want to believe in it.

Please change my mind, but for now I keep on building on ActivityPub.

@Sascha thank you for sharing this Sascha 🙏

I’m super grateful you’re here, building on ActivityPub

@Sascha @aerique But how is this different from AcrivityPub/Mastodon? If I am on a large instance A and want to reach members of another large instance B I need the cooperation of B too (it needs to federate with me), no?
@xot @aerique Let me try (I might fail):
- Verification is easy in ActivityPub (AP): If I am on A, I can verify without any interaction of instance B. (Of course verification in ATProto (AT) and AP are different verifications anyway, AP verifies links, AT verifies accounts AFAIK).
- Rate limits: Users of A in AP do not care for any rate limits on B when talking to each other or other instances than B. All Eurosky-PDS-users are limited by Blueskys rate limit now in AT.

@Sascha great explanation Sascha… basically ATProto has a central authority (Bluesky PBC) and even most forks rely on it for verification and the relay / firehose.

I said most forks because Rudy Fraser’s Blacksky has done an incredible job setting itself free from Bluesky. Not sure about how Blacksky handles verification though…

@xot @aerique

@Sascha @aerique Thanks. Wasn’t aware that all Eurosky-PDS-users are limited by Blieskys rate limit, even when talking to each other. That’s a fundamental difference indeed.
@Sascha @xot @aerique ActivityPub has no analogous feature to the Verification we are looking at here on Bluesky. If you are talking about Mastodon's implementation of rel="me" link verification this is not an part of ActivityPub this is Mastodon using the a microformat developed by the IndieWeb community and it really does a totally different thing then the Verified badge that Bluesky has. And any server in the fediverse can set up a rate limit, and I am sure many have *some* in place.

@liaizon @xot @aerique I guessed I might fail. 🤷‍♂️

But the question of dependency stays. How does someone get verified on AT? It’s by Bluesky? Or can Eurosky themselfes decide to grant „some colourful image trough a process called verification“? They are dependent on Bluesky, no?

The rate limit of Bluesky, why does it disturb Eurosky in functioning as a whole? It’s because of dependency on Blueskys infrastructure, isn’t it?

@Sascha @xot @aerique on the atmosphere there are already multiple "Trusted Verifiers" Bluesky the company runs one provider, Blacksky runs one, @WIRED runs one. Then each AppView can also choose which verifiers they show or acknowledge. Additionally, clients can choose to allow any user to verify any other user. So I have verified a bunch of people I was following in a client that showed user based verification and others could choose to use a client that shows this too.

> The rate limit of Bluesky, why does it disturb Eurosky in functioning as a whole? It’s because of dependency on Blueskys infrastructure, isn’t it?

Eurosky hasn't launched an AppView (I think they started working on it, haven't looked into it recently), Blacksky has. An AppView is like an fediverse instance that has made a local cache of every post on the fediverse. Bluesky PBC has a ratelimit for large requests, so if you want to pull the full firehose you have to do something extra

@Sascha

@Sascha I think Blacksky now has a pretty full copy, so you could probably hit that instead. You can also get the data directly from the users PDS and avoid the AppView entirely which some apps are now doing, but then you don't get things like global search and have to implement that differently

@Sascha would you also build on ActivityPub by "invading" #Bluesky / #Eurosky via @bsky.brid.gy ?

I find Bridgy pretty handful for showing how cool AP is, directly inside Bluesky/AT - thereby kinda demonstrating protocols and networks are "bothers" rather than ennemies.

@politipet @bsky.brid.gy I think bridges are okayish. They are still single point of failure. They should only work with active opt-in. But they remove a big disadvantage a see in AT: they kill the public blocklists in AT while still providing my content from AP. And lastly: I wonder why there should be two „social protocols“ at the same time. It’s good to have some time to learn from each other. On the longterm it should be one working protocol for all social web things.
@Sascha this dependency seems to undermine the objection that many have to BlueSky as decentralized. Hard to say you’re decentralized when BlueSky is a runtime dependency.