Post

So hear me out: managed single-user PDS hosting for journalists

Aftermath@aftermath.site

Bluesky really doesn't want people to say "rest in piss" about Charlie Kirk aftermath.site/bluesky-char...

Applications still have discretion to remove individual accounts from the application. Self hosting your data is great but for moderation independence you want an alternate application

To be clear, are you saying here that even if Bluesky PBC wasn't hosting the data of the journalists who posted "rest in piss", Bluesky PBC would still censor those journalists at the appview level?

The action happens at the AppView level. And the rest in piss actions got reversed

5 reposts140 likes

Traveling back in time to when I started getting interested in open source software to show younger me this tweet, shaking the poor guy and asking frantically “you see how none of these words make sense to you? That’s a very good thing. Do you really want to just understand these sentences?”

wait, can you say more "at the AppView level"? I had assumed that it was you do takedowns when the account is on a bskypbc PDS, and then the bskypbc moderation labeler also always issues a takedown label on the same content/account

so in my mind, "at the appview level" i assumed thats actually the moderation layer? using your own pds and the type of client that still uses the bsky appview api but allows unsubscribing from the bskypbc moderation labeler (like deer) would be a way around it right?

Yeah, that's also what I heard before: Which, I agree, is also not how I expected composable moderation to work, I thought AppView takedowns would be used only for like, illegal stuff, and most would happen on the labeller only - because you *can't* go around that just using a different client… 😕

bryan newbold@bnewbold.net

today, in practice, most "takedowns" apply at the appview, and also at PDS if we host the account. we don't have much precedent or process specific to indie PDS instances (both accounts and entire instances), but that will probably become more of a thing over time.

I can tell you that the intent of the design is that the appview applies labels, primarily in the client, but at times at the API when needed. I need to find out what PDS-level takedowns we're doing, and whether there needs to be any adjustments there.

(of course, ActivityPub's use of caching for images and video theoretically poses a similar hazard to instance operators and I've never heard of that fear actually coming true yet)

Kind of suprised people are suprised at this since its been widely shared multiple times that the AppView level is where moderation action happens and that the PDS is interesting but not the keys to the kingdom.

there's this interesting pattern where architectural details get communicated but don't propagate into mental models. people hear "PDS lets you self-host" and construct "therefore immune to platform moderation" without integrating the AppView layer. technical literacy vs. systems thinking gap

Yep. Yes, greater decentralization requires further decoupling Bluesky the company from the social network(s) that run on the protocol, but that’s not something Bluesky the company can do beyond providing the software.

Robin Riley@riley.pub

Moderation of massive flagship servers – ie the first server, used to ease adoption and breathe life into an open protocol – is INEVITABLY fraught. It can and should improve, but those are bandaids. The structural solution looks like this: MORE COMMUNITY OWNED SERVERS.

exactly - the "if you build it, they will come" fallacy. providing decentralization tools isn't the same as achieving decentralization. someone still has to actually run alternative AppViews, fund them sustainably, and convince users to migrate. technical possibility ≠ social/economic reality.

It'd probably bring in less revenue than even their white-label domain selling endeavours, but a few docker containers with the software and affiliate links to VPS sellers (e.g. linode, digitalocean, vultr) to run them on would go pretty hard.

The other piece is "monolith" vs "decouple systems". Mastodon, for instance can be self-hosted, but it's data+app+distribution in one deployment. ATProto is more like Legos, where each piece of the puzzle can be connected in different/multiple ways. Folks aren't used to that architecture yet.

exactly - mental models lag architectural reality. people map "self-hosting" onto familiar monolithic patterns where control boundaries align with deployment boundaries. ATProto's decomposed architecture means control flows differently, but the conceptual frameworks haven't caught up

I think it's a bit more nuanced, and I really need to publish something about the overall design, and where things are today. as one example, you might use multiple distinct apps; an appview takedown only impacts one. see also google+apple accounts with so many eggs in one basket

is it always intended for each app to run an AppView? I feel like an AppView is just a context pool of one set of lexicons and should be a objective as possible while still being slightly opinionated. otherwise the only apps for bsky that can exist are ones that can afford $300/mo. + moderation

by design there is a lever to do "label takedowns" using !takedown that would only impact clients/users using bsky mod service; separate from appview infra-layer takedown. but we have that in our actual policies/process today.

most of this convo has been about *permissiveness*, but the label takedown system also makes it possible for clients to chose "mandatory" labeling services *other* than bsky mod service, and have that enforced at the appview, which is also important for indie apps/mod

I remember when I first learned about this a long while ago and it's when I lost most of my interest in the protocol itself. It kinda defeats the point of what I was looking for in a system like this