Undo account deletion (blocked on Bluesky)

[snarfed]

Right now, blocking the bridge bot account disables the bridge for you and deletes your bridged account. That's almost too easy, and right now it can't be undone, which is unfortunate. We should allow undeleting! Background in #783

[lupomancer]

In an ideal world where this is solved, would this allow for blocking and unblocking from both Mastodon and Bluesky?

If, say, I want to delete my bridged mastodon -> BSKY account for the time being to avoid confusion, would I later be able to follow the bridger and recreate it?

Additionally, were I to delete my bridged BSKY -> Mastodon account, changed my BSKY handle, and then refollowed, would it create an account with the new BSKY handle? I know this may be blocked by that annoying AP username issue outlined in #1074

[snarfed]

Blocking and unblocking to recreate the bridged account is definitely the goal!

Handle changes are a separate question, you're right, #1074 tracks that.

[qazmlp]

For what it's worth, once this here is implemented, then the handle change should be reflected in Mastodon this way, at least if you wait a few hours between actions.

You'd still lose all your fediverse connections, but your follows could in theory be re-synchronised. (#1102)
Not your followers though, they'd be lost permanently when doing this.

[snarfed]

Not sure I follow, but if you mean that deleting and recreating bridged accounts like this this should give us Bluesky => fediverse handle changes for free, I don't think so. Background in #1074 (comment) .

TLDR is that the actor id itself wouldn't change, and right now it's unclear how broadly the fediverse currently supports either 1) changing an actor's username while keeping its id the same or 2) deleting and recreating an actor with the same id. Both probably need some testing in the wild.

[qazmlp]

For Mastodon specifically, I think it uses WebFinger existence to check whether to keep an account alive regarding a cleanup job.

But you're right, while I don't see a uniqueness constraint on the actor id, it's definitely possible that some part of it would glitch out.

[snarfed]

Looks like this is already working for Bluesky => fediverse! jglypt on Bluesky blocked @ap.brid.gy at 2024-06-21T22:47:15.283184Z, and we disabled his account and sent out Deletes for his AP actor (see below). He then unblocked and re-followed it at 2024-06-22T13:14:02Z, and fediverse instances were able to see his actor again. Posts before the block aren't visible, but posts after it are.

{
  "id": "https://bsky.brid.gy/convert/ap/did:plc:4hawmtgzjx3vclfyphbhfn7v#delete-copy-activitypub-2024-06-21T22:47:15.283184+00:00",
  "actor": "https://bsky.brid.gy/ap/did:plc:4hawmtgzjx3vclfyphbhfn7v",
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Delete",
  "object": "https://bsky.brid.gy/ap/did:plc:4hawmtgzjx3vclfyphbhfn7v",
  "to": ["https://www.w3.org/ns/activitystreams#Public"]
}

We weren't sure, if we Deleted an actor in AP with a given id, whether we could later recreate that actor with the same id. Our next step was to test it (#783 (comment)). Thanks Jack for doing that test for us!

[snarfed]

So, fediverse => Bluesky is the remaining one here.

[snarfed]

...specifically, the remaining work for fediverse => Bluesky here is to figure out how to reactivate an ATProto repo that has been tombstoned: bluesky-social/atproto#2503 (reply in thread) . Related: #1119, bluesky-social/atproto#2592 . cc @lupomancer

[snarfed]

Hmm. I tried undelete a tombstoned repo (snarfed.org.web.brid.gy / did:plc:vzxheqfwpbi3lxbgdh22js66) by emitting an #account event with "active": True, but no luck. https://bsky.app/profile/snarfed.org.web.brid.gy still says Profile not found.

{
  "op": 1,
  "t": "#account"
}
{
  "did": "did:plc:vzxheqfwpbi3lxbgdh22js66",
  "seq": 1131666,
  "time": "2024-07-16T20:26:56.540365+00:00",
  "active": true
}

[snarfed]

Asked @bnewbold about this ^ in https://bsky.app/profile/snarfed.org/post/3kxgh6bl6lu2j , haven't heard back yet.

[snarfed]

Heard back that #identity + #account should do the trick!

...except that doesn't seem to work yet. I emitted the two events below over BF's firehose just now, and got them back from the relay's firehose intact, but https://bsky.app/profile/snarfed.org.web.brid.gy still says Profile not found. https://enoki.us-east.host.bsky.network/xrpc/app.bsky.actor.getProfile?actor=did:plc:vzxheqfwpbi3lxbgdh22js66 returns 400 with the same error, as does the same call on api.bsky.app. BF hasn't received any getRepo calls for this DID recently.

@bnewbold any thoughts? could this be a bug in the Bluesky relay or appview or nearby?

{"op": 1, "t": "#identity"}
{
  "did": "did:plc:vzxheqfwpbi3lxbgdh22js66",
  "seq": 1221600,
  "time": "2024-07-24T17:02:27.223965+00:00",
  "handle": "snarfed.org.web.brid.gy"
}

{"op": 1, "t": "#account"}
{
  "did": "did:plc:vzxheqfwpbi3lxbgdh22js66",
  "seq": 1221601,
  "time": "2024-07-24T17:02:28.151528+00:00",
  "active": true
}

