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.
-
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.
-
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.
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.
-
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)
-
@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.
-
@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.
-
@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 Yeah, I believe it is mostly or entirely from-scratch.
-
@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.
-
@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.
@noracodes not sure if you've tracked it but they are starting to be situations where people want to block everything on a PDS. Instance blocking, ATstance blocking ... potayto, potahto
-
@noracodes not sure if you've tracked it but they are starting to be situations where people want to block everything on a PDS. Instance blocking, ATstance blocking ... potayto, potahto
@jdp23 I hadn't seen this, but it's not hard to believe.
-
@jdp23 I hadn't seen this, but it's not hard to believe.
@noracodes totally predictable! There's a lot they can learn from fedi both about what works and what could be improved but it's not clear how much that'll happen. Rudy's local-only posts are the only clear example I know of so far, that came from his discussions with Darius.
That said, my oh my the migration is a lot smoother there. It's not just the protocol level, PDSMoover and textite have very nice UIs where you basically give old account / new account, you can optionally add a rotation key for backups, etc. It really hlighlights how much progress could be made here -- Slurp is great, a big step forward, but still a long ways to go. Oh well.
-
@noracodes totally predictable! There's a lot they can learn from fedi both about what works and what could be improved but it's not clear how much that'll happen. Rudy's local-only posts are the only clear example I know of so far, that came from his discussions with Darius.
That said, my oh my the migration is a lot smoother there. It's not just the protocol level, PDSMoover and textite have very nice UIs where you basically give old account / new account, you can optionally add a rotation key for backups, etc. It really hlighlights how much progress could be made here -- Slurp is great, a big step forward, but still a long ways to go. Oh well.
@jdp23 I shan't beat this drum at you too much, but, they did have $30 million to do that with. I suspect things would be a lot better here if we had that kind of cash.
Hell, if I could go full time developing fedi software, I absolutely would.
-
@jdp23 I shan't beat this drum at you too much, but, they did have $30 million to do that with. I suspect things would be a lot better here if we had that kind of cash.
Hell, if I could go full time developing fedi software, I absolutely would.
@jdp23 @noracodes the good moving UIs over there are all third party so they haven't even spent any money on it, they're using volunteer labor
(but part of it is, really, that the protocol makes it quite easy)
-
@jdp23 @noracodes the good moving UIs over there are all third party so they haven't even spent any money on it, they're using volunteer labor
(but part of it is, really, that the protocol makes it quite easy)
-
@jdp23 @noracodes fuck it, I'll help fund it if there's a way to
-
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 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.
-
@jdp23 I shan't beat this drum at you too much, but, they did have $30 million to do that with. I suspect things would be a lot better here if we had that kind of cash.
Hell, if I could go full time developing fedi software, I absolutely would.
@noracodes @jdp23
Also, the specific task of rehoming data is borderline trivial when all of the documents are public, immutable, and self authenticating. -
R AodeRelay shared this topic
-
@jdp23 I shan't beat this drum at you too much, but, they did have $30 million to do that with. I suspect things would be a lot better here if we had that kind of cash.
Hell, if I could go full time developing fedi software, I absolutely would.
Agreed about the funding difference, but in this case the nice UIs were actually developed by an independent developers (who has a ko-fi) and by Blacksky. It's the same dynamic as here, the dominant platform doesn't really have an incentive to make the migration all that smooth.
-
@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.
-
@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?
