12 ms·

It’s not more painful because there’s plenty of alternatives for activitypub instances, but only one bluesky. And you’re meant to either host your own instance,

It’s not more painful because there’s plenty of alternatives for activitypub instances, but only one bluesky. And you’re meant to either host your own instance, or pick one that aligns with your views and interests, such that the bulk of moderation is handled for you in terms of which instances you federate with etc.

chokolad 3mo ago
> It’s not more painful because there’s plenty of alternatives for activitypub instances, but only one bluesky. No, there is not. There is blacksky, northsky, eurosky. They all display the data from your PDS.
- kuschku 3mo ago
  I'm already running my own RSS reader, Matrix server, Mastodon instance, etc. How do I run my own appview? They surely have a git repo, docker images and helm chart, right? And if I can't self-host it, surely every local computer club should be able to, as they are with all the other protocols?
  - danabramov 3mo ago
    You can trivially host an appview for your atproto app on your own. I have a hobby atproto app, and I host an appview for it. I mean — an “appview” literally just means “a server with a database that ingests stuff from the network”. It’s not some mysterious thing or some concrete distribution. It just means you’re aggregating stuff into your database. It’s just as cheap as hosting any webapp. But what you’re asking is not that. You seem to be saying “I want to host my own Bluesky appview”. That’s resource-intensive for the same reason “I want to host my own Twitter backend” is expensive. It has nothing to do with the protocol! If you want to host a database application server that stores gigabytes of data from millions of users forever, you’re gonna have to pay for that. This isn’t some kind of gotcha with the protocol, it’s just common sense. That’s the “instance brain” from my article. You’re used to the shape where the only thing you can host is a “isolated copy of the same app that only deals with a few users”. But that’s not the atproto topology! What atproto lets you host is the real thing. Like a second real Twitter app that “just works” with all existing users. That’s the value proposition here. Or — if you’re not actually in the mood to host a product with millions of users — you can make your own app that has nothing to do with Bluesky. And of course your own app aggregating its own data would be cheap to host because it won’t be aggregating millions of records. Do you see the disconnect? Atproto allows competition at big scale — actually forking real products — which AP doesn’t do in principle. But you’re using this ability as a knock again atproto. Atproto scales arbitrarily up, so you take the highest scaled up example you can think of (Bluesky app with all its users and posts) and compare it to the cost of running the most scaled down version of AP (an isolated app for some people). To make the comparison fair, we’d need to scale atproto down in your example. You can definitely achieve scale identical to Mastodon (and thus identical in costs) by taking the Bluesky app server and adding custom logic which ignores all events that aren’t relevant to some hardcoded lists of users (your “member list”) or people they follow. That would be an accurate comparison, and yes, you could totally host that. People don’t do that because it’s kinda niche. Maybe it would be nice if there were ready-to-go distributions of Bluesky appview that do this kind of filtering. But also — it’s just kind of a non-goal for most developers on the platform. Most developers create their own different apps, rather than host alternate projections of the Bluesky content of the whole world.
    - kuschku 3mo ago
      Say bluesky is applying content moderation techniques I disagree with. What steps do I have to follow to get the majority of users to see my content? Another example. Let's define decentralisation in terms of bus factor: How many companies could go bust today before most users would notice? > To make the comparison fair Okay, so let's build that, then we can actually talk about building a decentralized network on atproto. How do I build a relay that fetched all content from people I follow, plus all replies to those posts (no matter who sent them), plus automated backfilling if I click on the profile of someone who I'm not following yet? From what I understand, in bluesky the PDS does not know about replies to a post. So I'd need to scrape the entire network anyway, no matter what, even if I only store some of it. And every blue-stodon instance would have to scrape every single PDS. So it's a much much worse O(n²) issue, isn't it?
      - cavoirom 3mo ago
        > And every blue-stodon instance would have to scrape every single PDS. So it's a much much worse O(n²) issue, isn't it? They could rely on some relays to build their AppViews. The flexibility is already there.
        kuschku 3mo ago
        I feel like you're missing the point of a decentralized protocol if at every step you suggest to use centralized services instead.
        cavoirom 3mo ago
        You can self host every component in the stack. You can create a new one for your use case.
        lmorchard 3mo ago
        And then once you've self-hosted ever component in the stack, you have one (1) Mastodon instance equivalent :)

