@jwildeboer I won't argue that it isn't as decentralized in practice as AP right now, I'm just saying that "they promise that in future you might be able to run your own relay" is misleading, because you can do that today
@Claire@eramdam@cwebber Yeah, anyone can connect to any PDS (it's the exact same endpoint as the one for the firehose on the relay). A new relay may get a list of PDSes or find them somehow, but a PDS can also ask a relay to connect. I'm assuming even with some double-digit number of connections it would still be less resources than a well-connected Mastodon instance.
I feel like some ActivityPub-focused people are kind of still waiting for Bluesky to finish and launch something they were building, not having noticed that they already did a while ago, they've just missed it because it doesn't look exactly like what they were looking out for…
@BeAware I'm gonna have a list & search of Bsky->Masto and Masto->Bsky bridged accounts at some point on my site, but it's waiting for a better day when something else isn't prioritized… 😉
@BeAware@dynamic@danie10 Yeah, there's an artificial limit of 10 accounts right now enforced at the Relay so things don't get out of hand too quickly before shit's fully ready (it can be raised on request, but I think only Bridgy has did that so far).
Oh and one more thing, web UI isn't really integrated with the AppView, it's just a web-based JS client in the same way as Elk is for Mastodon. It's technically not any more privileged that any third party app, it's just "the official one".
@BeAware@dynamic@danie10 So, correction, *all* of your data has its "original location" at your PDS - all kinds of records (profile, posts, likes, follows, non-Bluesky records like WhiteWind blog posts), "blobs" like attached images, and even videos now. You can even put non-Bsky records like whtwnd posts on your Bluesky-hosted PDS.
They aren't usually directly served from there (data is served from the AppView, media from Bluesky CDN), but they can always be fetched from the original source.
The key is that the architecture is very different, and there isn't a direct equivalent of instances. There are PDSes, but they do much less than Fedi instances, and they also don't directly talk to (federate with) each other. The data flows from PDSes to relay(s) to AppView(s) and to clients.
@BeAware It's like when you log in to your Mastodon/Fedi account in an app, you're shown your server's login page in a browser and then "Do you want to authorize app X to do Y?" and you press "Authorize". And in Bluesky/ATProto at the moment you enter that "app password" at the moment to log in, you give the app password to the third party app itself instead of to your server's login form. It's less secure because they get that password itself instead of a token & they get access to whole acct.
@BeAware Also things are kind of in flux with OAuth at the moment - they've been working on it for the past few months, but it's only partially deployed so far and not ready, there have been some required updates to the PDS related to this, and most third party apps don't support OAuth login just yet, so things might be a bit messy in that area in the next few months.
@BeAware I think you could even not have a "Bluesky profile" record with bio and avatar etc. to use WhiteWind this way (I'm not 100% sure though how the account tooling works on the installable PDS).
@BeAware Yeah yeah, that's basically the same thing - I've seen some discussions a few times "How should we call this on the website? Log in with what?", but generally I think most people agreed that "Bluesky" will be more meaningful to more new users than "AT Protocol"…
@BeAware In practice it should work this way: you enter either the address of your PDS, or your handle which is resolved to your DID which is then used to find the address of your PDS, then the app contacts your PDS to authenticate to your account and get back access token from the PDS. If your on your own PDS then none of your account data is hosted on Bluesky servers except the (public) DID JSON file on plc.directory.
@BeAware Ok so I'm not sure I understand what you want exactly 😅 So you could have a PDS that you've installed on your server, sign up for an account on that PDS, and then log in to WhiteWind and Frontpage with that account. At that point the only places where you'd have something to do with Bluesky infrastructure is: - the Bluesky Relay which WhiteWind and Frontpage almost certainly pull data from because I'm sure they don't run their own - the plc.directory which registers DIDs
@BeAware But *that's the whole point*! "One account for multiple apps", that's the selling point. Kind of like in AP you can follow PixelFed from Mastodon, in AT you're supposed to be able to log in with the same account to Bluesky or to WhiteWind and reuse some data between them (or not, you can just make a separate account). It's not really a Bluesky account, it's an ATProto account technically. You should be able to log in with non-Bsky PDS to WhiteWind and Frontpage, if not - that's a bug.
Independent Mac/iOS & web developer. Building useless random stuff in Swift, Ruby or JavaScript and wasting time.I'm mostly hanging out on Bluesky these days and hacking things on the AT Protocol, so follow me there 😎 🐦 @kuba_suder 🦋 @mackuba.eu