[snarfed]

TODO for me for when this does work: https://indieweb.social/@hcj@fosstodon.org/112514598862207483

[snarfed]

Bad news, evidently Bluesky doesn't support deleting repos after all, at least not yet: https://bsky.app/profile/bnewbold.net/post/3kzmg32tokt2r . Ah well. Maybe eventually!

[snarfed]

Breakthrough! bluesky-social/atproto#2806 (comment) led me to try deactivating with #account instead of #tombstone, which works, and can be undone! Specifically with active: false, status: deactivated and then active: true. Exciting!

[derspyy]

wow!!

imagining we still wouldn't be able to undo the deletion if it's already been done

[snarfed]

Right. I'll probably be able to do it manually, eventually, but probably by creating a new bridged account, not reviving your old one.

[derspyy]

if you wanted to try 👉👈

https://fed.brid.gy/ap/@piuvas@capivarinha.club

[snarfed]

Shipped this, it's live! Tested with https://bsky.app/profile/snarfed.mas.to.ap.brid.gy , blocking deactivated it, and then unblocking and re-following brought it back again, including its posts.

[snarfed]

Started figuring out how to bring back old tombstoned Bluesky repos by recreating them as new repos. Recreating the repos works fine, but oddly I can't get them to emit the new app.bsky.actor.profile/self record that gets created. Example: https://bsky.app/profile/piuvas.capivarinha.club.ap.brid.gy .

Here's the repl code I'm using:

a = ActivityPub.query(ActivityPub.handle == '...').get()
a.copies = []
a.obj.copies = []
a.put()
ATProto.create_for(a)

The record gets created and stored in the repo fine, but we never emit it over our firehose. In this example, it's seq 2929703, and we emitted seq 2929703 and then seq 2929704.

I suspect this is because we're not allocating sequence numbers and writing blocks in the same transaction. If we allocates a seq for the new repo's initial commit, and then another commit allocates the next seq and writes its commit, and our firehose reads it, before we write ours, our firehose will skip our commit entirely. And I'm more likely to trigger that when I do this kind of manual change locally, outside GCP, because of the network distance.

Ugh.

[derspyy]

Started figuring out how to bring back old tombstoned Bluesky repos by recreating them as new repos. Recreating the repos works fine, but oddly I can't get them to emit the new app.bsky.actor.profile/self record that gets created. Example: https://bsky.app/profile/piuvas.capivarinha.club.ap.brid.gy .

Here's the repl code I'm using:

a = ActivityPub.query(ActivityPub.handle == '...').get()
a.copies = []
a.obj.copies = []
a.put()
ATProto.create_for(a)

The record gets created and stored in the repo fine, but we never emit it over our firehose. In this example, it's seq 2929703, and we emitted seq 2929703 and then seq 2929704.

I suspect this is because we're not allocating sequence numbers and writing blocks in the same transaction. If we allocates a seq for the new repo's initial commit, and then another commit allocates the next seq and writes its commit, and ouir firehose reads it, before we write ours, our firehose will skip our commit entirely. And I'm more likely to trigger that when I do this kind of manual change locally, outside GCP, because of the network distance.

Ugh.

if you refresh, my account actually did forward a post.

no avatar though, but if i try reuploading it... maybe?

[derspyy]

just noticed i have no display name and no bio, so it isn't the previous bug. my bad...

[snarfed]

Right, no display name or bio is what I mentioned in #1130 (comment) .

@derspyy I'm trying something else. Could you unfollow @bsky.brid.gy@bsky.brid.gy and then follow again?

[derspyy]

yup, doing it
(btw, is bridgy fed sending a follow Accept when someone follows the acct? on sharkey the follow action is just spinning forever)

[Tamschi]

It is, but Misskey incorrectly requires activity @ids to be on the same domain as the signing user.
I believe Bridgy Fed currently places Follow-Accept activities on fed.brid.gy while the actor is on bsky.brid.gy.

More details here: #1093 (comment)

[derspyy]

yup, doing it
(btw, is bridgy fed sending a follow Accept when someone follows the acct? on sharkey the follow action is just spinning forever)

seems like the bridge acct isn't following me back :/

[snarfed]

@derspyy sorry about that, my fault. Try again now? (And thanks for your patience!)

[derspyy]

@derspyy sorry about that, my fault. Try again now? (And thanks for your patience!)

(no worries! wish i knew enough about atproto to help you 😭)

looks the same, though

[snarfed]

Thanks for trying @derspyy. Looks like this is still snarfed/arroba#34. Argh. I'll need to work on that soon.

[snarfed]

It is, but Misskey incorrectly requires activity @ids to be on the same domain as the signing user.
I believe Bridgy Fed currently places Follow-Accept activities on fed.brid.gy while the actor is on bsky.brid,.gy.

This is a good point, thanks for the nudge. Follows are always on bsky.brid.gy, and I think they always were - not sure - but you're right that Accepts are still on fed.brid.gy. I'll go nudge #1093 and track there.