chokolad 3mo ago

> It’s not more painful because there’s plenty of alternatives for activitypub instances, but only one bluesky. No, there is not. There is blacksky, northsky, eurosky. They all display the data from your PDS.

kuschku 3mo ago
I'm already running my own RSS reader, Matrix server, Mastodon instance, etc. How do I run my own appview? They surely have a git repo, docker images and helm chart, right? And if I can't self-host it, surely every local computer club should be able to, as they are with all the other protocols?
- danabramov 3mo ago
  You can trivially host an appview for your atproto app on your own. I have a hobby atproto app, and I host an appview for it. I mean — an “appview” literally just means “a server with a database that ingests stuff from the network”. It’s not some mysterious thing or some concrete distribution. It just means you’re aggregating stuff into your database. It’s just as cheap as hosting any webapp. But what you’re asking is not that. You seem to be saying “I want to host my own Bluesky appview”. That’s resource-intensive for the same reason “I want to host my own Twitter backend” is expensive. It has nothing to do with the protocol! If you want to host a database application server that stores gigabytes of data from millions of users forever, you’re gonna have to pay for that. This isn’t some kind of gotcha with the protocol, it’s just common sense. That’s the “instance brain” from my article. You’re used to the shape where the only thing you can host is a “isolated copy of the same app that only deals with a few users”. But that’s not the atproto topology! What atproto lets you host is the real thing. Like a second real Twitter app that “just works” with all existing users. That’s the value proposition here. Or — if you’re not actually in the mood to host a product with millions of users — you can make your own app that has nothing to do with Bluesky. And of course your own app aggregating its own data would be cheap to host because it won’t be aggregating millions of records. Do you see the disconnect? Atproto allows competition at big scale — actually forking real products — which AP doesn’t do in principle. But you’re using this ability as a knock again atproto. Atproto scales arbitrarily up, so you take the highest scaled up example you can think of (Bluesky app with all its users and posts) and compare it to the cost of running the most scaled down version of AP (an isolated app for some people). To make the comparison fair, we’d need to scale atproto down in your example. You can definitely achieve scale identical to Mastodon (and thus identical in costs) by taking the Bluesky app server and adding custom logic which ignores all events that aren’t relevant to some hardcoded lists of users (your “member list”) or people they follow. That would be an accurate comparison, and yes, you could totally host that. People don’t do that because it’s kinda niche. Maybe it would be nice if there were ready-to-go distributions of Bluesky appview that do this kind of filtering. But also — it’s just kind of a non-goal for most developers on the platform. Most developers create their own different apps, rather than host alternate projections of the Bluesky content of the whole world.
  - kuschku 3mo ago
    Say bluesky is applying content moderation techniques I disagree with. What steps do I have to follow to get the majority of users to see my content? Another example. Let's define decentralisation in terms of bus factor: How many companies could go bust today before most users would notice? > To make the comparison fair Okay, so let's build that, then we can actually talk about building a decentralized network on atproto. How do I build a relay that fetched all content from people I follow, plus all replies to those posts (no matter who sent them), plus automated backfilling if I click on the profile of someone who I'm not following yet? From what I understand, in bluesky the PDS does not know about replies to a post. So I'd need to scrape the entire network anyway, no matter what, even if I only store some of it. And every blue-stodon instance would have to scrape every single PDS. So it's a much much worse O(n²) issue, isn't it?
    - cavoirom 3mo ago
      > And every blue-stodon instance would have to scrape every single PDS. So it's a much much worse O(n²) issue, isn't it? They could rely on some relays to build their AppViews. The flexibility is already there.
      - kuschku 3mo ago
        I feel like you're missing the point of a decentralized protocol if at every step you suggest to use centralized services instead.
        cavoirom 3mo ago
        You can self host every component in the stack. You can create a new one for your use case.
        lmorchard 3mo ago
        And then once you've self-hosted ever component in the stack, you have one (1) Mastodon instance equivalent :)