Development status

Development and publication work have resumed. Service APIs remain unavailable unless explicitly documented as live.

Triluna service model

Triluna Messages is designed as a secure institutional inbox, not a public chat claim.

Messages is the planned communications layer for direct, group, institutional, system, security, and structured-request communication. It is E2EE-only by policy: there is no server-readable fallback and no public message delivery while a reviewed endpoint-encrypted group protocol is still absent.

Identity, devices, and institutions

RENKAN ID identifies; Messages authorises communication locally.

Device-aware participation
A future participant has public encryption and signing material per device. Private keys, recovery secrets, and message plaintext are not server records.
Institutional conversations
An institutional thread records an authorised institution reference and a membership revision. Membership changes govern future encrypted envelopes; they do not silently grant past history.
History policy
New members may receive no prior history or history from their join revision when the reviewed protocol supports it. Institutional escrow is explicitly not implemented.
Notifications
Any future external push is deliberately generic—“Triluna · New secure notification”—so it does not disclose content, sender, or subject outside the encrypted client.

One node today; federation-ready boundaries

The current model is centralized operationally and does not claim decentralisation.

A public node descriptor names a logical node, its protocol versions, service capacity, federation state, and health state without exposing a user directory. Today it describes one centralized node with federation disabled, no registered external nodes, and no published node identity key. The descriptor is an interoperability boundary, not evidence of a federation network.

Before any delivery is enabled, the project requires a reviewed E2EE group-messaging implementation, device verification and revocation flows, authenticated membership changes, abuse controls, key-loss handling that does not create server recovery, operational monitoring, and independent security review. The local threat model records the remaining risks and non-goals.