Apps und API

Ein neuer Endpunkt notes/context liefert die Antworten oberhalb und unterhalb eines Beitrags in Thread-Reihenfolge, innerhalb derselben Grenzen wie bei Mastodon. Er speist die Thread-Ansicht von Mastodon-Apps; die eigenen Thread-Ansichten von Catodon verwenden ihn nicht.

Eine App, die anbietet, ein Konto zu erstellen, etwa die von Mastodon selbst, kann das nun auf einem Catodon-Server über Mastodons POST /api/v1/accounts tun und beachtet dabei jede Regel des eigenen Formulars des Servers: Einladungen, Freigabe, E-Mail-Bestätigung, Mindestalter und reservierte Benutzernamen. Jede Ablehnung wird dem jeweiligen Feld zugeordnet. Ein Server mit Captcha lehnt Registrierungen aus Apps ab, und App-Registrierungen sind pro IP-Adresse und pro App ratenbegrenzt.

Zwei Dinge hielten sie davon ab: Dem von Catodon ausgehändigten Token fehlte ein Feld, auf dem die App bestand, und eine App, die keinen bestimmten Zugriff anfordert, konnte nur lesen. Beides ist behoben, und eine solche App lässt Sie bei der Autorisierung jetzt zwischen „nur lesen“ und „lesen und schreiben“ wählen.

Mastodon-Apps können Beiträge über die Mastodon-API planen.

Server veröffentlichen Digital Asset Links, damit die Catodon-Android-App ihre Domain verifizieren kann.

Die Mastodon-Filterrouten lesen und schreiben jetzt genau die Filter, die der Einstellungsbildschirm zeigt, sodass ein in Tusky erstellter derselbe ist, der hier angezeigt wird, und umgekehrt. Bisher wurde das, was ein Mastodon-Client einstellte, pro Zugriffstoken gemerkt und filterte gar nichts.

Der neue Endpunkt notes/thread liefert die Antworten unter einem Beitrag in einer einzigen Anfrage über mehrere Ebenen, als flache Liste, in der jede Antwort ihren Elternbeitrag nennt, mit einem Cursor überall dort, wo weitere Antworten folgen. Er sortiert auf jeder Ebene nach Beliebtheit, ältesten oder neuesten, nimmt Grenzen für seine Größe entgegen und lässt Antworten, die Sie nicht sehen können, samt allem darunter weg.

Der neue Endpunkt notes/followed-hashtags liefert für jeden Hashtag, dem Sie folgen, seinen neuesten öffentlichen Beitrag, den neuesten zuerst, mit denselben Filtern und derselben Seitenaufteilung wie notes/following. Beiträge von stummgeschalteten, blockierten oder gesperrten Konten und Servern sowie Beiträge mit einem von Ihnen blockierten Hashtag werden weggelassen.

Die Mastodon-Übersetzungsroute antwortet jetzt vom Übersetzer, den der Server bereits für seine eigenen Beiträge verwendet, und der Server kündigt die Funktion und die Sprachen an, in die er übersetzt, sodass Tusky seine Übersetzen-Schaltfläche anbietet, sobald es das Flag sieht.

Bei einem Endpunkt, der Zugangsdaten verlangt und eine Datei entgegennimmt, muss das Zugangsdatum im Multipart-Body vor der Datei stehen. Früher wurde der gesamte Body zuerst eingesammelt, was bedeutete, einen kompletten Upload auf die Festplatte zu schreiben, bevor feststand, ob der Absender ihn überhaupt senden durfte.

Catodon bietet bei einer Liste seit jeher „Von der Startseite ausblenden“, doch seine Mastodon-Ausgabe ignorierte es: Das Feld wurde als unbekannt gemeldet und verworfen, wenn ein Client es setzen wollte. Clients anderer Anbieter sehen und ändern jetzt dasselbe wie ein Catodon-Konto.

Sie wurden schon immer gespeichert und in beide Richtungen föderiert; nichts las sie wieder aus. Beide APIs melden sie jetzt überall, wo das Konto Gegenstand der Anfrage ist, und die Mastodon-Update-Route schreibt sie auf die im selben Aufruf genannten Bilder. Der Web-Client zeigt oder bearbeitet sie noch nicht.

Für Apps nimmt notes/bubble-timeline nun dieselben Optionen wie notes/global-timeline: Sortierung nach „Beliebt“ und „Aktiv“ sowie Schalter für Antworten und Forenbeiträge, jeweils mit dem als Standard, was Empfohlen bisher lieferte. Empfohlen lässt nun auch Antworten auf Beiträge nur für Follower von Autoren weg, denen Sie nicht folgen, wie es Global tut.

