Triluna-Dienstmodell
Triluna Nachrichten ist als sicheres institutionelles Postfach konzipiert, nicht als öffentliche Chat-Behauptung.
Messages ist die vorgesehene Kommunikationsschicht für direkte, Gruppen-, institutionelle, System-, Sicherheits- und strukturierte Anfragen. Sie ist nach Vorgabe ausschließlich E2EE: Es gibt keinen serverlesbaren Rückfallweg und keine öffentliche Nachrichtenübermittlung, solange ein geprüftes gruppenfähiges Ende-zu-Ende-Protokoll fehlt.
Identität, Geräte und Institutionen
RENKAN ID identifiziert; Messages autorisiert Kommunikation lokal.
- Gerätebezogene Teilnahme
- Eine künftige teilnehmende Person hat pro Gerät öffentliche Verschlüsselungs- und Signaturdaten. Private Schlüssel, Wiederherstellungsgeheimnisse und Nachrichtentext werden nicht serverseitig gespeichert.
- Institutionelle Gespräche
- Ein institutioneller Faden enthält eine autorisierte Institutionsreferenz und eine Mitgliedschaftsrevision. Änderungen gelten für künftige verschlüsselte Umschläge; sie gewähren nicht stillschweigend Zugriff auf alte Verläufe.
- Verlaufsregel
- Neue Mitglieder erhalten je nach geprüftem Protokoll keinen früheren Verlauf oder erst Verlauf ab ihrer Beitrittsrevision. Institutionelles Escrow ist ausdrücklich nicht implementiert.
- Benachrichtigungen
- Jede künftige externe Push-Mitteilung bleibt absichtlich allgemein — „Triluna · Neue sichere Benachrichtigung“ — und verrät keinen Inhalt, Absender oder Betreff außerhalb des verschlüsselten Clients.
Heute ein Knoten; Grenzen für spätere Föderation
Das gegenwärtige Modell ist operativ zentralisiert und behauptet keine Dezentralisierung.
Ein öffentlicher Knotendeskriptor beschreibt einen logischen Knoten, Protokollversionen, Dienstkapazität, Föderationsstatus und Gesundheitsstatus, ohne ein Nutzerverzeichnis offenzulegen. Heute beschreibt er einen zentralisierten Knoten mit deaktivierter Föderation, ohne registrierte externe Knoten und ohne veröffentlichten Knotenschlüssel. Der Deskriptor ist eine Interoperabilitätsgrenze, kein Nachweis eines föderierten Netzes.
Vor jeder Aktivierung braucht das Projekt eine geprüfte E2EE-Gruppennachrichten-Implementierung, Geräteprüfung und Widerruf, authentifizierte Mitgliedschaftsänderungen, Missbrauchsschutz, Schlüsselverlust-Behandlung ohne Serverwiederherstellung, Betriebskontrollen und unabhängige Sicherheitsprüfung.
Keine simulierte Privatsphäre
Ein deaktivierter Transport ist sicherer als ein nicht-E2EE-Rückfallweg.
Diese Seite impliziert weder Klartextsuche, administrativen Inhaltszugriff noch automatische Schlüsselwiederherstellung. Der vorhandene lokale Relay-Prototyp ist eine getrennte Forschungsreferenz, keine Produktionsimplementierung dieses Dienstes.