How are reply restrictions handled?

[qazmlp]

I didn't see this in the docs, so I thought I'd ask.

Bsky supports reply permissions now (all, none, followers and/or mentioned). While it's possible to represent some of this in AP using Pixelfed vocabulary, this is not well-supported, so that most instances ignore the restriction outright.

(I don't know how Bsky behaves, but I assume that it and Pixelfed will discard disallowed replies locally. That's still a context breakdown though.)

It would be sort-of possible to map this one way (except strictly followers-only) using visibilities, but then that wouldn't safely translate back so it doesn't look like an option to me.

[snarfed]

Good question!

At a basic level, I expect Bluesky reply restrictions will behave like any network-specific feature that doesn't have an equivalent in other networks: it'll work fine inside Bluesky, including with bridged users, but it won't apply outside Bluesky.

Specifically, I expect you're right about the details: a fediverse user will be able to use BF to reply to a Bluesky post with reply restrictions, and that reply will be visible in the fediverse, but it won't be visible in Bluesky. I'm guessing this is the "context breakdown" you mentioned?

Practically speaking, without widespread adoption of reply restrictions in the fediverse, I don't know that BF can do much about this. BF can't prevent people from replying in the fediverse. If those replies violate reply restrictions, BF could drop the replies itself, or it could bridge them and let Bluesky drop them, but the effect is the same either way.

Thanks for raising the question. I'm open to ideas!

[snarfed]

Regardless, you're right that this is worth adding to the docs. I've filed #956 for that.

[qazmlp]

It would be good to have the meta data attached in some form still, where it differs from allow-all. Iff there's no established matching semantics elsewhere, you could add a namespaced field yourself.
(I can't find any information on how this is represented in ATProto. Pixelfed only supports https://www.w3.org/ns/activitystreams#Public and NULL as capability receivers. Mastodon's synchronised collections would be a natural extension of the semantics, but unless you can union those it wouldn't seem feasible to do this per post. Something like

{
    "@context": [
        "https://www.w3.org/ns/activitystreams",
        {
            "bridgy": "http://brid.gy/ns#", // Do you have a custom namespace already?
            "canReply": { // Very unsure about the structure here.
                "@id": "bridgy:canReply",
                "@container": "@set",
                "@type": "@id"
            },
        }
    ],
    "id": "…",
    "type": "Note",
    "content": "…",
    "canReply": [ "id-of-synchronised-followers-Collection", "id-of-first-Actor-mentioned", …]
}

is probably what I would guess would be a sensible way to represent this in JSON-LD?
I have no idea how many softwares actually do proper JSON-LD-processing, and it's probably not many considering the issues you had with embedded object sending.

I think the inline form of this is

{
    "@context": [
        "https://www.w3.org/ns/activitystreams",
    ],
    "id": "…",
    "type": "Note",
    "content": "…",
    "https://brid.gy/ns#canReply": {
        "@set": [ "id-of-synchronised-followers-Collection", "id-of-first-Actor-mentioned", …]
    }
}

, which also seems like a good way to do this more concisely. (I'll be frank though, I haven't got a clue how JSON-LD actually works, so massive rocks of salt on anything here. I'm sure there's a proper validator/transformer for this somewhere.)

In any case, if you do (a correct version of) this, it would be easy for compatible-ish software to parse this and map it onto their internal representation on their own terms, at least. Maybe not Mastodon, but I think @dansup might want to parse this if you don't attach Pixelfed capabilities, and you could easily map Pixelfed capabilities onto this.

(I hope the ping is okay. I'm aware you're very busy with PubKit right now, so this is very much just a "would probably like to know of this" nudge.)

---

As a stopgap measure, you could carefully render a (vertically separated?) line with :replies-not-delivered: or (:followers-can-reply: and/or :mentioned-can-reply:) custom emojis into the post body to indicate the restriction. The names are important, as they're used as alt text and also surfaced generally on mouse-over and if the custom emoji isn't available for whatever reason.

The instance I'm on has these to indicate boost preferences:
I think similar designs for replies would be easily understood, especially if their names are self-explanatory, but please keep the names short.

'carefully' because Mastodon has a nicer UI for e.g. hashtags that appear as the last line of a status without other content, and it would be good to preserve that where possible.

---

Regarding Bridgy's behaviour, I think it would be good if you ignored these replies completely, ideally rejecting them outright with a 403 Forbidden on receipt, as that most closely matches the original post's author's intention.

It may not make a difference on Bsky, and Mastodon may not recognise the rejection well, but in terms of ActivityPub it would still make a difference to not spread them through a Note's "replies" Collection, and also to not have them appear through any web-side representations you may have of the post.
(You may want to add a "reply to <post> rejected due to reply permission limit" entry to the public debug log without rendering the reply object there, if that would be useful, maybe linking to the relevant part of the bridge docs.)

You could also send back a DM-reply to the rejected reply if someone @-mentions the original author who imposed the restriction, but I don't think that's really necessary if you have the emojis.