@danabra.mov I'm not sure if #atproto has solved that either, neither in practice nor in theory. In practice today #atmosphere is basically centralized in #bluesky, so if you are blocked on #bluesky, also migration would keep you invisible for basically everyone else. But also in theory for a "credible exit" and "giving new life to old data", which new service would accept you and retroactive moderate all your "old data" again? How would this work?

re: first point, there’s actually a real issue there with where moderation is currently applied but there’s ongoing work to fix that. see here for details

Update on Protocol Moderation ...

re: retroactive moderation etc, i feel like this is just shifting goalposts. yes sure there’s new kinds of challenges tied to new kinds of opportunities, but even having access to data from dead product is something you could not do before in principle. i think app builders will figure it out

i wonder if it would be possible to archive existing bsky moderation decisions and piggyback on those when starting something new

@danabra.mov The issue is much deeper than migration. I mean, #mastodon is distributed over 8k servers. If #bluesky would be decentralized in the same way and also distributed over 8k independent entities, wouldn't this mean that every single post would have to be moderated 8k times?

@danabra.mov Let me state the following thesis: You cannot have scalable #decentralization and own your own data at the same time. It's a trade off.
#activitypub decided for scalable #decentralization, but at the costs of your data being tied to the servers.
#atproto decided for owning your data (*), but at the costs that it cannot be scalable #decentralized.
(*) At least in theory, because in practice basically everyone is using #bluesky PDSs.

bluesky moderation is neither tied to PDS nor to the app server. it’s a separate service. the app server aggregates it (i think?) and the client uses those labels. bluesky being “decentralized in the same way” is already a nonsensical sentence because atproto uses a different network topology

in atproto all of those things are separated. you don’t have “8000 bluesky instances” or something like that because bluesky is just an app. there’s no point to having 8000 copies of the same app. what you can have is distributed hosting (unrelated to most moderation) and separate apps

someone can build a different app that ingests bluesky data from user repositories and ingests official bluesky moderation and decides what to do with that. or it could ignore bluesky moderation and do something else (like own or no moderation). the system is modular. it’s more like rss

to understand atproto, you need to forget how mastodon works and think about how web works. in web, everyone can publish a website. but also everyone can aggregate, scrape and index other sites. whoever does that decides how to apply moderation to that index (and whether to apply it).

one difference with the web is that scraping is seamless and is *the* way to do aggregation. and aggregation is encouraged. and there’s a first-class concept of labelers and labels as entities on the network so aggregators can choose to share moderation decisions.

@danabra.mov Yes, I agree completely with your description. My point is different. By "8000 bluesky instances" I mean 8000 different independent entities controlling moderation decisions. Do I miss something in my thesis above?

i don’t understand the question. each entity that aggregates data (ie app) can ingest moderation decision from one or more labelers (moderation services). if there’s 8000 apps, for whatever reason, each app chooses whether to piggyback on someone’s decisions or not

if you’re asking whether 8000 independent services that decided to not cooperate would have to moderate each post 8000 times, the answer is yes, but it’s a loaded question. it’s like asking whether 8000 people who decided to review a book independently would write 8000 reviews. obviously yes!