Discussion
@cwebber remember how Bluesky talked so much about their design goal of avoiding the confusing situation in fedi where you see different parts of the conversation and different like and follower accounts depending on what instance you're on?
hahahahaha ...
https://blacksky.community/profile/jdp23.thenexus.today/post/3mtzhlfafec22
@adriano @jdp23 @cwebber There is also the W Social AppView, which seems to be in maybe some kind of alpha state right now. They have made the statement that it "only serves W-verified users" (verified in this context which they mean people who have uploaded their ID to a "third party" which appears not not be a third party, but W itself) - but the main reason I bring that up is that one possible interpretation of this sentence is that only returns accounts, posts, etc. from people that have been verified, and the rest of the atproto network is invisible. If this is correct, well ... I'm just sort of speechless
W Social interacts by default with the rest of the ATmosphere, but aparently there's a browser extension from somebody there that lets you block everybody on a different PDS. 🤣 And there's also a blocklist of "W Social critics" (including @elena's ATmosphere account ... a badge of honor).
The ATmosphere really is a lot more like fedi than people in either ecosystem want to admit.
The Blacksky web app fetches all profiles from both it's own AppView and the Bluesky AppView, and uses the follower numbers from the Bluesky result, since the Blacksky one doesn't have a full network view.
@ricci wait, hold on.
So are you saying that the poster child project ATmosphere project that supposedly is proving there can be a completely independent BlueSky-compatible service turns out to require both their own infra *and* BlueSky to work in order to work at all, including for folks only on Blacksky?
@rysiek @jdp23 @cwebber Agree, I've got nothing bad to say about Blacksky.
The reason they're doing what I documented here is super interesting from a federation point of view though.
AP and the fedi are designed to work pretty damn well with only a partial view of the network. atproto in general, and the way Bluesky and its alternatives are built in particular, are not, because to know, for example, how many followers you have, you have to look at every single account network wide and find the ones that have a record saying they follow you. Blacksky currently doesn't have that full network view, and people are picky about wanting to see accurate follower counts, so that's why they get the counts from another party that does have a full view.
Now, a real question that I don't really have the answer to is *why* the Blacksky AppView doesn't have a full view of the network. In the general design, it "should." What we do know is that they have not fully "backfilled" all accounts that are not on their own PDS. What we (or at least I) don't know is why not. Time-wise they've had plenty of time now to do it, and this kind of syncing is exactly what atproto is built to do. Is it on purpose, possibly for cost reasons? Is there something going wrong? If they've said something about it publicly, I've missed it (entirely possible).
The outcome though, is kinda not great. Not only are things like profiles incomplete (without pulling in data from Bluesky), but some feeds (like Following) act weird too - I *think* for the same reason, but I'm not confident in that. I think what this shows, though, is not a mark against Blacksky, but a mark against the idea that a whole network view is even necessary. People, by and large, seem to be happy on it.
Another fedi thing that the atmosphere is currently experiencing, despite atproto architects asking them to please not, is blocking users by PDS, like folks block whole instances here, and this will likely lead eventually to something that looks like the atmosphere's own version of defederation. The most visible instance of this currently are that Eurosky and W Social are both European and right now have similar user numbers, but have very different user bases, and there is constant complaining, and PDS-wide blocking, between users on each.
Agreed, the atproto stack is simple to get going with but very complex in practice -- and evolving very quickly (speaking of which, permissioned data is in alpha, that should be interesting). It also doesn't help that a lot of people used Bluesky's original implementations as a starting point, because they had a lot of implicit dependencies ... there are valid reasons for this all around but it's created a mess (somewhat analogous to how some of Mastodon's early decisions, now seen as suboptimal, have created a mess here for compatibility concerns).
A lot of this was broadly predictable. With the defederationish behavior, for example, I can't remember how many times I've said something like "what happens once there's a NaziSky?" Decentralized systems are hard! And in general it's why I see both of these ecosystems as prototypes -- the work @cwebber's doing at Spritely is much more deeply thought out.
But also there's plenty of complexity and confusing stuff here as well, it's just that those of us who have stuck around here for a while are used to it. Just a few minutes ago I clicked on a link embedded in a post and it wound up taking me to an instance I wasn't logged in on, so I had to do the cut-and-paste-into-search box trick ... I've done it so often that I don't even think twice but it's bewildering to newcomers. And why does Christine's post (quoting the original post in this thread) have 30 boosts and 49 likes when I look at here, but only one boost and no likes when I look at it on gotosocial.thenexus.today?
So the whole ActivityPub stack is also immensely complex, and in flux in ways that make it difficult to reason about.
Hey wait a second, I'm noticing a pattern here.
"Require" is too strong there - the behavior I linked to is (a) mostly just cosmetic (b) can be turned off with little consequence (in fact they *might* have done so during the last multi hour Bluesky outage - I know if I were in their shoes I would have)
Maybe the best fedi analogy I can make here is: you know how we're all used to the fact that if you look at a remote account's profile on your own instance, it might be incomplete because your instance may have a stale cache, not have seen all their posts, that kind of thing? And we know (in part cause the Masto interface says so) that you might need to click through to the original server to see the whole thing? Well imagine Masto had a feature where, when you were viewing the profile locally, it quietly also fetched it from m.s and used that data as authoritative for stuff like follower counts. Yes it would mean you're hitting m.s constantly from your client, but it's not actually very important.
Install bonfire.cafe
Get the full app experience
