Applications et API

Une nouvelle route notes/context renvoie les réponses situées au-dessus et en dessous d’une publication, dans l’ordre de la conversation, avec les mêmes limites que Mastodon. Elle alimente l’affichage des conversations des applications Mastodon ; les vues de conversation propres à Catodon ne l’utilisent pas.

Chaque envoi d’un webhook doté d’un secret porte désormais un en-tête X-Catodon-Signature, un HMAC-SHA256 d’un horodatage et du corps, calculé avec ce secret, pour que le récepteur puisse vérifier qu’il vient bien de votre instance et qu’il est récent. Les webhooks créés sans secret en reçoivent désormais un aléatoire, et X-Misskey-Hook-Secret, qui envoie le secret lui-même, est déprécié et sera retiré dans la 27.1.0.

Les webhooks de compte et les webhooks système listent désormais leurs 30 dernières tentatives d’envoi : quand, pour quel événement, le statut HTTP ou la raison de l’absence de réponse, et la durée. Un bouton Renvoyer relance un envoi perdu pendant que votre récepteur était hors service, même quand le webhook est désactivé, en gardant son eventId pour que le récepteur puisse le reconnaître. Le journal se lit aussi par i/webhooks/deliveries et admin/system-webhook/deliveries.

Un webhook qui échoue à livrer 10 événements d’affilée, le premier au moins une heure plus tôt, est désormais désactivé au lieu d’être envoyé indéfiniment vers une adresse morte, et son ou sa propriétaire est prévenu·e : le compte, ou chaque modérateur·ice et administrateur·ice pour un webhook système. Seuls comptent les événements qui ont épuisé toutes leurs tentatives, si bien qu’une courte panne ne change rien, et le webhook peut être réactivé une fois son récepteur rétabli.

Deux choses les en empêchaient : le jeton que Catodon fournissait ne portait pas un champ exigé par l’application, et une application qui ne demande aucun accès particulier ne pouvait que lire. Les deux sont corrigées, et une telle application propose désormais un choix entre lecture seule et lecture et écriture lors de l’autorisation.

Les applications Mastodon peuvent programmer des publications via l’API Mastodon.

Tusky, Pachli, Ice Cubes et les autres applications Mastodon peuvent désormais s’inscrire aux notifications push : elles apprennent chaque nouvelle notification aussitôt, au lieu de vérifier toutes les 15 minutes ou de ne rien recevoir une fois fermées. Les types de notification demandés par l’application et son réglage « de qui » sont respectés, et révoquer l’accès d’une application supprime son abonnement. Le tout s’appuie sur les réglages Web Push existants de l’instance.

Les instances publient des Digital Asset Links, ce qui permet à l’application Android de Catodon de vérifier leur domaine.

Les routes de filtres de Mastodon lisent et écrivent désormais les mêmes filtres que l’écran de paramètres affiche, si bien qu’un filtre créé dans Tusky est celui qui s’affiche ici, et inversement. Jusqu’ici, ce qu’un client Mastodon réglait était mémorisé par jeton d’accès et ne filtrait absolument rien.

La route de traduction de Mastodon répond désormais depuis le traducteur que l’instance utilise déjà pour ses propres publications, et l’instance annonce la fonctionnalité et les langues vers lesquelles elle traduit, si bien que Tusky propose son bouton de traduction dès qu’il voit le drapeau.

Sur une route qui exige des identifiants et prend un fichier, l’identifiant doit désormais précéder le fichier dans le corps multipart. Le corps entier était auparavant collecté en premier, ce qui voulait dire écrire tout un envoi sur le disque avant même de savoir si l’expéditeur·rice était autorisé·e à l’envoyer.

Catodon a toujours eu « Masquer du flux Accueil » sur une liste, mais sa sortie Mastodon l’ignorait : le champ était signalé comme inconnu et abandonné quand un client tentait de le régler. Les clients tiers voient et modifient désormais la même chose qu’un compte Catodon.

Elles ont toujours été enregistrées et fédérées dans les deux sens ; rien ne les relisait. Les deux API les renvoient désormais partout où le compte est le sujet de la requête, et la route de mise à jour Mastodon les écrit sur les images nommées dans le même appel. Le client web ne les affiche ni ne les modifie encore.

Une application qui propose de créer un compte, comme celle de Mastodon, peut désormais le faire sur une instance Catodon par la route POST /api/v1/accounts de Mastodon, en suivant toutes les règles du formulaire de l’instance : invitations, approbation, vérification de l’adresse e-mail, âge minimum et noms d’utilisateur réservés. Chaque refus est signalé sur son champ. Une instance dotée d’un captcha refuse les inscriptions depuis les applications, et celles-ci sont limitées en débit par adresse IP et par application.

Une application peut se connecter sans rien avoir enregistré au préalable : elle est identifiée par une adresse web qui la décrit et se prouve avec PKCE ; la page de consentement affiche son nom et son icône. Les applications qui utilisent l’API client-serveur d’ActivityPub peuvent alors publier, suivre, réagir, lire le flux Accueil et plus encore, par l’outbox du compte. C’est activé par défaut ; Administration → Fédération → Politique désactive l’API client ActivityPub.

La nouvelle route notes/thread renvoie en une seule requête les réponses à une publication sur plusieurs niveaux, sous forme de liste à plat où chaque réponse indique son parent, avec un curseur partout où il reste des réponses. Elle trie par pertinence, des plus anciennes ou des plus récentes à chaque niveau, accepte des limites de taille, et écarte les réponses que vous ne pouvez pas voir ainsi que tout ce qui se trouve en dessous.

La nouvelle route notes/followed-hashtags renvoie, pour chaque hashtag auquel vous êtes abonné·e, sa publication publique la plus récente, de la plus récente à la plus ancienne, avec les mêmes filtres et la même pagination que notes/following. Les publications des comptes et des instances mis en sourdine, bloqués ou suspendus, et celles qui portent un hashtag que vous avez bloqué, sont écartées.

Trois champs de forum que l’instance envoyait déjà, à savoir si un forum est réservé aux adultes et deux restrictions sur qui peut y publier, sont désormais déclarés dans la description de l’API, et les types misskey-js générés suivent. Rien de ce que l’instance envoie ne change.

Pour les applications, notes/bubble-timeline accepte désormais les mêmes options que notes/global-timeline : les tris Populaires et Actives, et des interrupteurs pour les réponses et les publications de forum, chacun réglé par défaut sur ce que renvoyait le flux Recommandé jusqu’ici. Le flux Recommandé écarte aussi désormais les réponses aux publications réservées aux abonné·es dont vous ne suivez pas l’auteur·ice, comme le flux public.