Eine App kann sich anmelden, ohne vorher registriert zu sein, identifiziert durch eine Webadresse, die sie beschreibt, und sich per PKCE ausweisend; die Zustimmungsseite zeigt ihren Namen und ihr Symbol. Apps, die die ActivityPub-Client-zu-Server-API verwenden, können dann über die Outbox des Kontos posten, folgen, reagieren, die Startseiten-Chronik lesen und mehr. Sie ist standardmäßig aktiviert, und unter Systemsteuerung → Föderation → Richtlinie lässt sich die ActivityPub-Client-API ausschalten.

Drei Forenfelder, die der Server bereits sendete – ob ein Forum für Erwachsene ist und zwei Einschränkungen, wer posten darf –, sind jetzt in der API-Beschreibung deklariert, und die generierten misskey-js-Typen folgen. Nichts von dem, was der Server sendet, ändert sich.

admin/user-lists/ensure-proxy-follows ist für Administratoren gedacht: Der Endpunkt findet die entfernten Konten, die in irgendeiner Liste stehen und denen kein lokales Konto folgt, und lässt das Proxy-Konto ihnen folgen. So bleiben Listenmitglieder, die hinzugefügt wurden, während das Proxy-Konto ausgeschaltet war, nicht länger stumm. Mit dryRun: true listet er sie nur auf, und jeder Lauf wird im Moderationsprotokoll festgehalten.

Jede Zustellung eines Webhooks mit Secret trägt nun einen Header X-Catodon-Signature, einen HMAC-SHA256 aus einem Zeitstempel und dem Inhalt, mit diesem Secret als Schlüssel, sodass ein Empfänger prüfen kann, dass sie von Ihrem Server stammt und aktuell ist. Webhooks, die ohne Secret erstellt werden, erhalten nun ein zufälliges, und X-Misskey-Hook-Secret, das das Secret selbst sendet, ist veraltet und wird in 27.1.0 entfernt.

Konto- und System-Webhooks listen nun ihre letzten 30 Zustellversuche auf: wann, welches Ereignis, der HTTP-Status oder warum keine Antwort kam und wie lange es dauerte. Eine Schaltfläche „Erneut senden“ sendet eine Zustellung erneut, die verloren ging, während Ihr Empfänger ausgefallen war, auch bei deaktiviertem Webhook, mit unveränderter eventId, damit ein Empfänger sie erkennen kann. Das Protokoll ist auch über i/webhooks/deliveries und admin/system-webhook/deliveries lesbar.

Ein Webhook, der 10 Ereignisse in Folge nicht zustellen kann, das erste mindestens eine Stunde zuvor, wird nun deaktiviert, statt für immer an eine tote Adresse zu senden, und sein Besitzer wird benachrichtigt: das Konto oder bei einem System-Webhook alle Moderatoren und Administratoren. Es zählen nur Ereignisse, die alle ihre Wiederholungen aufgebraucht haben, sodass ein kurzer Ausfall nichts ändert, und der Webhook lässt sich wieder einschalten, sobald sein Empfänger funktioniert.

Konto-Webhooks unter Einstellungen > Entwickler erhalten die Option Beim Erhalt einer Benachrichtigung, die jede vom Konto empfangene Benachrichtigung als Ereignis notification sendet, Reaktionen eingeschlossen. Ihre Benachrichtigungseinstellungen gelten dabei, und der Schalter Beim Erhalt einer Reaktion entfällt, da reaction nicht mehr gesendet wird.

Konto-Webhooks erhalten unter Einstellungen > Entwickler einen Abschnitt Beitragsfilter: ein Schalter pro Sichtbarkeit und eine Auswahl zwischen Autoren auf allen Servern, nur diesem Server oder nur anderen Servern. Die Filter gelten für die Ereignisse Beitrag, Bearbeitung, Antwort, Repost und Erwähnung, und i/webhooks/create und i/webhooks/update nehmen noteVisibilities und noteOrigin entgegen.

System-Webhooks unter Systemsteuerung > Webhooks erhalten Wenn ein Moderator eine Aktion ausführt, das jede im Moderationsprotokoll festgehaltene Aktion als Ereignis moderationAction sendet, und Wenn eine Registrierung auf Freigabe wartet, das userPendingApproval mit dem bei der Registrierung angegebenen Grund sendet. Beide haben eine Testschaltfläche.

Tusky, Pachli, Ice Cubes und andere Mastodon-Apps können sich nun für Push registrieren und erfahren so sofort von jeder neuen Benachrichtigung, statt alle 15 Minuten nachzusehen oder bei geschlossener App nichts zu erhalten. Die von der App angeforderten Benachrichtigungsarten und ihre Einstellung „von wem“ werden beachtet, und wird der Zugriff einer App widerrufen, wird auch ihr Abonnement entfernt. Es nutzt die bestehenden Web-Push-Einstellungen des Servers.