dani personally don’t find it very interesting!
it doesn’t solve “walk away without cooperation”, it doesn’t solve “aggregation at scale in a shared open world”, and it doesn’t solve “giving new life to old data” and “remixing products”.
it’s like comparing email with www. apples to oranges
Folker@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 ...
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.
#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!
@danabra.mov I refer to 8000 different independent entities controlling moderation decisions, not 8000 apps.
I would argue that decentralization should be measured at the weakest point. If there are 8000 apps, but only one or few entities controlling moderation, I wouldn't call the system decentralized. What do you think?
why would there be 8000 entities controlling moderation decisions? if there is a real competitor to bsky who *wants* to piggyback on its data, there’ll probably have their own moderation authority. if it’s a small hobby project they probably don’t care or will piggyback on bsky moderation.
it’s a question of incentives. if someone is motivated to make an alternative app, they’d either have to do moderation or they’d have to reuse existing one. or there could be more complex hybrid models. the point is just that atproto decouples apps from source data hosting from moderation services.
this doesn’t mean that there’s magically 8000 apps or 8000 independent moderation services. it just means that anyone who wants to start one has that ability while reusing pieces they still want to reuse. by definition this model subsumes any model where they’re coupled.
you can take the mastodon model and replicate it in atproto by coupling things together. but you don’t have to. atproto lets you reuse independent pieces. but of course that still depends on dynamics of who’d want to run them and for what purpose. atproto is strictly more general in that sense
@danabra.mov
I appreciate the flexibility and modularity.
About "why": I would consider reusing a single or very few entity controlling moderation as centralization, but 8000 entities each controlling only a disjoint subset of moderation decisions as decentral. You see it differently?
Do I understand you correctly that a goal of #atproto is to allow 8000 entities to operate their own appview each pulling from 8000 labelers? https://docs.bsky.app/docs/advanced-guides/moderation?utm_source=chatgpt.com#labeler-subscriptions seems to mention a limit of 20.
I appreciate the flexibility and modularity.
About "why": I would consider reusing a single or very few entity controlling moderation as centralization, but 8000 entities each controlling only a disjoint subset of moderation decisions as decentral. You see it differently?
Do I understand you correctly that a goal of #atproto is to allow 8000 entities to operate their own appview each pulling from 8000 labelers? https://docs.bsky.app/docs/advanced-guides/moderation?utm_source=chatgpt.com#labeler-subscriptions seems to mention a limit of 20.
@danabra.mov There are unbridged interactions I cannot follow up with, e.g. ask if and where this goal or plan of decentralized labelers is supported in #atproto, and how that can scale to real decentralization. But anyway, it seems we all agree that this is an academical discussion, and right now #bluesky is basically centralized in practice. Nevertheless interesting discussion about protocols. Ideally all social media users could interact with each other using the same protocol.
skewer0846.bsky.socialThis account should be bridged now. Apparently the bridge needed a profile picture on my account for anti-spam purposes. Sorry about not setting up the bridge properly earlier.
Aaron Mills 🏳️⚧️You say Mastodon is over 8000 services. With the way Mastodon works, isn't that 8000 entities making moderation decisions? Each with a hosted version of the app?
@cloudhunter.co.uk @danabra.mov 8000 servers, yes. See "Network health" on https://joinmastodon.org/servers
@danabra.mov It seems to me that this solves a different much simpler problem (and using only a "voluntary" fix which doesn't solve the more "adversarial" case), not the moderate-all-old-data-again problem, which is fundamental for real decentralization. Do I miss something?