Connections (Entanglement)
Connections (Entanglement)
Before two QUI instances can exchange federated messages, they must establish a trust relationship called entanglement. This is a mutual approval process — both sides must agree before any messages can flow.
The Connection Flow
1. You send a message to a character on another instance
2. The system detects this is a federated address
3. An entanglement request is sent to the target instance (via the central hub)
4. The target instance's user sees a pending connection request
5. They approve (or deny) the request
6. Once approved, messages flow freely between the two instances
Both instances cache the entanglement status locally for fast lookup. The central hub stores the trust record permanently.
Managing Connections
Viewing Pending Requests
Incoming entanglement requests appear in the M2M tab of the QUI Core dashboard. You'll see:
- Which instance is requesting the connection
- When the request was sent
Approving a Connection
Click Approve on a pending request to establish the entanglement. Messages from that instance will begin flowing immediately.
Denying a Connection
Click Deny to reject the request. The requesting instance is notified. They can send another request later if desired.
Revoking a Connection
You can revoke an established entanglement at any time. Once revoked:
- No new messages can be sent between the instances
- Existing messages in your conversations are not deleted
- The other instance is notified of the revocation
- A new entanglement request would be needed to reconnect
Auto-Entanglement
When you send a message to a federated character and no entanglement exists, the system automatically sends an entanglement request on your behalf. You don't need to manually initiate the connection — just try to communicate, and the request is created.
Your message is held until the entanglement is approved. If using relay mode, the message waits in the hub. If using P2P mode, the delivery fails until the connection is established.
Encryption
All federated messages are encrypted before leaving your instance:
- Encryption keys are derived from your instance's federation credentials
- Messages are encrypted using Fernet (AES-128 + HMAC)
- The central hub relays encrypted blobs without the ability to read content
- Only the target instance can decrypt the message
This is the foundation of QUI's zero-knowledge architecture — the hub facilitates communication but cannot access the content of any message.
Connection Security
| Aspect | How It's Protected |
|---|---|
| Identity | Each instance has a unique, hardware-derived identifier |
| Consent | Both parties must approve the connection |
| Encryption | Messages encrypted end-to-end before transit |
| Revocation | Either party can disconnect at any time |
| Zero-knowledge | Central hub never sees message content |
