@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)
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)
@samuel.bsky.team
now I'm more confused re what the app view vs relay does. and what do you mean by client?
either way, I don't see how these now overcome the same issue AP has with not knowing everything (unlike it was with one BS backend). also my understanding is there's lots of places […]
the relay doesn’t do much at all. It’s a very simple many-to-one websocket aggregator, basically
the appview is like the more traditional backend, and the client is like the iOS/android/web app. If you make your own client, for example deer.social, you can apply different moderation services
So then these PDS operators can advertise: "move your account here, and then you'll be browsing the Bluesky network from a European POV, not relying on a US-based company to control the presented information"
I think realistically, beyond just enthusiasts, the way this can become a thing on a larger scale, is if there are some public EU-based AppViews and larger EU-based PDSes, and these PDSes default to using these EU-based AppViews when you have an account on them.
You'd see pretty much the same network on that EU AppView with 99.9% overlap, but possibly some accounts/hosts would be not blocked here that are blocked there or the other way around, and you'd be putting some trust in a different place
I've noticed that if you make more than one reply here as a subthread to a post/comment from Masto, Bridgy seems to only bridge the first one… I'll need to file an issue for this @snarfed.org
isn’t it always possible that some relay never sees a given PDS, meaning that if you’re using some third-party relay, there’s always a chance you won’t see some fragment of the network?
though i suppose that’s possible today if you just don’t tell the bluesky relay about your pds…