The problem I feel with federated solutions is basically the 'cold start' problem.
When you are wanting to join a federated network, you have two choices: join a pre-existing server thereby creating the exact same problem you are escaping, ie: a giant server that holds you to its whims, BUT you do get a big network to begin with.
Or you start your own server but your network is zero, discoverability is zero, your feed is empty, and you have to convince other sites to federate with you / not block you for the crime of being a 1 person server / etc.
Am I alone in this feeling or am I just doing federation wrong? (But also this may just be a problem / quirk of Mastodon)
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.
Ah ok! Thanks for digging up info that I didn't go looking for myself. That's fantastic news.
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.
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.
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?
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.)
So the app is equivalent to an AP instance.
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.
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.
How does a new server discover other servers?
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.
This is more a mastodon thing. atproto doesn't really work the same way where every server is it's own semi-isolating zone. This gets into it well: https://atproto.com/articles/atproto-for-distsys-engineers
I think the gain sits in the middle: if the giant server starts to get iffy (moderation, content, policy, technical issues), people can leave it somewhat easily and form or grow another decently sized server which will have enough reputation from day one.
We already have other decently sized GH alternatives such as Gitlab, Codeberg and various OSS forge instances (freedesktop, Fedora, Debian, etc) which could be federated and become a safe harbor if we were able to maintained project visibility and discoverability.
That's been entirely my own experience, or at least the assumption that's kept me off all of them so far.
But I saw this project a few days ago and thought to myself "Hey, this one could actually work." The difference here is that the target audience has a pretty strong overlap with the part of society comfortable with self hosting services.
I don't need my whole network for this one to be useful, only that subset that's actually most likely to show up.
I think the appeal here is you can either self-host or even migrate between larger providers.
The server costs for the frontend should be very low allowing them to operate basically forever and they are fed in by a series of other hosts
For Mastodon, follow some tags through fedibuzz relay to populate your feed.
Not if you do it over git itself on the existing forge. You basically store everything in git and federate via git forks/mirrors.
The CTO @pfrazee had a lovely New Year's Eve post that talks about Atmospheric Computing and specifically raising the cold start problem and addressing how atproto tackles it. https://www.pfrazee.com/blog/atmospheric-computing
Tangled here is a great example. An existing user base of a social network was able to rapidly join and start using a new app, a git forge, to share repos and collaborate. PRs and comments show up like any other record on the network.
As for how the network works: atproto tackles the cold start problem by layering architectural concerns. Each person is their own server ("personal data server" aka PDS). But aggregation layers ("relays") collect all PDS activity they can find and relay it to consumers. Then applications such as Bluesky or Tangled ("appviews") can be built by reading records of interest (of the right "lexicon" type) from the relays. Each person owns their data, relays make all data available, appviews distill out user experiences appropriate to the records they cover.