-
Notifications
You must be signed in to change notification settings - Fork 11
initial proposal for history fetching through contacts #167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,133 @@ | ||
| --- | ||
| permalink: /draft/17 | ||
| title: 7/CONTACT-HISTORY | ||
| parent: Draft specs | ||
| layout: default | ||
| --- | ||
|
|
||
| # 7/CONTACT-HISTORY | ||
|
|
||
| > Version: 0.1 | ||
| > | ||
| > Status: Draft | ||
| > | ||
| > Authors: Iuri Matias <iuri@status.im>, Jonathan Rainville <jonathanrainville@status.im>, Richard Ramos <richard@status.im> | ||
| > | ||
|
|
||
| ## Table of Contents | ||
|
|
||
| - [Abstract](#abstract) | ||
| - [Modifications to Message Format](#Modifications-to-Message-Format) | ||
| - [Advertising Capabilities](#Advertising-Capabilities) | ||
| - [Requesting Chat history](#Requesting-Chat-history) | ||
| - [Requesting 1 on 1 chat history](#Requesting-1-on-1-chat-history) | ||
| - [Requesting a group chat history](#Requesting-a-group-chat-history) | ||
| - [Requesting a public chat history](#Requesting-a-public-chat-history) | ||
| - [Requesting a community chat history](#Requesting-a-community-chat-history) | ||
|
|
||
| ## Abstract | ||
|
|
||
| When Store Nodes (aka Mailservers) are unavailable or faulty, short term history is lost. This spec proposes a solution for which short term history can be recovered through trusted contacts without relying on Store Nodes. It is not meant to replace Store Nodes or other solutions, but instead to complement them. | ||
|
|
||
| ### Modifications to Message Format | ||
|
|
||
| The `ApplicationMetadataMessage` is modified to include 3 new Types: | ||
|
|
||
| ``` | ||
| message ApplicationMetadataMessage { | ||
| // Signature of the payload field | ||
| bytes signature = 1; | ||
| // This is the encoded protobuf of the application level message, i.e ChatMessage | ||
| bytes payload = 2; | ||
|
|
||
| // The type of protobuf message sent | ||
| Type type = 3; | ||
|
|
||
| enum Type { | ||
| // ... | ||
| HISTORY_CAPABILITY = 42; | ||
| HISTORY_REQUEST = 43; | ||
| HISTORY_REPLY = 44; | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| ## Advertising Capabilities | ||
|
|
||
| - When a contact request is sent the sender MAY advertise its capabilities | ||
| - When a contact request is accepted the receiver MAY advertises its own capabilities | ||
|
|
||
| ``` | ||
| HistoryCapability { | ||
| uint64 clock = 1; | ||
| string contactChatId = 2 | ||
| map<string, int64> capability = 3; | ||
| } | ||
| ``` | ||
|
|
||
| `HistoryCapability.capability` has the mapping between chatIds and time in seconds. This indicates the contact is willing to send the chat history for last X seconds for that particular chatId. | ||
|
|
||
| ``` | ||
| { | ||
| "0x123": -1, // all available chat history | ||
| "0x234": 3600, // last 1h | ||
| "0x345": 300, // last 5 minutes | ||
| } | ||
| ``` | ||
|
|
||
| If no capabilities are advertised, it MUST be assumed that contact will not relay contact history. | ||
|
|
||
| When a user changes its capabilities, a change signal MUST be sent to contacts. | ||
|
|
||
| ## Requesting Chat history | ||
|
|
||
| The client chooses one of his online contacts at random that indicated capability to send the history for the target chat or community. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Does this mean individual contacts should be able to provide the history of an entire community? |
||
|
|
||
| **Request** | ||
|
|
||
| A `ChatMessage` with the ContentType `HISTORY` and the timestamp of the last known message in the 1 on 1 chat. | ||
|
|
||
| ``` | ||
| HistoryRequest { | ||
| uint64 clock = 1; | ||
| string contactChatId = 2 | ||
| uint64 requestedChatId = 3; | ||
| uint64 requestedLastTimestamp = 4; | ||
| } | ||
| ``` | ||
|
|
||
| **Response** | ||
|
|
||
| ``` | ||
| HistoryResponse { | ||
| uint64 clock = 1; | ||
| string contactChatId = 2 | ||
| uint64 requestedChatId = 3; | ||
| string message = 4; | ||
| } | ||
| ``` | ||
|
|
||
| `HistoryResponse.message` contains the encoded original message. | ||
| A `HistoryResponse` is sent for each message in the requested time range. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I feel like this could be burdensome. Why not package chats into a blob and send that?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We can potentially turn these messages into
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To add to this, even without message archives and bundling, I think messages have to be sent as waku messages. That means, when users switch between different capabilities, we need to think about how to handle this. Do we start/stop storing waku messages when it's turned on/off? Do we just always store waku messages, in which case turning it on/off won't be an issue because all messages always exist? |
||
|
|
||
| ## Requesting 1 on 1 chat history | ||
|
|
||
| In this case, only 1 contact will be a match. If the contact has not advertised intention to send the chat history, no request should be sent. | ||
|
|
||
| ## Requesting a group chat history | ||
|
|
||
| The client chooses one of the online contacts that are members in the group chat at random to request the group history and that has advertised intention to send the chat history of this group chat. | ||
| If no history is received during time X, then the client can choose another contact to request the history | ||
|
|
||
| ## Requesting a public chat history | ||
|
|
||
| The client chooses one of the online contacts that displayed intentions to send chat history for the public chat in question. | ||
|
|
||
|
|
||
| ## Requesting a community chat history | ||
|
|
||
| The client chooses one of the online contacts that displayed intentions to send chat history for the community in question. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In all of these scenarios, status nodes will have to store each message as waku message. Also, it should be taking into account here in the spec that this in fact needs to happen (waku messages need to be stored separately).
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ah this ties into the fact that we should have a
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For reference and context, the Community History Archive Protocol requires the same #164
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
|
|
||
| ## Copyright | ||
|
|
||
| Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). | ||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does "all available chat history" mean here? Is this just whatever is in the local database of the contact?