So I usually hate sending over bluesky links anywhere since I'm not a fan, but Rob Ricci highlights some important distinctions between #activitypub and #atproto

Fundamentally, activitypub is designed to be useful with a partial view of the network. (Narrowing down to #mastodon here) Likes are communicated, mentions are communicated, and so on.

Over at atproto land, you have no option but to write to your repo, and so you have no choice but to view the entire network to say, find replies and such (narrowing to #bluesky here). So the only way you can get your data is to read the network and filter it yourself, or have someone else do it for you, which doesn't solve the problem, only shift it.

https://bsky.app/profile/ricci.io/post/3mooua5znk225

#bluesky #bsky #atproto #mastodon #fediverse #activitypub

Rob Ricci (@ricci.io)

ehhh... only sort of agree. The difference is that AP has a way to notify another instance if, say, there is a reply to a post, or a mention of a user. This scales down well. In atproto, since you can only write to your own repo, the only way to find replies is to observe the entire network.

Bluesky Social

https://overreacted.io/there-are-no-instances-in-atproto/

While having an extremely snobbish and arrogant tone, I think it makes some good points about separating hosting from viewing, which I think the usual #fediverse sort of conflates. And while the doesn't doesn't cover it, #atproto also has the unique feature of your data being relatively portable, largely absent in #fediverse.

#fediverse #atproto #bluesky #mastodon #lemmy #activitypub

There Are No Instances in atproto — overreacted

Like RSS and Google Reader.

On the other hand, the post largely glosses over the actual cost of running it, which Rob addresses above.

In fact, it entirely skips relays, which are so fundamental now, and in particular, that every #atproto app effectively needs to consume one.

(If your atproto app doesn't consume from a relay, it HAS an embedded relay, and in that case, god help your app's compute consumption).

#atproto #bluesky

Having said that, and also disliking the fact that it came out of corpo billionaire creators of twitter, I genuinely believe there's some good stuff to pick up from that protocol.

In particular, I think the coolest part of the architecture is server-independent (more like server-migratable) identity, which is kind of amazing.

Activitypub/fediverse should adopt https://helge.codeberg.page/fep/fep/ef61/ soon, and I feel like that'd be even better than what atproto has if I understand correctly.

#activitypub #fediverse #atproto #bluesky #mastodon #federated #protocols

FEP-ef61: Portable Objects - Fediverse Enhancement Proposals

Portable ActivityPub objects with server-independent IDs.

Hate to mention people out of the blue, but @ricci @cwebber if you can vet this info it'd be great. You two seem like the experts in these two topics, and I don't want to get stuff wrong. Thanks.

@innocentzero @cwebber

FWIW, I didn't personally find this article to be particularly snobbish or arrogant. I think it's quite well written, and while it does have a particular viewpoint and is written with a strong voice, I think it's making a good faith attempt to explain something that is a frequent point of confusion/contention when people are discussing the fediverse and atmosphere.

However, I think it uses a metaphor that's flawed enough that it's not really helping; here's my part of the thread on that:

https://bsky.app/profile/ricci.io/post/3moogiuvkjc2e

In short, article positions the data storage (PDS) as the blog in its analogy, but I think the PDS is actually more like the backend database for the blog. When people familiar with the fediverse and Web in general ask "why are there not more atproto instances" they are not asking why there are not more databases with people's raw blog posts in them, they are asking why all the blogs are served through a small number of websites.

This particular exchange, I think, helps to clearly explain the difference in how Dan and I are looking at these networks:

https://bsky.app/profile/danabra.mov/post/3moovf2g2dk2u

https://bsky.app/profile/ricci.io/post/3moovkbywnc2t

Rob Ricci (@ricci.io)

Someone can visit my blog with an "app" that is self-hosted and ubiquitous: a web browser. Or, we can view the blog's backend DB + PHP/python/whatever as the complete app. Either way, I can set up a blog and people can read it with or without an RSS reader.

Bluesky Social

@cwebber @innocentzero @ricci

Somewhat related—on the relative moderation loads of a PDS owner and the owner of a Fedi instance.



RE: https://app.wafrn.net/fediverse/post/78e7e0d7-bd19-49ee-936d-7e5bb388c706
#ATProto #ATmosphere #Bluesky #ActivityPub #Fediverse #Mastodon

@dialecticalmusings @cwebber @innocentzero

I partially agree and partially disagree.

I agree that moderation load on fediverse instances can be high, and demonstrably leads to burn out. I think "the entire network" is overstating it; they only have to moderate the fraction of the network their users interact with. Which yes, can be a lot. But it scales linearly in the number of users, and one reason many folks tend to argue for relatively small instances.

What you get in return is the ability to create and maintain community standards.

Yes, you can run a PDS, in which case you are offloading almost all moderation to others. But you are just a data host. You cannot form a community with a PDS alone, and you are feeding that data into a service that must try to enforce some sort of global homogeneous notion of "community standards", which is the moderation scaling problem that many people are trying to avoid by using decentralized social networks.

If you want to form a community, with standards, you either need to run an appview, in which case you are truly moderating the *entire* network, not just the portion your users interact with; or you use the labeling tools available on eg. the Bluesky appview, which are cool but are not really good for community formation.

My recent conversations over on Bluesky have led me to the conclusion that, so far, people building on atproto tend (with exceptions) to think of themselves as building products, and people building on activitypub tend of thing of themselves as building communities. These are both fine, if that's what you want as a developer or user. The difference in moderation load comes from the fact that it's fundamentally different to bring your own data storage to someone else's product than it is to host a community. I think this is largely in line with what you are saying, but I think it's important to understand how different they are.

@ricci @dialecticalmusings @cwebber @innocentzero Plus it's completely possible to run one-user ActivityPub instances. I basically don't have to moderate anything there, and yet I host a number of my publications' accounts there which both post to and reply/boost others' content.

The "hard zone" is probably instances which have many dozens or a hundred+ users, requiring much more hands-on oversight but lacking financial resources. Under that or well over that, it's a different story.

@jaredwhite @dialecticalmusings @cwebber @innocentzero The author of the post we're commenting on - and, I think many other atproto developers and advocates - seem to not see the value in single-user instances because they think of Bluesky as "an app" or "a product" that only makes any sense as a whole, and not as a network where each node is valuable in its own right, there is value in controlling that node, and we build something larger by making choices on how to network. I think this is very un-web-like thinking, but it does have a certain logic if you think of it as a product and not a network.
@ricci @jaredwhite @dialecticalmusings @cwebber @innocentzero I encountered this prejudice when I was a moderator. Among the moderators! For them simply being a single user instance was straight up a black mark. Just one of the reasons I am no longer on that instance.

@jaredwhite @cwebber @innocentzero @ricci

As long as the single user-owner follows users on other instances, they are still responsible for moderating every post and every boost by those users. The load will obviously be far lower than that on a multi-user instance, but it will not be zero.

A PDS owner can also choose to be the sole user there. In that case, they simply have to ensure that they themselves post nothing illegal.

So my basic point still holds.

Agree with you that the moderation load will be particularly intense in case of large instances.


#ATProto #Bluesky #ActivityPub #Fediverse #Mastodon

@dialecticalmusings @jaredwhite @cwebber @innocentzero

> As long as the single user-owner follows users on other instances, they are still responsible for moderating every post and every boost by those users.

Only if they choose to expose a public "global" feed.

[edit: that is, the feed that shows everything seen by the server, not just posts made by the local user]

@cwebber @jaredwhite @innocentzero @ricci

Only if they choose to expose a public "global" feed.

Yup – agreed.

@dialecticalmusings @jaredwhite @innocentzero

I am currently working on a moderate issue on my instance regarding a reportedly-problematic instance that uses a language I don't speak and involving cultural nuances in a different country that are completely unfamiliar to me. This is, however, quite a rare situation. Normally, I have an easy time because the kinds of moderation issues that come up are ones encountered by people I have a lot of common context with, and that we have explicitly disallowed on our instance.

The atproto model described by the blog post - and specifically the Bluesky app/appview - simply cannot have this moderation context. If they have someone join who is hated/feared by trans users for the harm done by their rhetoric - toeing the ToS line but being careful not to cross it - then they "have" to allow that user on. I do not. I can deny them an account on my instance, block their account, block the instance they are on if it is a source of harassment for my users, etc. I am accountable to my users, I owe nothing to them.

@dialecticalmusings @cwebber @innocentzero @ricci Sorry, I'm not following. I'm not responsible for moderation of other users' content on their own instances if I'm the only user of my instance. There's no other user of my instance who would be expecting me to control what they are able to be exposed to.

@cwebber @innocentzero @ricci

I did say

… legally responsible for moderating the entire slice of the Fediverse visible to their instance.

so I am aware that a Fedi instance owner does not have to literally moderate the entire network. :-)

Why is the increase in moderation load (necessarily) linear though? Say, I am an instance owner, and a new user joins my instance. If she follows the conventional Fedi wisdom (“you are your own algorithm—follow a LOT of people and build a rich feed”) and immediately follows a lot of users from other instances, and if many of those users post a lot, and/or boost a lot, then all those posts will now land on my instance, and I am legally responsible for moderating them. Similarly, if my new user starts boosting a lot of posts from other instances, then I am responsible for moderating those too. So at least in this hypothetical example, the moderation load increases exponentially.

Of course, in case of an inactive user, the load may not increase at all.

I think the more important point is the uncertainty of not knowing what new stuff from other instances may suddenly start landing in your storage. (When I earlier said “more or less the entire network”, it’s this uncertainty that I had in mind.) Your existing user may start following some toxic person, and suddenly in comes the deluge. You may not have the bandwidth to look at some moderation report, and by the time you get round to it, the issue may have blown up.

In comparison, an admin/owner has a lot more authority and control over their own users, so there isn’t as much anxiety.

My only point was this: a PDS owner in the ATProto world does NOT have to moderate stuff originating on any other PDS. In the ActivityPub world, this option does not exist. To a lot of people, this difference matters.

By the way, you said:

If you want to form a community, with standards, you either need to run an appview, in which case you are truly moderating the entire network, not just the portion your users interact with …

I was under the impression that a PDS can directly communicate with another PDS without the need of an intermediary relay or AppView. Isn’t that correct? So couldn’t someone host a PDS + AppView (no relay), directly communicate with a small number of PDSs, and have their AppView show only those conversations? Wouldn’t this PDS + AppView setup be the equivalent of a Fedi instance? I could be wrong, but I believe wafrn does something like this on the ATProto end.

Regarding your broader argument:
I agree with you that moderation is a critical part of community building. (A corporate executive may say that in case of social media, moderation is the product.) I also know that moderation is a social + political + economic exercise, in addition to being a technical measure.

Personally, I think we need to urgently imagine what ought to be the political economy of social media. Is the Fediverse a public utility? If yes, who is providing the public utility? The state? Which state? Or some NGO? Some philanthropist? To whom is the public utility being provided?

Or is the Fediverse a market of commodities? If yes, who is selling those commodities? To whom?

One can ask similar questions about the ATmosphere. (The movers and shakers in that world seem to imagine it as a market of commodities, as you point out. But that may be just Americans on autopilot, there may be no deep thought behind it.)

The questions of moderation and community building are deeply entangled with the questions of political economy. People arguing about moderation and community building often have fundamentally differing visions for the political economy of the Fediverse, but those differences never get unpacked, so people end up talking past each other.


#ATProto #Bluesky #ActivityPub #Fediverse #Mastodon #wafrn
Wafrn, the social media that respects you

Wafrn is a social media inspired by tumblr that connects with the fediverse

app.wafrn.net
@dialecticalmusings @cwebber @innocentzero The reason it's linear is that if each user interacts with N other accounts, two users interact with 2N accounts, three with 3N accounts, and so on - this is linear scaling. Of course the Ns will be different for different users depending on their activity, and it's actually likely to be sub-linear since some of your local accounts are interacting with the same remote accounts, but this is the basic principle.

@cwebber @innocentzero @ricci

Ohhh, okay. I guess I was vaguely imagining the moderation load in terms of the increase in number of outside posts landing on an instance with the addition of each user. In other words, I was imagining that some edges connecting the nodes (users) could be very thick, and some very thin. Even then, one may simply measure and use average thickness of an edge, I suppose.

@dialecticalmusings @innocentzero

[Removing Christine from CC list as I think she expressed a disinterest in contributing to this thread.]

Sure, some links will be thicker in terms of, say, how many posts are passed back and forth between a pair of users. However, the thickness of that user-user link depends only on the activity of each of those users, not the total number of users. When we add up instance-instance links, by adding up the user-user links between those instances, this linear in the width of each of those user-user links (in fact it will contain duplicates, since two local users may follow the same remote user, etc.)

@dialecticalmusings @cwebber @innocentzero

> I was under the impression that a PDS can directly communicate with another PDS without the need of an intermediary relay or AppView. Isn’t that correct?

This is not correct from the "pure" atproto viewpoint. A PDS is simply a store of records, it has no user interface, it has only an API that users use to create and maintain their records (posts, etc.) and a streaming API for others to get copies of those records. The only visible interaction that users have with their PDS is the oauth login flow.

Think of it like an s3 bucket, if that is meaningful to you.

In this context, it makes no sense for PDSes to talk to each other.

Wafrn looks much more like the "instance" that the author of this article calls nonsensical in the atproto world, because it combines several things, including the store of many users' data including users who are not "local", the web interface and/or APIs that users access it with, and more. Wafrn does work in this world, but it is very much in opposition to the architecture the article at the root of this thread is claiming as the "correct" use and understanding of atproto.

@dialecticalmusings @cwebber @innocentzero

> Personally, I think we need to urgently imagine what ought to be the political economy of social media. Is the Fediverse a public utility? If yes, who is providing the public utility? The state? Which state? Or some NGO? Some philanthropist? To whom is the public utility being provided?

Strongly agree - the political economy used by atproto - as described in the blog post - is exactly the same one used by Twitter/X, Facebook, Instagram, and all of the other big tech companies. The "app" is a centralized thing, a product, that may have many stakeholders, but has one owner. Yes, they may provide you with some moderation tools Facebook doesn't give you, but at the end of the day, there is an owner of the app, and their moderation is enforced for all users of that app, regardless of what their PDS is on (Bluesky bans users from their appview, regardless of the user's PDS, for violations of their ToS). That is what you are outsourcing to when you run your own PDS but use their appview.

What is decentralized in the architecture shown in this blog post - which is the generally-agreed-on use of atproto - is *just* storage. This makes no appreciable difference to the political economy.

Now, both Blacksky and wafrn break this "typical" atproto architecture, in different ways. Blacksky does so by running a copy of (almost) the entire network (as well as other things like a more open governance process). In the blog author's diagram, it is basically another app, which happens to have functionality and network visibility that are very similar to the Bluesky app. wafrn breaks it more by building the "instance" that the author of the post doesn't think anyone should think of, combining the app and storage in a way that looks much more like the fediverse.

The fediverse (including wafrn here) provide the opportunity to experiment with fundamentally different political economies than the big tech companies have built. atproto (as understood by the author of this blog post, and as generally discussed) does not.

@ricci @dialecticalmusings @cwebber @innocentzero

What about we all run single-user servers, like #holos or something ?
No need to have moderation at scale, everyone is responsible for his own opinion and everyone can decide the people he wants to speak with.

My posts are public, if public means that everyone can potentially see them.
They won't be read by the whole world anyway