logos-messaging/chat_proto
1
0
Fork 0
mirror of https://github.com/logos-messaging/chat_proto.git synced 2026-01-02 21:13:09 +00:00
Code Issues Packages Projects Releases Wiki Activity

update inbox.md

Browse Source
This commit is contained in:
Jazz Turner-Baggs 2025-07-09 11:44:16 -07:00
parent 655719fdbd
commit ed5d8efa8d
No known key found for this signature in database
1 changed files with 22 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
specs/inbox.md
View File

@ -19,8 +19,16 @@ Clients must be able to receive frames before conversations can be initialized.
Inboxes are inbound only conversation types, which allow a client to receive messages from contacts.
An inbox does not have a defined set of participants, and is used to receive messages when there is not an established channel between contacts.
An inbox does not have an inherent keypair or identity associated with it - it's an agreed upon location to recieve messages.
An inbox does not have an inherent keypair or identity associated with it - it's an agreed upon location to receive messages.
Inboxes are not exclusive to a single account, and can be used by many different accounts. It is expected
## Invitations / Initialization
Inboxes do not require coordination with other clients because they are inbound only.
However to receive messages at this inbox, remote clients must know this is a valid place to receive messages. This can be statically defined in a conversation protocol or communicated out of band.
## Inbox Identifiers
@ -29,7 +37,7 @@ Inboxes are Identified by a
Inboxes do not need to be "created", and there is no required initialization.
## Content Topic
## Content Topic Usage
// TODO: Inbox Topics will be defined in ContactBundles, allowing for dynamic topic usage
All clients must listen for messages posted with the content topic `/inbox/<inbox_address>`
@ -90,9 +98,9 @@ flowchart TD
### EncryptedBytes
The EncryptedBytes message is a self-describing wrapper for all encrypted payloads. As the protocol grows it will include potentially different encryption mechanisms. This message type makes no assumptions about the encryption used an allows new conversation types to use the same messaging framework.
The EncryptedBytes message is a self-describing wrapper for all encrypted payloads. This message type makes no assumptions about the encryption used an allows new conversation types to use the same messaging framework.
As this protocol uses the KN noise handshake, the encoding wrapper uses the corresponding type.
## Wire Format Specification / Syntax
@ -107,39 +115,28 @@ message InboxV1Frame {
}
}
message EncryptedBytes {
message EncryptedPayload {
oneof encryption {
bytes encrypted_bytes=1;
Plaintext plaintext = 2;
Ecies ecies = 3;
NoiseKN noise_KN = 3;
}
message Ecies {
bytes encrypted_bytes=1;
message NoiseKN {
bytes encrypted_bytes = 1;
bytes ephemeral_pubkey = 2;
bytes tag = 3;
}
message Plaintext {
bytes payload=1;
}
}
```
## Implementation Suggestions (optional)
An optional *implementation suggestions* section may provide suggestions on how to approach implementation details, and,
if available, point to existing implementations for reference.
## (Further Optional Sections)
## Security/Privacy Considerations
The encryption scheme used does not provide any sender authentication. Messages sent over this pathway need to validate the sender before trusting any of the contents.
### Sender Auth
The encryption scheme used does not provide any sender authentication. Messages sent over this pathway need to validate the sender before trusting any of the contents.
### EncryptedPayload metadata leakage
Encrypted bytes themselves are not encrypted so its fields are visible to all observers. Through analytical means observers can determine the type of message being sent, by looking at what fields are present, and the relative size of the payload. This is true regardless of whether the encrypted bytes are wrapped in a EncryptedPayload object. Wrapping the payload allows for better support into the future without meaningful changing the metadata leakage.
## Copyright