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)

▲

knotbin 5 hours ago | parent | next [-]

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 5 hours ago | parent | next [-]

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

▲

class4behavior 4 hours ago | parent | prev [-]

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 2 hours ago | parent [-]

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.

	▲	tardedmeme 26 minutes ago \| parent [-]
		How does a new server discover other servers?

▲

tbryant 5 hours ago | parent | prev | next [-]

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

▲

kakwa_ 4 hours ago | parent | prev | next [-]

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.

▲

AlecSchueler 4 hours ago | parent | prev | next [-]

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.

▲

tardedmeme 26 minutes ago | parent | prev | next [-]

For Mastodon, follow some tags through fedibuzz relay to populate your feed.

▲

vablings 5 hours ago | parent | prev | next [-]

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

▲

delf 3 hours ago | parent | prev | next [-]

Not if you do it over git itself on the existing forge. You basically store everything in git and federate via git forks/mirrors.

▲

jauntywundrkind 4 hours ago | parent | prev [-]

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.