Messages
Zot6 ist in erster Linie ein Transport- und Identifikationsformat. Die Semantik des Nachrichteninhalts liegt in vielerlei Hinsicht außerhalb des Geltungsbereichs dieses Dokuments. Websites/Server MÜSSEN in ihrem Site-Discovery-Dokument angeben, welche standardisierten Nachrichtenformate akzeptiert werden.
Die für uns vorrangig relevanten Nachrichtenformate sind
- ActivityStreams (ActivityStreams JSON-LD) (format=‚activitystreams‘)
- Zot (format=‚zot‘)
Bei der Verwendung von ActivityStreams JSON-LD wird standardmäßig ein @context von „https://www.w3.org/ns/activitystreams“ angenommen. Aktivitätsobjekte müssen nur dann eine @context-Deklaration angeben oder bereitstellen, wenn Abweichungen vom Standard vorliegen.
Delivery
Die Zustellung erfolgt als POST-Anruf mit Umschlag und Daten an den Zot-Endpunkt. Zur Validierung des Absenders werden HTTP-Signaturen verwendet. Zustellberichte für private Nachrichten SOLLTEN verschlüsselt sein und MÜSSEN Ergebnisse zur Host-Sperrung enthalten. Hier ist ein Beispiel für eine Aktivität…
{
"type": "activity",
"encoding": "activitystreams",
"sender": "wXDz7WR51QHwAORaVR8-0wff06LBtBWvhd_zfDWTYEzaqaPfJ_fsK7nRaM4aVeKPmZklUAgtqs09zUzitwNT2w",
"site_id": "gcwJ1OzIZbwtfgDcBYVYhwlUmjaxsgPyJezd-F2IS1F3IrlVsyOesNpm3hvoWemIBxoHmgIlMYKkhFeYihsqBQ",
"recipients": {
"xxWsqvZp3w-sr3FXrmb6wxmKZx6khMLjBCOafPdRT1lWzYmCPHeaDDBD9KwOqpOAt4lezIFQbyaLt9I3H54M9Q",
"T5ni0wUAlYmyqlibiTQiS54PqLKXCL7XAJhOSKeJMqEXeKn46AkDPdCJZ4JUA05Vlhux25OLTkBPyV7L60JmyQ",
},
"version": "6.0",
"data": {
"type": "Create",
"id": "https://example.org/item/e8a20a21dd7e0d8d2207a5df62d2168d65db7db08f1a91ca",
"published": "2018-06-25T04:14:08Z",
"actor": "https://example.org/channel/zapper",
"object": {
"type": "Article",
"id": "https://example.org/item/e8a20a21dd7e0d8d2207a5df62d2168d65db7db08f1a91ca",
"published": "2018-06-25T04:14:08Z",
"content": "just another Zot6 message",
"actor": "https://example.org/channel/zapper",
},
},
}
Die „sender_id“ ist die „portable_id“ des Absenders. Die „site_id“ ist die „portable_id“ der Website des Absenders. „recipients“ ist ein einfaches Array aus „portable_ids“ der Nachrichtenempfänger. Diese Liste KANN gefiltert werden und nur die Empfänger enthalten, von denen bekannt ist, dass sie auf der empfangenden Website verfügbar sind.
Die „version“ wird angegeben, um mögliche Unterschiede bei der Protokollversion im Laufe der Zeit auszugleichen. „data“ enthält die eigentliche Nutzlast von ActivityStreams (in diesem Fall).
Empfangende Websites MÜSSEN die bereitgestellte HTTP-Signatur überprüfen und Beiträge ohne Signatur oder mit ungültigen Signaturen ablehnen (Fehler 400). Während des Überprüfungsprozesses wird „Discovery“ verwendet, wodurch eine lokal gespeicherte „portable_id“ generiert wird. Stimmt die „portable_id“ nicht mit der „portable_id“ des verifizierten Unterzeichners überein, MUSS die Nachricht abgelehnt werden (Fehler 400).
Wenn das Feld „recipients“ nicht vorhanden oder leer ist, gilt der Beitrag als öffentlich und darf an jeden Kanal zugestellt werden, der dem Absender folgt. Wenn das Feld „recipients“ Inhalte enthält, DARF die Nachricht an niemanden außer den aufgeführten Empfängern zugestellt werden.
Nach erfolgreicher Zustellung wird ein Zustellbericht erstellt und an die sendende Seite zurückgesendet.
{
"success": true,
"delivery_report": [
{
"location": "https://zap.macgirvin.com",
"sender": "T5ni0wUAlYmyqlibiTQiS54PqLKXCL7XAJhOSKeJMqEXeKn46AkDPdCJZ4JUA05Vlhux25OLTkBPyV7L60JmyQ",
"recipient": "xxWsqvZp3w-sr3FXrmb6wxmKZx6khMLjBCOafPdRT1lWzYmCPHeaDDBD9KwOqpOAt4lezIFQbyaLt9I3H54M9Q",
"name": "System ",
"message_id": "https://zap.macgirvin.com/item/ebaa483a2e8331a21a68b9d9e4a72a079c260162d2e37edc",
"status": "posted",
"date": "2018-06-26 05:19:48"
},
{
"location": "https://zap.macgirvin.com",
"sender": "T5ni0wUAlYmyqlibiTQiS54PqLKXCL7XAJhOSKeJMqEXeKn46AkDPdCJZ4JUA05Vlhux25OLTkBPyV7L60JmyQ",
"recipient": "wXDz7WR51QHwAORaVR8-0wff06LBtBWvhd_zfDWTYEzaqaPfJ_fsK7nRaM4aVeKPmZklUAgtqs09zUzitwNT2w",
"name": "Zapper ",
"message_id": "https://zap.macgirvin.com/item/ebaa483a2e8331a21a68b9d9e4a72a079c260162d2e37edc",
"status": "posted",
"date": "2018-06-26 05:19:48"
},
{
"location": "https://zap.macgirvin.com",
"sender": "T5ni0wUAlYmyqlibiTQiS54PqLKXCL7XAJhOSKeJMqEXeKn46AkDPdCJZ4JUA05Vlhux25OLTkBPyV7L60JmyQ",
"recipient": "T5ni0wUAlYmyqlibiTQiS54PqLKXCL7XAJhOSKeJMqEXeKn46AkDPdCJZ4JUA05Vlhux25OLTkBPyV7L60JmyQ",
"name": "Bopper ",
"message_id": "https://zap.macgirvin.com/item/ebaa483a2e8331a21a68b9d9e4a72a079c260162d2e37edc",
"status": "update ignored",
"date": "2018-06-26 05:19:48"
}
]
}
Followups
Alle Folgeaktivitäten zu einem Beitrag (Antworten, Likes, Reaktionen usw.) MÜSSEN als private Aktivität (einzelner Empfänger) an den Absender des Originals mit dem Nachrichtentyp „response“ gesendet werden. Dies wird als „Upstream-Zustellung“ bezeichnet.
Darüber hinaus MÜSSEN diese Aktivitäten ein „inReplyTo“-Element enthalten, das auf die ID der Aktivität gesetzt ist, auf die sich die Antwort bezieht. Implementierungen SOLLTEN mehrstufige Likes unterstützen. Server KÖNNEN mehrstufige Kommentare unterstützen.
Der ursprüngliche Absender MUSS die Folgeaktivitäten unter Verwendung des Nachrichtentyps „activity“ an alle Empfänger der ursprünglichen Nachricht erneut senden. Dies wird als „Downstream-Übermittlung“ bezeichnet.
Dieser Mechanismus mit einer einzigen Quelle stellt sicher, dass die Datenschutzeinstellungen des ursprünglichen Absenders respektiert werden und die Konversationen für alle Empfänger der ursprünglichen Nachricht intakt bleiben.
Multi-level support
Wenn mehrstufige Kommentare nicht unterstützt werden, MUSS der Empfänger den mehrstufigen Kommentar dem ursprünglichen Konversationskopf zuordnen und die Konversation dabei auf eine Ebene vereinfachen. Der empfangende Server SOLLTE die korrekte Ziel-ID speichern, auch wenn der Kommentar neu zugeordnet wird.
Wenn mehrstufige „Likes“ nicht unterstützt werden, DARF die eingehende „Like“-Aktivität für einen nicht übergeordneten Konversationsknoten verworfen oder abgelehnt werden, anstatt sie einem möglicherweise nicht beabsichtigten, nicht verwandten Aktivitätsknoten zuzuordnen.
Portable IDs
Portable IDs dienen dazu, ortsunabhängige Identifikatoren im gesamten Netzwerk bereitzustellen. Eine portable ID ist nur dann vertrauenswürdig, wenn sie verifiziert wurde oder auf dieser Website generiert wurde. Die Verifizierung erfolgt im Rahmen des [[Discovery]]-Prozesses.
Die portable ID verwendet einen bereitgestellten öffentlichen Schlüssel. Um sicherzustellen, dass die Berechnung der portablen ID portabel ist, MUSS die Berechnung anhand eines öffentlichen Schlüssels im PKCS#8-Format erfolgen. Wird der Quellschlüssel in einem anderen Format bereitgestellt (z. B. als Salmon-Schlüssel [Modulus/Exponent] oder im PKCS#1-Format), MUSS der Schlüssel vor der Berechnung der portablen ID in das PKCS#8-Format konvertiert werden.
Im Folgenden werden die Schritte zur Generierung einer „portable_id“ beschrieben.
- Rufen Sie über [[Discovery]] das „zot-info“-Paket für eine Netzwerk-URI ab. Die Netzwerk-URI wird häufig als „signer keyID“ in einer signierten Nachricht angegeben, kann aber auch als „acct:“-URI bereitgestellt werden, die von Nutzern der Website übermittelt wird.
- Das „zot-info“-Paket enthält alle notwendigen Informationen zur Überprüfung einer Identitätsangabe.
- Überprüfen Sie mit dem „public_key“ die „id_sig“ anhand der „id“ (angegebene Identität).
- Überprüfen Sie mit dem public_key die location->url_sig anhand der location->url für die Discovery-Website.
- Überprüfen Sie mit site->sitekey die site->site_sig anhand der site->url.
- Verketten Sie die id und den public_key. Wenden Sie auf diese verkettete Zeichenfolge eine Whirlpool-Hashfunktion an und führen Sie eine Base64-URL-Kodierung des Ergebnisses durch.
- Dies ist die Kanal-portable_id.
- Verknüpfen Sie die URL und site->sitekey. Wenden Sie auf diese verkettete Zeichenfolge eine Whirlpool-Hash-Funktion an und kodieren Sie das Ergebnis mit base64_url.
- Dies ist die portable site_id. Überprüfen Sie, ob sie mit der location->site_id im Discovery-Paket übereinstimmt.
- Wenn ein Verifizierungsschritt fehlschlägt, verwerfen Sie die Ergebnisse und geben Sie einen Fehler zurück.
Diese Berechnung gilt allgemein als rechenintensiv; daher sollten die Ergebnisse als Paar aus Kanal und Ort gespeichert werden.
Wenn Sie eine Zot-Nachricht erhalten, verwenden Sie bei der Überprüfung der HTTP-Signatur die gespeicherten Ergebnisse (sofern vorhanden) für die keyID des Unterzeichners. Wenn die HTTP-Signatur gültig ist, die keyID mit der location->id_url für diesen Standort übereinstimmt und die portable_id des Absenders mit der berechneten/gespeicherten portable_id für dieses Kanal-Standort-Paar übereinstimmt, wurde der nomadische Absender validiert.
Falls für die keyID keine gespeicherten Ergebnisse vorliegen, führen Sie [[Discovery]] wie beschrieben durch.