Merge remote-tracking branch 'refs/remotes/origin/main'

src/content/docs/components/iota/endpoints.md

@@ -10,6 +10,25 @@ When a message comes from an iota without a `sender-id` that the iota has access
 
 ## Messages
 
+### Messaging Lifecycle
+
+The messaging system follows a strict derivation loop to ensure delivery and correct state synchronization:
+
+1. The client sends a `message_send` to its Iota.
+2. The Iota sends a response `message_send` as confirmation back to the client.
+3. The Iota sends a `message_other_iota` to the chat partner's Iota.
+   - **If it times out:**
+     - The initial Iota sends a `message_state` to the client with the state `"sending"`.
+   - **If successful:**
+     - The other Iota receives the `message_other_iota` and handles it.
+     - The other Iota informs its client with a `message_live`.
+     - **If the client doesn't answer:**
+       1. The other Iota will send a `message_state` to the initial Iota with the state `"sent"`.
+       2. The initial Iota will store the state and forward the `message_state` to its client.
+     - **If the client answers with `message_state`:**
+       1. The other Iota will store the state (either `"received"` or `"read"`) and forward the `message_state` to the initial Iota.
+       2. The initial Iota will store the state and forward the `message_state` to its client.
+
 ### Client adds someone to their contacts
 When adding via name, the omikron will intercept and fill the chat_partner_id.
 The iota will never read, or handle the chat_partner_name.

src/content/docs/components/omega/endpoints.md

@@ -55,3 +55,19 @@ Any message to the `Omega` will be ignored until Identification.
 	}
 }
 ```
+
+### Push Notification
+
+Sends a push notification to a user. The receiver ID can be specified either in the `receiver` field of the message or in the data payload.
+
+##### `REQ:`
+
+```json
+{
+  "type": "push_notification",
+  "data": {
+    "receiver_id": "<user-id>", // Optional, if not in receiver field
+    "sender_id": "<user-id>"
+  }
+}
+```

src/content/docs/components/omega/tauri.md

@@ -3,3 +3,161 @@ title: Tauri
 ---
 
 # Tauri
+
+The Tauri system provides push notification capabilities for mobile clients via a secure QUIC connection.
+
+### Connection
+
+Tauri clients connect to the Omega server on port 9189 using QUIC with client certificate authentication.
+
+### Identification
+
+Any message to the Tauri server will be ignored until Identification.
+
+##### `REQ:`
+
+```json
+{
+  "type": "tauri_identification",
+  "data": {
+    "user_id": "<user-id>"
+  }
+}
+```
+
+##### `RES:`
+
+```json
+{
+  "type": "success",
+  "id": "<message-id>"
+}
+```
+
+### Ping & Pong
+
+Tauri clients must respond to ping messages to maintain their connection.
+
+#### `REQ:`
+
+```json
+{
+  "type": "ping",
+  "data": {
+    "last_ping": long
+  }
+}
+```
+
+#### `RES:`
+
+```json
+{
+  "type": "pong",
+  "data": {
+    "last_ping": long
+  }
+}
+```
+
+### Push Notifications
+
+When a user is offline (no active Iota connection), messages generate push notifications that are sent to Tauri clients.
+
+#### `REQ:`
+
+```json
+{
+  "type": "push_notification",
+  "data": {
+    "sender_id": "<user-id>"
+  }
+}
+```
+
+### Read Notifications
+
+When a user reads a message on any device, a read notification is sent to clear the push notification badge on Tauri clients.
+
+#### `REQ:`
+
+```json
+{
+  "type": "read_notification",
+  "data": {
+    "sender_id": "<user-id>"
+  }
+}
+```
+
+### Tauri Client Responsibilities
+
+1. Establish QUIC connection to Omega:9189
+2. Send `tauri_identification` with user_id
+3. Respond to ping messages with pong
+4. Display notifications when receiving `push_notification` messages
+5. Clear notification badges when receiving `read_notification` messages
+6. Maintain connection heartbeat (respond to pings within 30 seconds)
+
+## Omega Server Endpoints (HTTPS)
+
+The Omega server provides an HTTPS API for administrative and data retrieval functions, which Tauri clients can use to synchronize notification state.
+
+### Get User Data
+
+Retrieve user profile information including online status.
+
+#### `GET: /api/get/user/{user_id}`
+
+##### `RES:`
+
+```json
+{
+  "status": "success",
+  "user_id": long,
+  "username": "<string>",
+  "display": "<string>",
+  "public_key": "<base64>",
+  "iota_id": long,
+  "online_status": "<status>", // user_online, user_offline, user_invisible, etc.
+  "sub_level": long,
+  "sub_end": long,
+  "about": "<string>?",
+  "avatar": "<base64>?",
+  "status_message": "<string>?"
+}
+```
+
+### Get User Notifications
+
+Retrieve pending push notifications for a user.
+
+#### `GET: /api/get/notifications/{user_id}`
+
+##### `RES:`
+
+```json
+{
+  "status": "success",
+  "notifications": [
+    {
+      "sender_id": long,
+      "amount": long
+    }
+  ]
+}
+```
+
+### Mark Notification as Read
+
+Clear a specific notification.
+
+#### `DELETE: /api/delete/notifications/{user_id}/{sender_id}`
+
+##### `RES:`
+
+```json
+{
+  "status": "success"
+}
+```

src/content/docs/components/omikron/endpoints.md

@@ -175,3 +175,68 @@ The ping request should contain the last Client or Iota ping and the pong answer
   }
 }
 ```
+
+## User Online Status
+
+### Set Client Status
+
+The client can change their online status by sending a `client_changed` message.  
+Supported status values: `user_online`, `user_offline`, `user_dnd`, `user_idle`, `user_wc`, `user_invisible`.
+
+When `user_invisible` is set, the user remains connected and can send/receive messages, but appears as `user_offline` to all other users.
+
+#### `REQ` (Client → Omikron):
+
+```json
+{
+  "id": "<uuid>",
+  "type": "client_changed",
+  "data": {
+    "user_state": "<status>"
+  }
+}
+```
+
+### Online Status Notifications
+
+When a connected user changes their status, interested clients receive a notification:
+
+#### `EVENT` (Omikron → Client):
+
+```json
+{
+  "type": "client_changed",
+  "data": {
+    "user_id": "<user-id>",
+    "user_state": "<status>"
+  }
+}
+```
+
+### Online Status in User Data
+
+When fetching another user's profile via `get_user_data`, their online status is included in the response. Invisible users are reported as `user_offline`.
+
+#### `RES` (Omikron → Client, field in `get_user_data`):
+
+```json
+{
+  "id": "<uuid>",
+  "type": "get_user_data",
+  "data": {
+    "user_id": long,
+    "username": "<string>",
+    "display": "<string>",
+    "public_key": "<base64>",
+    "iota_id": long,
+    "online_status": "<status>",
+    "omikron_id": long,
+    "omikron_connections": [long, ...],
+    "sub_level": long,
+    "sub_end": long,
+    "about": "<string>?",
+    "avatar": "<base64>?",
+    "status": "<string>?"
+  }
+}
+```