Post

What's to stop someone running their own relay and appview, but "locked down", so that instead of trying to scrape every account from every PDS in the world, they only look at a limited subset? This doesn't sound too difficult. (He says, not having tried to do it...)

Jetstream and Tap both support that kind of filtering natively, it's entirely doable. You would need to fall back to something like Constellation for incoming references from outside the subset though.

the issue i face with this is: how do i host something for a community that can see everything on the protocol but does not rely on/trust bluesky pbllc infrastructure without making it a major effort? microcosm projects exist but the ux isn’t there, generally (no feeds, labelers, etc)

You could do it the way I suggested in the article, with a custom feed server for the following feed that's limited to just the users in an invite-only PDS.

This is exactly the point of the article. You don’t need an infinite archive of 40M accounts if your goal is independence. You can run a Red Dwarf instance. You can run a PDS. etc etc Just like no one runs a copy of all Mastodon servers in the world.

Roundabout runs a full, independent atproto stack for each community in the $10s of dollars per community per month. Getting below that is easily possible, either by combining the community infrastructure and/or by making latency tradeoffs.

Are those communities with the full atproto stack connected to the "Atmosphere", e.g. do they get the full atproto firehose? Or are they separate "islands"? Basically a cluster of (or even just one) PDS with a combined AppView+relay, only serving and seeing community accounts/participants?

Right now they're islands, with fully independent PLC, PDS, etc. We could turn on the firehose, but we need to figure out what that means from a UX perspective, first. Taking things step by step. 😊

Then it is more like hosting a phpBB or Discourse community IMHO, which can easily be done for $10/mo. Consuming the full, global atproto firehose and hydrating events in an AppView is a different beast and probably not doable for $10/mo. Except maybe with tricks/clever filtering?

It's not a simple system to run at the moment, but we'll get there. Everyone's still at the "what is this? How does it work?" stage, not yet at "how do we connect these well-understood things in elegant turn-key ways?"

Would be fun to do that small instance implementation but also make it (optionally, and obviously with non trivial cost) implement AP for local users. Then people wouldn't have to choose which protocol. Although that starts to sound like embrace extend extinguish.

Anuj Ahooja@quillmatiq.com

Just learned about FediSky, a project by @msonnberger.com that adds an ActivityPub instance sidecar to a PDS. Think Bridgy Fed except hosted by the PDS owner or Wafrn except reversed. Still in early dev, but keeping an eye on this space 👀