Compare commits
2 changed files with 0 additions and 84 deletions
|
|
@ -10,25 +10,6 @@ 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.
|
||||
|
|
|
|||
|
|
@ -175,68 +175,3 @@ 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>?"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
|
|
|||
Loading…
Reference in a new issue