From 01a1a4bad62d87ef6ae475a38669dfe5b14c2a23 Mon Sep 17 00:00:00 2001 From: Alex Emmet <111742636+Alex-Emmet@users.noreply.github.com> Date: Thu, 21 May 2026 21:37:29 +0200 Subject: [PATCH 1/3] Metrics, Tool config ... --- src/content/docs/components/iota/endpoints.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/src/content/docs/components/iota/endpoints.md b/src/content/docs/components/iota/endpoints.md index 7636270..47d4133 100644 --- a/src/content/docs/components/iota/endpoints.md +++ b/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. From 19b1c60fab747cff698674f40d99692c382f5821 Mon Sep 17 00:00:00 2001 From: Alex Emmet <111742636+Alex-Emmet@users.noreply.github.com> Date: Wed, 3 Jun 2026 14:23:18 +0200 Subject: [PATCH 2/3] User Online Status --- .../docs/components/omikron/endpoints.md | 65 +++++++++++++++++++ 1 file changed, 65 insertions(+) diff --git a/src/content/docs/components/omikron/endpoints.md b/src/content/docs/components/omikron/endpoints.md index 640a07c..30bc9b2 100644 --- a/src/content/docs/components/omikron/endpoints.md +++ b/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": "", + "type": "client_changed", + "data": { + "user_state": "" + } +} +``` + +### 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_state": "" + } +} +``` + +### 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": "", + "type": "get_user_data", + "data": { + "user_id": long, + "username": "", + "display": "", + "public_key": "", + "iota_id": long, + "online_status": "", + "omikron_id": long, + "omikron_connections": [long, ...], + "sub_level": long, + "sub_end": long, + "about": "?", + "avatar": "?", + "status": "?" + } +} +``` From f5726f9072c1156d0c0b2c766096e5ca8314b3a6 Mon Sep 17 00:00:00 2001 From: Alex Emmet <111742636+Alex-Emmet@users.noreply.github.com> Date: Wed, 3 Jun 2026 20:55:18 +0200 Subject: [PATCH 3/3] Message States, Tauri, Global and Local Settings --- .../docs/components/omega/endpoints.md | 16 ++ src/content/docs/components/omega/tauri.md | 159 ++++++++++++++++++ 2 files changed, 175 insertions(+) create mode 100644 src/content/docs/components/omega/tauri.md diff --git a/src/content/docs/components/omega/endpoints.md b/src/content/docs/components/omega/endpoints.md index 62a54c3..b138897 100644 --- a/src/content/docs/components/omega/endpoints.md +++ b/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": "", // Optional, if not in receiver field + "sender_id": "" + } +} +``` diff --git a/src/content/docs/components/omega/tauri.md b/src/content/docs/components/omega/tauri.md new file mode 100644 index 0000000..43d3e93 --- /dev/null +++ b/src/content/docs/components/omega/tauri.md @@ -0,0 +1,159 @@ + # Tauri System + +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": "" + } +} +``` + +##### `RES:` + +```json +{ + "type": "success", + "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": "" + } +} +``` + +### 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": "" + } +} +``` + +### 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": "", + "display": "", + "public_key": "", + "iota_id": long, + "online_status": "", // user_online, user_offline, user_invisible, etc. + "sub_level": long, + "sub_end": long, + "about": "?", + "avatar": "?", + "status_message": "?" +} +``` + +### 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" +} +```