Comment un threadgate de Bluesky décide qui peut répondre à un post

Qu'est-ce qu'un threadgate de Bluesky ?

Un threadgate de Bluesky est le record app.bsky.feed.threadgate qui décide qui peut répondre à un fil. Le lexicon le décrit comme un « Record defining interaction gating rules for a thread (aka, reply controls). » Sur Bluesky, les contrôles de réponse ne sont ni un réglage de votre compte ni un indicateur sur le post. Ce sont ce record, stocké dans votre propre dépôt.

C'est un record à part entière, pas un champ du post. Cette conception a une conséquence que beaucoup ratent : vous pouvez ajouter, modifier ou supprimer les contrôles de réponse d'un post déjà en ligne, parce que le record du post lui-même ne change jamais.

Le lexicon fixe l'endroit où le record doit se trouver : « The record key (rkey) of the threadgate record must match the record key of the thread's root post, and that record must be in the same repository. » Un threadgate appartient à un post racine, dans le dépôt de l'auteur, sous la même rkey.

Quels champs contient le record threadgate ?

Quatre, dont deux obligatoires.

Un record complet qui laisse répondre les comptes mentionnés et une liste ressemble à ceci :

{
  "$type": "app.bsky.feed.threadgate",
  "post": "at://did:plc:abc123/app.bsky.feed.post/3kxyzpost",
  "allow": [
    { "$type": "app.bsky.feed.threadgate#mentionRule" },
    {
      "$type": "app.bsky.feed.threadgate#listRule",
      "list": "at://did:plc:abc123/app.bsky.graph.list/3kxyzlist"
    }
  ],
  "createdAt": "2026-09-24T10:00:00.000Z"
}

Vous l'écrivez avec com.atproto.repo.createRecord, en réglant collection sur app.bsky.feed.threadgate et rkey sur la rkey du post, qui est le dernier segment de l'AT-URI du post. La page de Bluesky sur les thread gates montre la même étape dans son exemple TypeScript : const { rkey } = new AtUri(postUri).

Quelles règles allow un threadgate de Bluesky peut-il utiliser ?

Quatre types de règles, chacune étant un objet dans allow. La documentation de Bluesky les liste avec une définition d'une ligne :

Trois des quatre n'ont aucune propriété. listRule est l'exception : son champ list est obligatoire et prend l'AT-URI d'un record app.bsky.graph.list.

Les règles s'additionnent au lieu de se restreindre. L'exemple de Bluesky place mentionRule, followingRule et listRule dans un même tableau avec les commentaires « allow mentioned users », « allow followed users » et « allow list members », donc chaque règle ouvre les réponses à un groupe de plus.

mentionRule dépend de la façon dont le post encode ses mentions. Dans un record de post, une mention est une facet app.bsky.richtext.facet#mention, et le lexicon des facets précise que « The text is usually a handle, including a '@' prefix, but the facet reference is a DID. » Taper un @handle en texte brut sans facet n'en fait pas une mention dans le record. Obtenir les bons décalages en octets pour la facet est un problème à part, traité dans la note sur byteStart et byteEnd dans les facets Bluesky.

Le tableau allow plafonne à 5 éléments alors qu'il n'existe que quatre types de règles. Le schéma n'interdit pas de répéter listRule, donc le cinquième emplacement laisse la place à une seconde liste.

Quelle différence entre un tableau allow vide et un tableau absent ?

Toute la différence. Le lexicon trace la limite en une phrase : « If value is an empty array, no one can reply. If value is undefined, anyone can reply. »

La documentation de Bluesky formule cela au niveau du record : « If a thread gate record is present but empty, then nobody can reply, » et « If a thread gate record is not present, then anybody can reply. » Lisez les deux sources ensemble et un cas apparaît que la page de documentation passe sous silence. Un record threadgate peut exister sans champ allow, par exemple un record qui ne liste que des hiddenReplies. Selon la formulation du lexicon, ce fil reste ouvert à tout le monde. Si votre code masque une réponse en créant un threadgate, et que quelqu'un lit ensuite « record présent signifie fil restreint », il inversera la logique.

Peut-on restreindre les réponses au milieu d'un fil ?

Non. La rkey du threadgate doit correspondre à « the thread's root post », donc il y a un threadgate par fil, rattaché à son premier post. Les réponses plus bas dans le fil ne peuvent pas porter leurs propres contrôles de réponse.

Le tableau hiddenReplies se trouve sur le même record racine, et il plafonne à 300 URI. L'annonce de la fonctionnalité par Bluesky, dans la version 1.90 de l'application, indique « Only the original creator of the thread can hide replies, » et que « All hidden replies will be placed behind a Hidden replies screen. » Elles y restent accessibles, « but much less visible. » La même annonce prévient que les réponses masquées, ainsi que les posts que l'auteur a masqués, « are still public data. » Tout ce qui figure dans un record threadgate est lisible par quiconque lit votre dépôt.

