Modèle de service Triluna
Messages Triluna est conçu comme une boîte de réception institutionnelle sûre, non comme une promesse publique de chat.
Messages est la couche de communication prévue pour les échanges directs, de groupe, institutionnels, système, sécurité et demandes structurées. Par principe, elle est uniquement E2EE : aucun repli lisible par le serveur ni aucune remise publique ne sont admis tant qu’un protocole de groupe chiffré de bout en bout et évalué manque.
Identité, appareils et institutions
RENKAN ID identifie ; Messages autorise localement la communication.
- Participation par appareil
- Un futur participant dispose de matériel public de chiffrement et de signature par appareil. Les clés privées, secrets de récupération et textes de message ne sont pas des enregistrements serveur.
- Conversations institutionnelles
- Un fil institutionnel enregistre une référence d’institution autorisée et une révision de membres. Les changements s’appliquent aux futures enveloppes chiffrées ; ils n’accordent pas silencieusement l’historique antérieur.
- Règle d’historique
- Les nouveaux membres peuvent ne recevoir aucun historique ou celui postérieur à leur révision d’entrée lorsque le protocole évalué le permet. L’entiercement institutionnel n’est explicitement pas implémenté.
- Notifications
- Toute notification externe future restera délibérément générique — « Triluna · Nouvelle notification sécurisée » — et ne révélera ni contenu, ni expéditeur, ni sujet hors du client chiffré.
Un nœud aujourd’hui ; des frontières prêtes pour la fédération
Le modèle actuel est centralisé sur le plan opérationnel et ne prétend pas être décentralisé.
Un descripteur de nœud public nomme un nœud logique, ses versions de protocole, sa capacité de service, son état de fédération et de santé sans exposer d’annuaire d’utilisateurs. Aujourd’hui, il décrit un nœud centralisé avec fédération désactivée, sans nœud externe enregistré ni clé d’identité de nœud publiée. Ce descripteur est une frontière d’interopérabilité, non la preuve d’un réseau fédéré.
Avant toute remise, le projet exige une mise en œuvre de messagerie de groupe E2EE évaluée, des parcours de vérification et révocation d’appareil, des changements de membres authentifiés, des contrôles contre les abus, une gestion de perte de clé sans récupération serveur, une surveillance opérationnelle et un examen de sécurité indépendant.
Aucune confidentialité simulée
Un transport désactivé est plus sûr qu’un repli non E2EE.
Cette page n’implique ni recherche en clair, ni accès administratif au contenu, ni récupération automatique de clé. Le prototype Relay local existant est une référence de recherche distincte, pas l’implémentation de production de ce service.