Move to protobuf for Message type (#1706)
* Use a single Message type `v1/message.go` and `message.go` are the same now, and they embed `protobuf.ChatMessage`
* Use `SendChatMessage` for sending chat messages, this is basically the old `Send` but a bit more flexible so we can send different message types (stickers,commands), and not just text.
* Remove dedup from services/shhext. Because now we process in status-protocol, dedup makes less sense, as those messages are going to be processed anyway, so removing for now, we can re-evaluate if bringing it to status-go or not.
* Change the various retrieveX method to a single one:
`RetrieveAll` will be processing those messages that it can process (Currently only `Message`), and return the rest in `RawMessages` (still transit). The format for the response is:
`Chats`: -> The chats updated by receiving the message
`Messages`: -> The messages retrieved (already matched to a chat)
`Contacts`: -> The contacts updated by the messages
`RawMessages` -> Anything else that can't be parsed, eventually as we move everything to status-protocol-go this will go away.
2019-12-05 16:25:34 +00:00
|
|
|
syntax = "proto3";
|
|
|
|
|
2021-08-06 15:40:23 +00:00
|
|
|
option go_package = "./;protobuf";
|
Move to protobuf for Message type (#1706)
* Use a single Message type `v1/message.go` and `message.go` are the same now, and they embed `protobuf.ChatMessage`
* Use `SendChatMessage` for sending chat messages, this is basically the old `Send` but a bit more flexible so we can send different message types (stickers,commands), and not just text.
* Remove dedup from services/shhext. Because now we process in status-protocol, dedup makes less sense, as those messages are going to be processed anyway, so removing for now, we can re-evaluate if bringing it to status-go or not.
* Change the various retrieveX method to a single one:
`RetrieveAll` will be processing those messages that it can process (Currently only `Message`), and return the rest in `RawMessages` (still transit). The format for the response is:
`Chats`: -> The chats updated by receiving the message
`Messages`: -> The messages retrieved (already matched to a chat)
`Contacts`: -> The contacts updated by the messages
`RawMessages` -> Anything else that can't be parsed, eventually as we move everything to status-protocol-go this will go away.
2019-12-05 16:25:34 +00:00
|
|
|
package protobuf;
|
|
|
|
|
2020-07-25 11:13:23 +00:00
|
|
|
import "enums.proto";
|
|
|
|
|
Move to protobuf for Message type (#1706)
* Use a single Message type `v1/message.go` and `message.go` are the same now, and they embed `protobuf.ChatMessage`
* Use `SendChatMessage` for sending chat messages, this is basically the old `Send` but a bit more flexible so we can send different message types (stickers,commands), and not just text.
* Remove dedup from services/shhext. Because now we process in status-protocol, dedup makes less sense, as those messages are going to be processed anyway, so removing for now, we can re-evaluate if bringing it to status-go or not.
* Change the various retrieveX method to a single one:
`RetrieveAll` will be processing those messages that it can process (Currently only `Message`), and return the rest in `RawMessages` (still transit). The format for the response is:
`Chats`: -> The chats updated by receiving the message
`Messages`: -> The messages retrieved (already matched to a chat)
`Contacts`: -> The contacts updated by the messages
`RawMessages` -> Anything else that can't be parsed, eventually as we move everything to status-protocol-go this will go away.
2019-12-05 16:25:34 +00:00
|
|
|
message StickerMessage {
|
|
|
|
string hash = 1;
|
|
|
|
int32 pack = 2;
|
|
|
|
}
|
|
|
|
|
2020-05-13 13:16:17 +00:00
|
|
|
message ImageMessage {
|
|
|
|
bytes payload = 1;
|
|
|
|
ImageType type = 2;
|
|
|
|
}
|
|
|
|
|
2020-06-17 18:55:49 +00:00
|
|
|
message AudioMessage {
|
|
|
|
bytes payload = 1;
|
|
|
|
AudioType type = 2;
|
2020-06-23 14:30:39 +00:00
|
|
|
uint64 duration_ms = 3;
|
2020-06-17 18:55:49 +00:00
|
|
|
enum AudioType {
|
|
|
|
UNKNOWN_AUDIO_TYPE = 0;
|
|
|
|
AAC = 1;
|
|
|
|
AMR = 2;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-06-07 08:31:27 +00:00
|
|
|
message EditMessage {
|
|
|
|
uint64 clock = 1;
|
|
|
|
// Text of the message
|
|
|
|
string text = 2;
|
|
|
|
|
|
|
|
string chat_id = 3;
|
|
|
|
string message_id = 4;
|
|
|
|
|
|
|
|
// Grant for community edit messages
|
|
|
|
bytes grant = 5;
|
|
|
|
|
|
|
|
// The type of message (public/one-to-one/private-group-chat)
|
|
|
|
MessageType message_type = 6;
|
2022-10-05 17:54:47 +00:00
|
|
|
|
2022-10-07 07:05:02 +00:00
|
|
|
ChatMessage.ContentType content_type = 7;
|
2021-06-07 08:31:27 +00:00
|
|
|
}
|
|
|
|
|
2021-07-26 21:06:32 +00:00
|
|
|
message DeleteMessage {
|
|
|
|
uint64 clock = 1;
|
|
|
|
|
|
|
|
string chat_id = 2;
|
|
|
|
string message_id = 3;
|
|
|
|
|
|
|
|
// Grant for community delete messages
|
|
|
|
bytes grant = 4;
|
|
|
|
|
|
|
|
// The type of message (public/one-to-one/private-group-chat)
|
|
|
|
MessageType message_type = 5;
|
|
|
|
}
|
|
|
|
|
2022-09-28 11:42:17 +00:00
|
|
|
message DeleteForMeMessage {
|
|
|
|
uint64 clock = 1;
|
|
|
|
string message_id = 2;
|
|
|
|
}
|
|
|
|
|
feat: introduce messenger APIs to extract discord channels
As part of the new Discord <-> Status Community Import functionality,
we're adding an API that extracts all discord categories and channels
from a previously exported discord export file.
These APIs can be used in clients to show the user what categories and
channels will be imported later on.
There are two APIs:
1. `Messenger.ExtractDiscordCategoriesAndChannels(filesToimport
[]string) (*MessengerResponse, map[string]*discord.ImportError)`
This takes a list of exported discord export (JSON) files (typically one per
channel), reads them, and extracts the categories and channels into
dedicated data structures (`[]DiscordChannel` and `[]DiscordCategory`)
It also returns the oldest message timestamp found in all extracted
channels.
The API is synchronous and returns the extracted data as
a `*MessengerResponse`. This allows to make the API available
status-go's RPC interface.
The error case is a `map[string]*discord.ImportError` where each key
is a file path of a JSON file that we tried to extract data from, and
the value a `discord.ImportError` which holds an error message and an
error code, allowing for distinguishing between "critical" errors and
"non-critical" errors.
2. `Messenger.RequestExtractDiscordCategoriesAndChannels(filesToImport
[]string)`
This is the asynchronous counterpart to
`ExtractDiscordCategoriesAndChannels`. The reason this API has been
added is because discord servers can have a lot of message and
channel data, which causes `ExtractDiscordCategoriesAndChannels` to
block the thread for too long, making apps potentially feel like they
are stuck.
This API runs inside a go routine, eventually calls
`ExtractDiscordCategoriesAndChannels`, and then emits a newly
introduced `DiscordCategoriesAndChannelsExtractedSignal` that clients
can react to.
Failure of extraction has to be determined by the
`discord.ImportErrors` emitted by the signal.
**A note about exported discord history files**
We expect users to export their discord histories via the
[DiscordChatExporter](https://github.com/Tyrrrz/DiscordChatExporter/wiki/GUI%2C-CLI-and-Formats-explained#exportguild)
tool. The tool allows to export the data in different formats, such as
JSON, HTML and CSV.
We expect users to have their data exported as JSON.
Closes: https://github.com/status-im/status-desktop/issues/6690
2022-07-13 09:33:53 +00:00
|
|
|
message DiscordMessage {
|
|
|
|
string id = 1;
|
|
|
|
string type = 2;
|
|
|
|
string timestamp = 3;
|
|
|
|
string timestampEdited = 4;
|
|
|
|
string content = 5;
|
|
|
|
DiscordMessageAuthor author = 6;
|
2022-08-04 16:16:56 +00:00
|
|
|
DiscordMessageReference reference = 7;
|
2022-09-20 09:13:44 +00:00
|
|
|
repeated DiscordMessageAttachment attachments = 8;
|
feat: introduce messenger APIs to extract discord channels
As part of the new Discord <-> Status Community Import functionality,
we're adding an API that extracts all discord categories and channels
from a previously exported discord export file.
These APIs can be used in clients to show the user what categories and
channels will be imported later on.
There are two APIs:
1. `Messenger.ExtractDiscordCategoriesAndChannels(filesToimport
[]string) (*MessengerResponse, map[string]*discord.ImportError)`
This takes a list of exported discord export (JSON) files (typically one per
channel), reads them, and extracts the categories and channels into
dedicated data structures (`[]DiscordChannel` and `[]DiscordCategory`)
It also returns the oldest message timestamp found in all extracted
channels.
The API is synchronous and returns the extracted data as
a `*MessengerResponse`. This allows to make the API available
status-go's RPC interface.
The error case is a `map[string]*discord.ImportError` where each key
is a file path of a JSON file that we tried to extract data from, and
the value a `discord.ImportError` which holds an error message and an
error code, allowing for distinguishing between "critical" errors and
"non-critical" errors.
2. `Messenger.RequestExtractDiscordCategoriesAndChannels(filesToImport
[]string)`
This is the asynchronous counterpart to
`ExtractDiscordCategoriesAndChannels`. The reason this API has been
added is because discord servers can have a lot of message and
channel data, which causes `ExtractDiscordCategoriesAndChannels` to
block the thread for too long, making apps potentially feel like they
are stuck.
This API runs inside a go routine, eventually calls
`ExtractDiscordCategoriesAndChannels`, and then emits a newly
introduced `DiscordCategoriesAndChannelsExtractedSignal` that clients
can react to.
Failure of extraction has to be determined by the
`discord.ImportErrors` emitted by the signal.
**A note about exported discord history files**
We expect users to export their discord histories via the
[DiscordChatExporter](https://github.com/Tyrrrz/DiscordChatExporter/wiki/GUI%2C-CLI-and-Formats-explained#exportguild)
tool. The tool allows to export the data in different formats, such as
JSON, HTML and CSV.
We expect users to have their data exported as JSON.
Closes: https://github.com/status-im/status-desktop/issues/6690
2022-07-13 09:33:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
message DiscordMessageAuthor {
|
|
|
|
string id = 1;
|
|
|
|
string name = 2;
|
|
|
|
string discriminator = 3;
|
|
|
|
string nickname = 4;
|
|
|
|
string avatarUrl = 5;
|
2022-09-15 09:05:30 +00:00
|
|
|
bytes avatarImagePayload = 6;
|
|
|
|
string localUrl = 7;
|
feat: introduce messenger APIs to extract discord channels
As part of the new Discord <-> Status Community Import functionality,
we're adding an API that extracts all discord categories and channels
from a previously exported discord export file.
These APIs can be used in clients to show the user what categories and
channels will be imported later on.
There are two APIs:
1. `Messenger.ExtractDiscordCategoriesAndChannels(filesToimport
[]string) (*MessengerResponse, map[string]*discord.ImportError)`
This takes a list of exported discord export (JSON) files (typically one per
channel), reads them, and extracts the categories and channels into
dedicated data structures (`[]DiscordChannel` and `[]DiscordCategory`)
It also returns the oldest message timestamp found in all extracted
channels.
The API is synchronous and returns the extracted data as
a `*MessengerResponse`. This allows to make the API available
status-go's RPC interface.
The error case is a `map[string]*discord.ImportError` where each key
is a file path of a JSON file that we tried to extract data from, and
the value a `discord.ImportError` which holds an error message and an
error code, allowing for distinguishing between "critical" errors and
"non-critical" errors.
2. `Messenger.RequestExtractDiscordCategoriesAndChannels(filesToImport
[]string)`
This is the asynchronous counterpart to
`ExtractDiscordCategoriesAndChannels`. The reason this API has been
added is because discord servers can have a lot of message and
channel data, which causes `ExtractDiscordCategoriesAndChannels` to
block the thread for too long, making apps potentially feel like they
are stuck.
This API runs inside a go routine, eventually calls
`ExtractDiscordCategoriesAndChannels`, and then emits a newly
introduced `DiscordCategoriesAndChannelsExtractedSignal` that clients
can react to.
Failure of extraction has to be determined by the
`discord.ImportErrors` emitted by the signal.
**A note about exported discord history files**
We expect users to export their discord histories via the
[DiscordChatExporter](https://github.com/Tyrrrz/DiscordChatExporter/wiki/GUI%2C-CLI-and-Formats-explained#exportguild)
tool. The tool allows to export the data in different formats, such as
JSON, HTML and CSV.
We expect users to have their data exported as JSON.
Closes: https://github.com/status-im/status-desktop/issues/6690
2022-07-13 09:33:53 +00:00
|
|
|
}
|
2021-06-07 08:31:27 +00:00
|
|
|
|
2022-08-04 16:16:56 +00:00
|
|
|
message DiscordMessageReference {
|
|
|
|
string messageId = 1;
|
|
|
|
string channelId = 2;
|
|
|
|
string guildId = 3;
|
|
|
|
}
|
|
|
|
|
2022-09-20 09:13:44 +00:00
|
|
|
message DiscordMessageAttachment {
|
|
|
|
string id = 1;
|
|
|
|
string messageId = 2;
|
|
|
|
string url = 3;
|
|
|
|
string fileName = 4;
|
|
|
|
uint64 fileSizeBytes = 5;
|
|
|
|
string contentType = 6;
|
|
|
|
bytes payload = 7;
|
|
|
|
string localUrl = 8;
|
|
|
|
}
|
|
|
|
|
Move to protobuf for Message type (#1706)
* Use a single Message type `v1/message.go` and `message.go` are the same now, and they embed `protobuf.ChatMessage`
* Use `SendChatMessage` for sending chat messages, this is basically the old `Send` but a bit more flexible so we can send different message types (stickers,commands), and not just text.
* Remove dedup from services/shhext. Because now we process in status-protocol, dedup makes less sense, as those messages are going to be processed anyway, so removing for now, we can re-evaluate if bringing it to status-go or not.
* Change the various retrieveX method to a single one:
`RetrieveAll` will be processing those messages that it can process (Currently only `Message`), and return the rest in `RawMessages` (still transit). The format for the response is:
`Chats`: -> The chats updated by receiving the message
`Messages`: -> The messages retrieved (already matched to a chat)
`Contacts`: -> The contacts updated by the messages
`RawMessages` -> Anything else that can't be parsed, eventually as we move everything to status-protocol-go this will go away.
2019-12-05 16:25:34 +00:00
|
|
|
message ChatMessage {
|
|
|
|
// Lamport timestamp of the chat message
|
|
|
|
uint64 clock = 1;
|
2022-09-28 11:42:17 +00:00
|
|
|
// Unix timestamps in milliseconds, currently not used as we use whisper as
|
|
|
|
// more reliable, but here so that we don't rely on it
|
Move to protobuf for Message type (#1706)
* Use a single Message type `v1/message.go` and `message.go` are the same now, and they embed `protobuf.ChatMessage`
* Use `SendChatMessage` for sending chat messages, this is basically the old `Send` but a bit more flexible so we can send different message types (stickers,commands), and not just text.
* Remove dedup from services/shhext. Because now we process in status-protocol, dedup makes less sense, as those messages are going to be processed anyway, so removing for now, we can re-evaluate if bringing it to status-go or not.
* Change the various retrieveX method to a single one:
`RetrieveAll` will be processing those messages that it can process (Currently only `Message`), and return the rest in `RawMessages` (still transit). The format for the response is:
`Chats`: -> The chats updated by receiving the message
`Messages`: -> The messages retrieved (already matched to a chat)
`Contacts`: -> The contacts updated by the messages
`RawMessages` -> Anything else that can't be parsed, eventually as we move everything to status-protocol-go this will go away.
2019-12-05 16:25:34 +00:00
|
|
|
uint64 timestamp = 2;
|
|
|
|
// Text of the message
|
|
|
|
string text = 3;
|
|
|
|
// Id of the message that we are replying to
|
|
|
|
string response_to = 4;
|
|
|
|
// Ens name of the sender
|
|
|
|
string ens_name = 5;
|
|
|
|
// Chat id, this field is symmetric for public-chats and private group chats,
|
|
|
|
// but asymmetric in case of one-to-ones, as the sender will use the chat-id
|
|
|
|
// of the received, while the receiver will use the chat-id of the sender.
|
2022-09-28 11:42:17 +00:00
|
|
|
// Probably should be the concatenation of sender-pk & receiver-pk in
|
|
|
|
// alphabetical order
|
Move to protobuf for Message type (#1706)
* Use a single Message type `v1/message.go` and `message.go` are the same now, and they embed `protobuf.ChatMessage`
* Use `SendChatMessage` for sending chat messages, this is basically the old `Send` but a bit more flexible so we can send different message types (stickers,commands), and not just text.
* Remove dedup from services/shhext. Because now we process in status-protocol, dedup makes less sense, as those messages are going to be processed anyway, so removing for now, we can re-evaluate if bringing it to status-go or not.
* Change the various retrieveX method to a single one:
`RetrieveAll` will be processing those messages that it can process (Currently only `Message`), and return the rest in `RawMessages` (still transit). The format for the response is:
`Chats`: -> The chats updated by receiving the message
`Messages`: -> The messages retrieved (already matched to a chat)
`Contacts`: -> The contacts updated by the messages
`RawMessages` -> Anything else that can't be parsed, eventually as we move everything to status-protocol-go this will go away.
2019-12-05 16:25:34 +00:00
|
|
|
string chat_id = 6;
|
|
|
|
|
|
|
|
// The type of message (public/one-to-one/private-group-chat)
|
|
|
|
MessageType message_type = 7;
|
|
|
|
// The type of the content of the message
|
|
|
|
ContentType content_type = 8;
|
|
|
|
|
|
|
|
oneof payload {
|
|
|
|
StickerMessage sticker = 9;
|
2020-05-13 13:16:17 +00:00
|
|
|
ImageMessage image = 10;
|
2020-06-17 18:55:49 +00:00
|
|
|
AudioMessage audio = 11;
|
2020-11-18 09:16:51 +00:00
|
|
|
bytes community = 12;
|
2022-08-04 16:16:56 +00:00
|
|
|
DiscordMessage discord_message = 99;
|
Move to protobuf for Message type (#1706)
* Use a single Message type `v1/message.go` and `message.go` are the same now, and they embed `protobuf.ChatMessage`
* Use `SendChatMessage` for sending chat messages, this is basically the old `Send` but a bit more flexible so we can send different message types (stickers,commands), and not just text.
* Remove dedup from services/shhext. Because now we process in status-protocol, dedup makes less sense, as those messages are going to be processed anyway, so removing for now, we can re-evaluate if bringing it to status-go or not.
* Change the various retrieveX method to a single one:
`RetrieveAll` will be processing those messages that it can process (Currently only `Message`), and return the rest in `RawMessages` (still transit). The format for the response is:
`Chats`: -> The chats updated by receiving the message
`Messages`: -> The messages retrieved (already matched to a chat)
`Contacts`: -> The contacts updated by the messages
`RawMessages` -> Anything else that can't be parsed, eventually as we move everything to status-protocol-go this will go away.
2019-12-05 16:25:34 +00:00
|
|
|
}
|
|
|
|
|
2020-11-18 09:16:51 +00:00
|
|
|
// Grant for community chat messages
|
|
|
|
bytes grant = 13;
|
|
|
|
|
2022-02-17 15:13:10 +00:00
|
|
|
// Message author's display name, introduced in version 1
|
|
|
|
string display_name = 14;
|
|
|
|
|
2022-01-18 16:31:34 +00:00
|
|
|
ContactRequestSignature sent_contact_request_signature = 15;
|
|
|
|
ContactRequestSignature received_contact_request_signature = 16;
|
|
|
|
bool contact_message = 17;
|
|
|
|
|
Move to protobuf for Message type (#1706)
* Use a single Message type `v1/message.go` and `message.go` are the same now, and they embed `protobuf.ChatMessage`
* Use `SendChatMessage` for sending chat messages, this is basically the old `Send` but a bit more flexible so we can send different message types (stickers,commands), and not just text.
* Remove dedup from services/shhext. Because now we process in status-protocol, dedup makes less sense, as those messages are going to be processed anyway, so removing for now, we can re-evaluate if bringing it to status-go or not.
* Change the various retrieveX method to a single one:
`RetrieveAll` will be processing those messages that it can process (Currently only `Message`), and return the rest in `RawMessages` (still transit). The format for the response is:
`Chats`: -> The chats updated by receiving the message
`Messages`: -> The messages retrieved (already matched to a chat)
`Contacts`: -> The contacts updated by the messages
`RawMessages` -> Anything else that can't be parsed, eventually as we move everything to status-protocol-go this will go away.
2019-12-05 16:25:34 +00:00
|
|
|
enum ContentType {
|
2019-12-02 15:34:05 +00:00
|
|
|
UNKNOWN_CONTENT_TYPE = 0;
|
|
|
|
TEXT_PLAIN = 1;
|
|
|
|
STICKER = 2;
|
|
|
|
STATUS = 3;
|
|
|
|
EMOJI = 4;
|
2020-01-10 18:59:01 +00:00
|
|
|
TRANSACTION_COMMAND = 5;
|
2020-01-28 11:16:28 +00:00
|
|
|
// Only local
|
|
|
|
SYSTEM_MESSAGE_CONTENT_PRIVATE_GROUP = 6;
|
2020-05-13 13:16:17 +00:00
|
|
|
IMAGE = 7;
|
2020-06-17 18:55:49 +00:00
|
|
|
AUDIO = 8;
|
2020-11-18 09:16:51 +00:00
|
|
|
COMMUNITY = 9;
|
2021-03-25 15:15:22 +00:00
|
|
|
// Only local
|
|
|
|
SYSTEM_MESSAGE_GAP = 10;
|
2022-01-18 16:31:34 +00:00
|
|
|
CONTACT_REQUEST = 11;
|
2022-08-04 16:16:56 +00:00
|
|
|
DISCORD_MESSAGE = 12;
|
2022-08-31 14:41:58 +00:00
|
|
|
IDENTITY_VERIFICATION = 13;
|
Move to protobuf for Message type (#1706)
* Use a single Message type `v1/message.go` and `message.go` are the same now, and they embed `protobuf.ChatMessage`
* Use `SendChatMessage` for sending chat messages, this is basically the old `Send` but a bit more flexible so we can send different message types (stickers,commands), and not just text.
* Remove dedup from services/shhext. Because now we process in status-protocol, dedup makes less sense, as those messages are going to be processed anyway, so removing for now, we can re-evaluate if bringing it to status-go or not.
* Change the various retrieveX method to a single one:
`RetrieveAll` will be processing those messages that it can process (Currently only `Message`), and return the rest in `RawMessages` (still transit). The format for the response is:
`Chats`: -> The chats updated by receiving the message
`Messages`: -> The messages retrieved (already matched to a chat)
`Contacts`: -> The contacts updated by the messages
`RawMessages` -> Anything else that can't be parsed, eventually as we move everything to status-protocol-go this will go away.
2019-12-05 16:25:34 +00:00
|
|
|
}
|
|
|
|
}
|
2022-01-18 16:31:34 +00:00
|
|
|
|
|
|
|
message ContactRequestSignature {
|
|
|
|
bytes signature = 1;
|
|
|
|
uint64 timestamp = 2;
|
|
|
|
}
|