Because the protocol doesn't support private data, Blacksky is launching a bunch of features in a centralized (Blacksky-only) way, including mutes and private posts.
These are good features, and it's great that they're building them, but it frustrates me that Blacksky is constrained by the protocol from making them participate in any of the benefits of the ATProto system such as account portability.
@noracodes permissioned data is on Bluesky PBC's Q1 roadmap, per today's office hours stream. Private data that's shared directly between PDS and an App is relatively simple (that already exists with the preferences API, but I'd guess they'd make something more lexicon aware)
Bluesky is also getting drafts imminently: https://github.com/bluesky-social/atproto/pull/4549 / https://github.com/bluesky-social/social-app/pull/9691
@noracodes it should be noted that blacksky's drafts aren't federated either.
When people said that Bluesky's federation wasn't complicated only because it wasn't real, this is what they meant.
Now that there is more than one AppView, more than one centralized repository of interconnected social data, we start to see the cracks. That's where they show up in ActivityPub too.
@noracodes great points. I see the two things as slightly different ... local-only posts (if and when they're implemented) are things that really shouldn't migrate between appviews or instances. Mutes should, both here and there, but don't. Blocks do migrate in the ATmosphere, but don't here (although you an do an export / import -- good enough and only a minor annoyance but weird that the platform itself doesn't do it). Why do mutes and blocks behave differently? I have no idea.
(Minor note: Bluesky already implemented mutes, I don't think this was new to Blacksky)
@jdp23 Yeah, I'm not sure why (or if) Blacksky isn't using the Bluesky mute functionality, but Rudy says they're doing it differently somehow.
I agree that local only posts should not migrate between AppViews, but shouldn't they migrate between PDSes? I guess it doesn't matter so much, but it seems odd.
@noracodes not sure, i think they might be implementing their own appview from scratch?
Agreed that local-only posts should migrate between PDSs. Bluesky says they're working on private data this year and depending what the implementation is that might support something like that. Rudy doesn't want to be in a situation where he has to wait for that so is going the appview route for now, will potentially migrate it later.
It is odd, an artifact of AT Proto basically being all-public, so anything non-public has to be tucked in somewhere. I'm skeptical as to how well they can shoehorn private data into it, and even if it's there at the protocol level it's not clear to me what the challenges will be to making it usable in practice.
@jdp23 @noracodes I think I disagree about migrating local-only posts. I can think of a number of scenarios where that would violate people's expectations around "local-only" in potentially unsafe ways.
Quite possibly, it really depends on the semantics and implementation of "private data". Hmm, I wonder how this works with ActivityPods?
@jdp23 Yeah, I believe it is mostly or entirely from-scratch.
@noracodes if it's like most of their other stuff it's in Rust so it makes it very hard to reuse Bluesky's stuf. Also Bluesky's muting isn't great, clearly room for improvement.
