AT: Bridgy ignores reply controls

[qazmlp]

I ended up bridging my Bsky to help test a little more.

I made a post with replies set to "Nobody": https://bsky.app/profile/qazm.bsky.social/post/3ktwdn55s6c27

This resulted in the following bridged JSON at https://bsky.brid.gy/convert/ap/at://did:plc:2shmwstgqmlu4ymg7ctjcdc7/app.bsky.feed.post/3ktwdn55s6c27:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "attributedTo": "https://bsky.brid.gy/ap/did:plc:2shmwstgqmlu4ymg7ctjcdc7",
  "content": "<p>This is a reply-restricted post just for testing.</p>",
  "contentMap": {
    "en": "<p>This is a reply-restricted post just for testing.</p>"
  },
  "content_is_html": true,
  "id": "https://bsky.brid.gy/convert/ap/at://did:plc:2shmwstgqmlu4ymg7ctjcdc7/app.bsky.feed.post/3ktwdn55s6c27",
  "published": "2024-06-02T06:33:45.374Z",
  "to": [
    "https://www.w3.org/ns/activitystreams#Public"
  ],
  "type": "Note",
  "url": "https://bsky.brid.gy/r/https://bsky.app/profile/did:plc:2shmwstgqmlu4ymg7ctjcdc7/post/3ktwdn55s6c27"
}

Note that there's no indication of the reply restriction.

I can reply on Mastodon:

Bridgy appears to send the reply to Bluesky (as my AP account doesn't have bridged web followers, though I can't see the logs):

Bluesky of course mostly rejects this post (also not showing it in the "Replies" tab of the bridged account profile there):

However, curiously enough it did increment the reply count on the post:

---

Why I expected Bridgy to honour the reply restriction:

It appears to be documented to do so.

---

What I expected:

There should be some data in the "Note" object that represents the reply controls. Currently nothing supports that (except maybe Pixelfed, if you use its vocabulary), but if it was there, then apps would at least have a chance to offer rich UX there.

Ideally, the post content should also have some (small!) indication that replies are disallowed or limited, at least when fetched by instances where you can't be sure they support the reply restrictions. This could take the form of a custom emoji similar to this mockup:

I don't care too much about the reply count being incremented, that's probably something the Bluesky frontend should handle anyway. (I'll file this as a bug there.)

[snarfed]

Hmm! Thanks for filing. So, this is the expected behavior right now. As you mention:

Bluesky of course rejects this post completely (also not showing it in the "Replies" tab of the bridged account profile there)

In other words, the reply restrictions still work inside Bluesky, in the sense that bridged fediverse replies aren't accepted by Bluesky and don't show up on the post.

I tried to word the docs carefully to describe this, but you're right, I should probably add language to them to say that fediverse users will still be able to reply, those replies just won't show up in Bluesky.

I could put something into a custom field in the AS2 object, but as you mention, it would have no effect. In general, I don't really plan to try to drive new functionality or standards-track data formats in BF. My goal is to follow existing specs and de facto standards. If either of those emerges for reply restrictions in the fediverse, I'll happily follow!

[jfietkau]

On that note: there's FEP-5624 (discussion here, and lots of it) for reply control, but I'm not sure if it's fully implemented anywhere. The Mastodon project has reply control on its roadmap as MAS-37 and the FEP author is a Mastodon core team member, so the eventual Mastodon implementation may look a lot like what's suggested there. But of course anything about it could change until then.

[snarfed]

Added this to the reply controls section:

The fediverse itself doesn't have reply controls, so if you bridge your Bluesky account and post with reply controls, people in the fediverse will still be able to reply, but those replies won't show up in Bluesky.

[qazmlp]

Oh, this is interesting: Bluesky actually didn't reject the post completely. It's visible at https://bsky.app/profile/Qazm.tiggi.es.ap.brid.gy/post/3ktwec555a2w2 and turned up in a search for to:me. It's detached both ways and did not notify me, though.

[qazmlp]

GoToSocial now has Interaction Policies that are a superset of this (and really good ActivityPub docs in general 👀).

You may have to support Following Collections to an extent, but considering GoToSocial allows users to serve a stub instead, it's most likely that it matches these with policies by collection ID (which is what I would suggest here to map them to their Bluesky equivalents).

Note that GoToSocial is still BETA software, and that this is a pre-release as of right now, technically, but I think it's worth keeping an eye on. The software behaves roughly the same as Bluesky, (silently?) dropping any interactions that don't conform to the Interaction Policy.