[knotbin]

Yeah that's why Tangled didn't go with ActivityPub (Mastodon protocol) and went with ATproto instead, which is specifically built to solve that problem, so individual servers are all aggregated by centralized AppViews (that anyone can host) that give a singular unified "view" of the network that is just as cohesive as a centralized network feels.

[madamelic]

Ah ok! Thanks for digging up info that I didn't go looking for myself. That's fantastic news.

[class4behavior]

ATProto simply ignores the need for decentralizing incentives on a human/community level. What we get is a sort of a "top-down" federation rather than a grass-roots one. Whoever invests in the infra ends up running a domain.

I mean, practically no one is aware of any other ATPROTO provider other than Bluesky whereas the issue with AP is merely the lack of better implementations, so mastodon.social got the most attention and the hype died off with niche success.

[danabramov]

There’s no such thing as “running a domain” or “atproto provider” in atproto. You’re approaching it with a Mastodon/AP mindset and it doesn’t match that.

In atproto, there’s two axes.

One is hosting. Bluesky offers hosting but some people host on their own (it’s just a Docker container with sqlite), some on Cloudflare, some on community-hosted nodes like https://npmx.dev and https://selfhosted.social. From app perspective it looks exactly the same way (unlike in Mastodon where “hosting” = “choosing a community”) and you can switch hosting anytime.

Another axis is apps. Apps aggregate from data from all hosts. Bluesky is an app, Tangled is an app, Leaflet is an app, Wisp is an app, Semble is an app, and so on. Those can all aggregate over the same data (which enables cross-app interop) but they don’t have to (eg Bluesky doesn’t overlap with Tangled much except that Tangled can reuse Bluesky avatar on login). Generally you don’t have people running copies of the same app (as in Mastodon) which is why there aren’t many “blueskyes”. But when someone has an incentive, they can. (Eg Blacksky is a complete fork including server and DB, allowing their own moderation decisions over same data.) Similarly you can build your own app on top of distributed Tangled data.

Hope that helps clarify why “atproto provider” as a concept doesn’t make sense. You have hosting, which is as distributed as you want, and you have apps, which anyone can make.

[vladms]

So does Bluesky app have control over what data it aggregates and can decide (without checking with a user) not to aggregate data from a host? I am trying to understand what are the implications for a user, and a bad scenario where one would disagree with an action of the app.

And if the answer is "yes" then at least when someone "makes their own app" can they easily use "Bluesky hosts list" + add special extra hosts (or remove specific hosts) so that the app relies on the platform, with the exception the disagreement point?

[danabramov]

Yes to both.

An app can choose to ignore/ban some users (or even entire hosting servers if they’re specifically created for network abuse). This is similar to how any web app may choose to ignore POST requests from spammers.

And yes, someone can decide to aggregate data themselves and provide an alternative app over same data with different moderation policies. In fact that’s already the case (Blacksky runs their own application server that mostly piggybacks on Bluesky moderation decisions but overrides some of them. There are also clients that ignore moderation altogether and show you the raw data from hosting.)

[tardedmeme]

So the app is equivalent to an AP instance.

[danabramov]

No because apps are decoupled many-to-many with hosting.

Every app can display public data from every other app because the source of truth is outside both apps (in hosting).

App owner can’t do bad things to your account other than banning you in their particular app. Other apps (even for same data) independently choose whether to show your data. So app owners are only in control over how your data is presented in their apps, not over your actual data.

Whereas in AP, each app’s moderators literally control your entire identity.

[Crestwave]

Not really. From my understanding, in AP, your account belongs to an instance and your data is then synced to other servers. If the instance goes down, your account is gone.

In ATP, your data is stored in the "Atmosphere", hosted on decentralized "Personal Data Servers" (PDS). The app then simply parses and filters that data. They can apply moderation actions by choosing not to display or read certain posts, but your data still exists and another app could choose to display it. Similarly, if the app goes down, your data is still perfectly intact in the Atmosphere.

It might then seem like the PDS is equivalent to an AP instance, but as mentioned, they are decentralized. Identity is verified through signatures, so if your PDS goes down, you can migrate to a new one as long as you have your signing keys. Therefore, the account belongs to you and not any specific server.

[class4behavior]

You're interpreting my post with the assumption that I don't know what I'm talking about. You don't need to explain the protocol to me.

Domain here referred to the area of influence or control, like what the provider of a relay effectively has. The fact that other groups can run any element of the infra themselves doesn't change the fact that the drift towards centralization is much greater with ATP than with AP.

ATP has its own uses (quick aggregation) but it doesn't even attempt to solve fundamental issues of current ecosystem of social networking,. AP, on the other hand, offers the foundation for further development in the right direction.

[tardedmeme]

How does a new server discover other servers?

[danabramov]

A new hosting provider can preemptively request known relays to crawl it. Or relays (or apps) can lazily discover it when the user hosted there tries to log in for the first time, or their data is linked to by a known user. It’s similar to the relationships between websites and search engines.

Hosting providers don’t need to discover other hosting providers. Data only flows between hosting and apps; not between hosting and hosting or apps and apps.