How will this end up going any better than Mastodon has?

Near inevitabilities:

- All the small instances defederating from the largest due to politics/spam/annoying noobs/whatever, effectively killing the easiest path to entry into the community

- Pointless debates about whether it’s OK to federate with instances that host pirated content, disagreeable politics, furry VNs, etc., which everyone has to take a side (the correct side) on

- Relatively little actual work/productive discussion going on, since many users are there mostly for the politics / fediverse posturing than for actual work

▲

danabramov an hour ago | parent | next [-]

Atproto isn’t “many servers sending messages to each other”. It’s structured more like RSS:

1) there’s an app-agnostic hosting layer (and anyone can run a host, a bit like personal site with RSS)

2) then there’s apps, which aggregate over data from all hosts (a bit like Google Reader or Feedly)

So there’s no such thing as “defederating”. You don’t have many copies of Tangled beefing with each other. It’s more like you can run your own hosting for your own data (if you want), and anyone can build an app that aggregates from everyone’s data (Tangled is one such app).

If this got you curious, I have two longreads: https://overreacted.io/open-social/ (conceptual) and https://overreacted.io/a-social-filesystem/ (diving into the data model).

▲

cxr an hour ago | parent | next [-]

> Atproto isn’t “many servers sending messages to each other”. It’s structured more like RSS

Except that, crucially, RSS/Atom plays well with static nodes (e.g. personal websites generated with Jekyll/Hugo/whatever—or even written by hand[1]), and Atproto does not. (Nor does Mastodon; previously: <https://news.ycombinator.com/item?id=30862612>.)

It'd be great if the complexities needed to support the "Atmosphere" were widely recognized/acknowledged to be overkill and soon enough ended up going the way of things like CORBA and WSDL while in its place a resurgence of interest in the Atomsphere emerged.

1. <https://m15o.ichi.city/site/writing-atom-feed-manually.html>

	▲	miki123211 a minute ago \| parent \| next [-]
		Atom is pull, Atproto is push. Atom was designed for news, before social media existed, where 15+ minute polling times were (borderline) acceptable. Atproto was designed for social media, in an age of Twitter users getting their news in seconds, to the point of being able to comment on live events play-by-play. There's no coming back from that world. With that said, I wish both Mastodon and Atproto supported opt-in pull-based, static sources.
	▲	jauntywundrkind 7 minutes ago \| parent \| prev [-]
		There's always some Gemini protocol faction that shows up to yell that everything is wrong and we have to keep hand assembling our packets by hand or it'll never work. Atproto's PDS is the root idea that everything extends off of, is the "social filesystem" that you control. There's a protocol objective to be able to spread your data around widely and for folks to be able to cryptographically check that that data came from you (even if you have to change hosts or even if someone sneakernets your data around). That's going to have some complexity! If you want to make a simpler network where we don't have those guarantees, please go right ahead. It feels to me like a snap reaction though that doesn't bother weighing what we have gotten or why things are this way, that is reflexively demanding.

▲

4lx87 an hour ago | parent | prev | next [-]

The web is already structured like this. You can poll a URL for updates. You can host your own data. Anyone can build an app that aggregates from everyone's data.

	▲	embedding-shape 25 minutes ago \| parent [-]
		Yes, all of those things are possible. Now imagine a protocol built from the ground up for those purposes, not just possible, but the entire community and ecosystem embracing those things.

▲

rafram an hour ago | parent | prev [-]

Thanks, that does seem better for this use case!

▲

knotbin an hour ago | parent | prev | next [-]

ATproto federates in a very different way than Mastodon. There is no concept of "instances" on ATproto.

Your account is hosted on a PDS and you sign into the app with your PDS sign-in and records go to your PDS, but everything on the app is from what's called an "AppView" which provides a centralized view of all data in all PDSes so it feels just like you're using a regular centralized app. But there can be multiple AppViews and AppViews can be self-hosted.

So unlike with Mastodon, it doesn't matter what PDS "instance" you're on because the app layer is completely separate from it.

▲

kajman an hour ago | parent | prev | next [-]

Not in expert in either but ATProto services (what they call AppViews) are substantially different from the fediverse because they rely on a shared relay instead of explicit federation.

I'm conflicted about the costs of what is currently effectively global discovery, but it's not just another Mastodon.

E: I think its funny multiple other people said the same thing in the time it took me to write this

	▲	danabramov an hour ago \| parent [-]
		Note a relay is a perf optimization and doesn’t have to be a single shared chokepoint. These days running a relay is fairly cheap (~$30/mo?), there’s maybe a dozen of them, and some apps don’t use one at all (instead relying on services like https://constellation.microcosm.blue/ for querying backlinks).

▲

embedding-shape 29 minutes ago | parent | prev | next [-]

> - Pointless debates about whether it’s OK to federate with instances that host pirated content, disagreeable politics, furry VNs, etc., which everyone has to take a side (the correct side) on

Why do you have to take a side / take the correct side? Can't you either just not take any side or take whatever side you feel like and go with that?

▲

miki123211 7 minutes ago | parent | next [-]

On Mastodon, if you take the wrong side, those on the correct side will defederate from you. Not merely because you host (or don't host) the content they like (or dislike), but because you merely enable (or discriminate against) those who host that content.

Of course, all sides are wrong in somebody's eyes; so no matter what you do, you will be defederated from by at least somebody.

The way Mastodon works, defederation irreversibly breaks all follow relationships, without notifying those involved. If you disagree with the decision, you can migrate to another server, but you won't get your followers / followees back, not without everybody involved doing a lot of manual drudge work. This is just one way in which the myth of "users are free to do what they wish, if they disagree with the admins, they can migrate somewhere else" breaks.

To make matters worse, there's no way to see which users that you may wish to follow are / will be hidden from you if you choose a given instance. Defederation lists are a (somewhat open) secret; it's good practice to announce defederations, but there's no automated API endpoint to see them, so there's no way to answer the question of "who am I going to lose if I migrate from x to y."

	▲	embedding-shape a minute ago \| parent [-]
		[delayed]

▲

throw_a_grenade 7 minutes ago | parent | prev [-]

They'll then defederate also from you. The argument goes, you're a nazi/facist/racist/*phobe, because you associate with (== did not defederate from) the designated nazi/facist/racist/*phobe.

Yes, it's that toxic. Go subscribe #FediBlock hashtag if you don't believe me.

▲

malicka an hour ago | parent | prev [-]

You overexaggerate, but even so, that would be a huge step up (even if imperfect) from bring dependant on GitHub and GitLab for you to be relevant.