Use DM to disable instead of blocking?

[snarfed]

Blocking is an awkward, surprising mechanism for disabling the bridge. Blocking can be undone in both the fediverse and Bluesky, but right now disabling the bridge for fediverse => Bluesky can't be undone, #1130. I get a steady trickle of users who do this, and don't realize it disables the bridge, and they're confused why it's no longer working for them.

One option would be to switch to using DMs instead. You can already DM no to the bridge user to disable the bridge. I don't advertise this, since multiple ways to do the same thing is generally confusing UX, but we could switch to this.

Alternatively, we could just push to get Bluesky team to make repos undeletable on their end, #1330 , and then this wouldn't be a problem. That's arguably the better long term fix, but I'm not holding my breath on ETA on their end.

[qazmlp]

If you are doing this, it may be a good idea to also have a (preferred) command that only deactivates the account on the Bluesky side. IIrc the PDS doesn't need to serve data for inactive accounts and the AppView won't show any (but will hold onto its internal cache).

[snarfed]

Hmm! I don't quite follow "only deactivates the account on the Bluesky side." As opposed to fully deleting? If so then yes, that's what we do now, in hopes that Bluesky team will eventually make the AppView able to undelete repos, #1130 / bluesky-social/atproto#2806 .

[qazmlp]

I think currently you send a tombstone or something with a status set to deleted, or similar..
There was a great overview of these various state transition messages in a GitHub issue or discussion, but I only saw it on my phone and can't find it anymore.

The gist is that (in my eyes) it'd be good if Bridgy Fed had an option to temporarily deactivate the bridged account without deleting any data – like the 'Deactivate my account' feature in the Bluesky settings that's distinct from deletion:

This is already undoable and would be useful to turn off bridging when full distributed data deletion isn't a strong concern in the moment. The UX difference in this case is that Bluesky would say the account is deactivated, instead of calling it a "Deleted Account" or presenting a not-found page.

Maybe this is also the action that blocking should take, if any, since it's easy to undo.
The action for receiving an account-Delete should still be distributed deletion, of course.

[qazmlp]

On that note (tangentially related), (how) do you translate soft account deactivations and reactivations from ATProto into ActivityPub?

I don't think an account-Delete would work here, as breaking follow-connections would be entirely unexpected. Maybe sending an Update to make the bridge account reasonably locked-down ("approves followers" while rejecting any requests, indexing and discovery off (if otherwise on), clearing out the bio and header/avatar), denying new content fetches and (for enhanced compatibility opportunities) rejecting interaction Activities on the user's objects would work, as that would effectively prevent further spread of the content through the network.

[snarfed]

The gist is that (in my eyes) it'd be good if Bridgy Fed had an option to temporarily deactivate the bridged account without deleting any data – like the 'Deactivate my account' feature in the Bluesky settings that's distinct from deletion:

Ahhh! Yes that's what Bridgy Fed currently does. We're just waiting on Bluesky team to support re-activating accounts in their AppView.

On that note (tangentially related), (how) do you translate soft account deactivations and reactivations from ATProto into ActivityPub?

We just send a new Create with the same actor id as before. We keep the pre-existing followers/followees, so delivery picks back up like brefore. #1130 (comment), #783 (comment)

[qazmlp]

The gist is that (in my eyes) it'd be good if Bridgy Fed had an option to temporarily deactivate the bridged account without deleting any data – like the 'Deactivate my account' feature in the Bluesky settings that's distinct from deletion:

Ahhh! Yes that's what Bridgy Fed currently does. We're just waiting on Bluesky team to support re-activating accounts in their AppView.

Wait, reactivation of deactivated (not tombstoned or deleted!) accounts is already supported though 😕❔
https://bsky.app/profile/safety.bsky.app/post/3ku74woxysv2d See below.

On that note (tangentially related), (how) do you translate soft account deactivations and reactivations from ATProto into ActivityPub?

We just send a new Create with the same actor id as before. We keep the pre-existing followers/followees, so delivery picks back up like brefore. #1130 (comment), #783 (comment)

Delivery to the server may pick back up, but sending a Delete via ActivityPub is a destructive action:
https://github.com/mastodon/mastodon/blob/3e91c101b3c4b5166dab778837e38bed424b4333/app/lib/activitypub/activity/delete.rb#L3-L16
https://github.com/mastodon/mastodon/blob/main/app/services/delete_account_service.rb

Notably, this completely severs follow-relationships:
https://github.com/mastodon/mastodon/blob/main/app/services/delete_account_service.rb#L103-L106

The posts may still go to the federated feed, but the previous followers won't see them in their home timeline.
(No issue with the followees, but that's only because Bridgy Fed is always still following with the @bsky.brid.gy@bsky.brid.gy account.)

This is very much not equivalent to Bluesky's 'deactivation', which is entirely non-destructive.

[snarfed]

Wait, reactivation of deactivated (not tombstoned or deleted!) accounts is already supported though 😕❔

Maybe on the main PDS, but not yet for federated PDSes, bluesky-social/atproto#2806 .

Delivery to the server may pick back up, but sending a Delete via ActivityPub is a destructive action:

True! Apologies, I didn't mean that it had perfect parity with how Bluesky will hopefully be.

[qazmlp]

Wait, reactivation of deactivated (not tombstoned or deleted!) accounts is already supported though 😕❔

Maybe on the main PDS, but not yet for federated PDSes, bluesky-social/atproto#2806 .

Oh, I see. Sorry, I wasn't aware of that specifically (but should have inferred it).
(That is a very strange thing to not have parity on… I wonder what else they shortcut internally.)

Delivery to the server may pick back up, but sending a Delete via ActivityPub is a destructive action:

True! Apologies, I didn't mean that it had perfect parity with how Bluesky will hopefully be.

I'm just wondering if there's a way to get closer to the intent (that doesn't have you send out a ton of Deletes for individual statuses)…

But probably not and failing with lower-than-expected connectivity is indeed the 'safe' option in some ways.
Being able to temporarily close an account would make a good FEP I think (but admittedly I'm not going to write it, and of course don't expect you to). I wonder if current Mastodon would allow feature detection on its inbox in this regard or if it'd just quietly accept and ignore unknown activity types.

[snarfed]

This seems lower priority now that we've switched tombstoning in Bluesky to deactivating instead, #1130 (comment), which can be undone.

[Tamschi]

See #1440 (reply in thread): Mastodon doesn't track delivery of Create-Note activities, so Bridgy Fed should interpret Undo-Accept-Follow targeting the Accept of the Bridge's Follow as request to disable bridging (in order to better avoid desyncs where a bridged status is still present indefinitely while the original was deleted).

[Tamschi]

I think this issue doesn't actually fit the remaining open questions here. I'll file a new one based on #1335 (comment).

(The other parts are either implemented, superseded or tracked elsewhere like in #1293.)