Message Types
purge
Dieser Nachrichtentyp enthält weder Nutzdaten noch eine Kodierung. Wenn die Nachricht Empfänger hat, gilt sie als „Unfriend“-Aktion. Die Beziehung des Absenders zu den Empfängern wird beendet. Die genauen Maßnahmen, die daraufhin ergriffen werden, sind implementierungsspezifisch. Im Allgemeinen werden die Berechtigungen des Absenders gegenüber dem Empfänger widerrufen. Die dem Absender vom Empfänger gewährten Berechtigungen KÖNNEN unverändert bleiben.
Hat die Nachricht keine Empfänger, gilt sie als Benachrichtigung, dass die Identität des Absenders nicht mehr existiert. Empfangende Seiten MÜSSEN den Kanal als nicht verfügbar kennzeichnen und die weitere Kommunikation einstellen. Sie SOLLTEN alle dem Absender zugeordneten öffentlichen Inhalte löschen und KÖNNEN die Verbindung sowie private Inhalte aus verbundenen Kanälen entfernen.
Die Antwort auf diese Nachricht lautet
{
'success': true
}
oder
{
'success': false,
'message': 'optional error message or reason'
}
Server SOLLTEN bei der Verwendung einer zielgerichteten Nachricht nur einen einzigen Empfänger angeben, da die einzelne Rückantwort mehrdeutig sein könnte.
refresh
Diese Nachricht enthält weder Nutzdaten noch eine Kodierung. Sie dient dazu, dem empfangenden Server mitzuteilen, dass sich wichtige Kanalinformationen geändert haben. Der empfangende Server MUSS einen „Zot Discovery“-Vorgang durchführen und alle lokal gespeicherten Informationen, die sich geändert haben, aktualisieren. Falls die Nachricht Empfänger enthält, sollte diese Aktion vom Empfänger mithilfe eines signierten „Discovery Fetch“ durchgeführt werden, der vom Empfänger signiert ist. Die Antwort entspricht der einer „Purge“-Nachricht.
Eine gezielte Aktualisierungsnachricht (die z. B. Empfänger enthält) wird üblicherweise verwendet, um eine Änderung der Berechtigungen anzuzeigen, die der Absender dem Empfänger gewährt hat. Wenn diesem Absender zuvor keine Berechtigungen zugewiesen wurden, gilt dies als „Freundschaftsanfrage“, was bedeutet, dass bestimmte Berechtigungen verfügbar sind, die zuvor möglicherweise nicht verfügbar waren. Der empfangende Kanal SOLLTE die aktualisierten Berechtigungen speichern und den Absender zu den bekannten Verbindungen des Empfängers hinzufügen. Er KANN den Empfänger darüber benachrichtigen, dass ein neuer Freund vorliegt, und die Verbindung in den Status „ausstehend“ versetzen, bis die Anfrage vom Empfänger geprüft, angenommen oder abgelehnt wurde.
rekey
Die „rekey“-Nachricht wird ohne Empfänger gesendet. Die Nachricht gibt an, dass der Absender seinen öffentlichen Schlüssel geändert hat. Die Schlüsseländerung MUSS sowohl mit dem alten als auch mit dem neuen privaten Schlüssel signiert sein, und diese Signaturen MÜSSEN gültig sein, andernfalls MUSS der Vorgang fehlschlagen. Das boolesche Flag „update“ (sofern vorhanden) gibt an, dass die mit diesem Schlüssel verknüpfte alte „portable_id“ geändert und die alte „portable_id“ verworfen werden soll. Ist „update“ falsch, wird eine neue „portable_id“ generiert und die alte sowie die neue Identität werden miteinander verknüpft. Das bedeutet, dass beide „portable_id“s gültige nomadische Identifikatoren für denselben Kanal sind. Die Antwort entspricht der für die „purge“-Nachricht.
activity
Nachrichtenkodierung: activitystreams
Dieser Nachrichtentyp wird für die normale Kommunikation verwendet. Sind Empfänger angegeben, handelt es sich um eine private Nachricht. Sind keine Empfänger angegeben, ist die Nachricht öffentlich. Die Empfängerliste KANN gefiltert werden und nur diejenigen Empfänger enthalten, von denen bekannt ist, dass sie auf der empfangenden Website verfügbar sind. Der Absender DARF eine Nachricht NICHT versenden, wenn es sich um eine private Nachricht handelt und die Empfängerliste für eine bestimmte empfangende Website leer ist.
{
"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",
},
}
Bei der Zustellung wird ein Zustellbericht erstellt und an den Absender 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"
}
]
}
response
Die Antwortnachricht dient dazu, einen Kommentar oder eine Antwort „stromaufwärts“ an den Absender zu senden. Der Absender leitet die Nachricht anschließend an alle nachgelagerten Empfänger weiter. Sie entspricht dem Nachrichtentyp „Aktivität“, mit dem Unterschied, dass sie genau einen Empfänger haben MUSS – nämlich den Absender der Aktivität, auf die sich diese Aktivität bezieht. Diese gesamte Aktivität SOLLTE vom Absender der Antwort signiert und als JSON-Salmon-Magic-Envelope gekapselt werden, wie in Encryption+Signatures beschrieben.
sync
Zwischen nomadischen Klonen werden Synchronisationsnachrichten verwendet, um geänderte Datenstrukturen zu synchronisieren. Diese Nachrichten werden als private Nachrichten an die nomadischen Instanzen des Absenders gesendet und SOLLTEN zusätzlich zur HTTPS-Transportverschlüsselung weiter verschlüsselt werden, da die Nachrichten private Schlüssel enthalten können.
Implementierungen KÖNNEN Synchronisationsnachrichten bereitstellen und KÖNNEN versuchen, mit Synchronisationspaketen koexistieren, die von anderen Implementierungen erstellt wurden. Wenn ihre Anforderungen an die Datensynchronisation nicht auf die von anderen bereitgestellten Synchronisationsstrukturen abgebildet werden können, MÜSSEN sie einen eindeutigen Kodierungstyp bereitstellen (es wird empfohlen, den Namen der Implementierung unter ausschließlicher Verwendung der Buchstaben [a–z] des US-ASCII-Zeichensatzes zu wählen). Wenn eine Stelle eine Synchronisationsnachricht mit unbekannter Kodierung und unbekanntem Datenformat empfängt, MUSS diese ignoriert werden.
Zu den grundlegenden Synchronisierungsinformationen gehören alle lokalen Änderungen an persönlichen Einstellungen, Profileinstellungen sowie Änderungen im sozialen Netzwerk. Implementierungen KÖNNEN die Synchronisierung aller verfügbaren Informationen unterstützen, einschließlich hochgeladener Dateien und Fotos, Ereignisse sowie anderer anwendungsspezifischer Datenstrukturen.