Qu'est-ce que le record postgate ?

Le postgate est l'équivalent du threadgate pour les citations. app.bsky.feed.postgate est un « Record defining interaction rules for a post », et il suit la même règle d'emplacement : sa rkey « must match the record key of the post, and that record must be in the same repository. »

embeddingRules n'a aujourd'hui qu'un seul type de règle, app.bsky.feed.postgate#disableRule, décrit comme « Disables embedding of this post. » C'est l'interrupteur qui désactive les citations.

Notez que les valeurs par défaut du postgate diffèrent de celles du threadgate. Pour embeddingRules, « If value is an empty array or is undefined, no particular rules apply and anyone can embed. » Un tableau vide bloque les réponses dans un threadgate mais laisse les citations ouvertes dans un postgate. Pour bloquer les citations, il faut une disableRule explicite.

Le postgate diffère aussi par sa portée. Il correspond à « the record key of the post », pas à la racine du fil, donc n'importe quel post, y compris une réponse, peut porter son propre postgate.

detachedEmbeddingUris enregistre les citations dont vous vous êtes déjà détaché. L'annonce 1.90 de Bluesky le décrit ainsi : « you can detach your original post from someone's quote post, » et « Like blocks, quote post removals are public data. » Le tableau contient 50 URI.

Comment un client sait-il qu'un post est restreint ?

Par la vue du post, pas en récupérant les records. app.bsky.feed.defs#postView contient un champ threadgate qui renvoie le record avec les listes qu'il référence. L'état du viewer pour le compte connecté ajoute deux booléens, replyDisabled et embeddingDisabled, qu'un client peut utiliser pour griser les boutons de réponse et de citation pour cette personne.

Un outil de planification a une étape de plus. Le threadgate est un second record, donc un post programmé avec des contrôles de réponse implique deux écritures : le post, puis le gate sous la même rkey. La note sur comment programmer des posts Bluesky couvre la partie publication, et les deux écritures comptent dans les limites décrites dans la note sur la limite de taux de l'API Bluesky.

Questions fréquentes

Comment empêcher tout le monde de répondre à un post Bluesky via l'API ?

Créez un record app.bsky.feed.threadgate avec la rkey du post et "allow": []. Le lexicon indique « If value is an empty array, no one can reply. »

Un threadgate de Bluesky peut-il n'autoriser que mes abonnés à répondre ?

Oui. Ajoutez app.bsky.feed.threadgate#followerRule à allow. Bluesky la définit comme « Allow replies from actors following you. »

Combien de règles un threadgate peut-il contenir ?

Cinq. Le tableau allow a un maxLength de 5 dans le lexicon.

Puis-je modifier les contrôles de réponse après la publication d'un post ?

Oui. Le threadgate est un record distinct, donc vous pouvez le créer, le modifier ou le supprimer sans toucher au post lui-même.

Comment désactiver les citations sur Bluesky via l'API ?

Créez un record app.bsky.feed.postgate avec la rkey du post et ajoutez app.bsky.feed.postgate#disableRule à embeddingRules. Un tableau vide ne bloque pas les citations.

Les réponses masquées sont-elles privées ?

Non. Bluesky indique que les réponses masquées, et les posts que l'auteur a masqués, « are still public data. » Elles se trouvent dans le tableau hiddenReplies du threadgate, que tout le monde peut lire.

Qui peut masquer des réponses dans un fil Bluesky ?

Seul le créateur d'origine du fil peut masquer des réponses, d'après l'annonce de Bluesky pour la version 1.90. Les URI des réponses masquées vont dans le tableau hiddenReplies du threadgate, jusqu'à 300. Elles restent derrière un écran Hidden replies et y sont toujours accessibles.

Un tableau embeddingRules vide désactive-t-il les citations ?

Non, il ne le fait pas. Dans un postgate, un embeddingRules vide ou non défini signifie qu'aucune règle particulière ne s'applique et que tout le monde peut intégrer le post. Pour bloquer les citations, ajoutez app.bsky.feed.postgate#disableRule.

Comment détacher une citation de mon post d'origine sur Bluesky ?

Ajoutez l'AT-URI de la citation au tableau detachedEmbeddingUris du postgate de votre post. Le tableau contient jusqu'à 50 URI. Bluesky précise que, comme les blocages, les retraits de citations sont des données publiques.

Un threadgate peut-il combiner plusieurs règles allow ?

Les règles s'additionnent. Chaque règle de allow ouvre les réponses à un groupe de plus, donc les comptes mentionnés, les comptes suivis et une liste peuvent figurer dans le même tableau. Le tableau accepte jusqu'à 5 règles, et listRule demande l'AT-URI d'un record app.bsky.graph.list.