Skip to content
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
133 changes: 133 additions & 0 deletions docs/draft/17-contact-history.md
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
Copy link
Member

@0x-r4bbit 0x-r4bbit Mar 11, 2022

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?

"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.
Copy link
Member

@0x-r4bbit 0x-r4bbit Mar 11, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

target chat or community

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.
Copy link
Contributor

Choose a reason for hiding this comment

The 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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can potentially turn these messages into WakuMessageArchives, marshall them and send them across the wire. However, that requires individual nodes to store messages as waku messages (instead of just application messages), which means potentially they'll double every message stored (in the worst case)

Copy link
Member

Choose a reason for hiding this comment

The 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.
Copy link
Member

Choose a reason for hiding this comment

The 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.
Something to take into consideration as this will have an impact on storage.

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).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah this ties into the fact that we should have a dont-store flag on waku-2, I think there's should be an issue somewhere about it in the vac repos

Copy link
Member

Choose a reason for hiding this comment

The 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

Copy link
Member

Choose a reason for hiding this comment

The 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/).