@samuel.bsky.team@mmasnick.bsky.social
so I've been told this was true (or easy) many times before. if finally true, very awesome. congrats.
but now it gets real (MTV etc). you have our problem of which node to join for new users. BS becomes much less appealing to VCs. you actually have to […]
@cloudhunter.co.uk
afaik that's where we are now. but to truly try to help make the network more decentralized, won't you not only have to choose where to host your PDS and what domain name to use, but what app view and relay to use?
otherwise people will default to the bluesky defaults, same […]
PDS choice is a lot easier choice to make, due to zero-friction migration. You can change your PDS at any time. And then the relay/appview choice is just a matter of which app on your phone you decide to use that day. You’re not committing to anything permanent when you make these choices
@samuel.bsky.team
I can understand switching app views that easily but if the advantage of the BS relay compared to fedi was that it knew everything going on in the network unlike my mastodon server who only knows of the other servers it has dealt with before, how do multiple relays work?
the […]
ok so all the data is out there, sitting on various PDSes. a relay aggregates all the data emitted from these into one single event stream. relays are effectively live views of the entire network, they don’t keep historical data. They feed into AppViews. 1/3
AppViews are responsive for transforming this event stream into an actual social app, by tallying like counts etc. Since relays provide updates from every PDS they can see, AppViews can thus provide a view of the entire network. Moderation, incl. regional moderation, is done at a separate level: 2/3
Labellers. The clients themselves are responsible for selecting which labellers to use, so moderation choice is actually pretty low friction and can be changed while still using Bluesky’s pds+relay+appview stack (see deer.social)
fig (aka:[phil])@bad-example.com· 4 May 2025
