2019-11-21 16:19:22 +00:00
package protocol
2019-08-06 21:50:13 +00:00
import (
2019-08-20 11:20:25 +00:00
"context"
2019-08-06 21:50:13 +00:00
"database/sql"
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
"encoding/json"
2019-08-06 21:50:13 +00:00
"fmt"
2022-09-20 09:13:44 +00:00
"sort"
2019-08-06 21:50:13 +00:00
"strings"
2020-09-01 13:27:01 +00:00
"github.com/status-im/status-go/protocol/common"
2020-01-02 09:10:19 +00:00
"github.com/status-im/status-go/protocol/protobuf"
2019-08-06 21:50:13 +00:00
)
2022-08-25 17:20:26 +00:00
var basicMessagesSelectQuery = `
SELECT % s % s
FROM user_messages m1
LEFT JOIN user_messages m2
2023-01-11 21:09:40 +00:00
ON m1 . response_to = m2 . id
2022-08-25 17:20:26 +00:00
LEFT JOIN contacts c
ON m1 . source = c . id
LEFT JOIN discord_messages dm
ON m1 . discord_message_id = dm . id
LEFT JOIN discord_message_authors dm_author
ON dm . author_id = dm_author . id
2022-09-20 09:13:44 +00:00
LEFT JOIN discord_message_attachments dm_attachment
ON dm . id = dm_attachment . discord_message_id
2023-01-13 15:28:49 +00:00
LEFT JOIN discord_messages m2_dm
ON m2 . discord_message_id = m2_dm . id
LEFT JOIN discord_message_authors m2_dm_author
ON m2_dm . author_id = m2_dm_author . id
2022-08-25 17:20:26 +00:00
`
2022-09-29 11:50:23 +00:00
var basicInsertDiscordMessageAuthorQuery = ` INSERT OR REPLACE INTO discord_message_authors(id,name,discriminator,nickname,avatar_url, avatar_image_payload) VALUES (?,?,?,?,?,?) `
2022-08-25 17:20:26 +00:00
var cursor = "substr('0000000000000000000000000000000000000000000000000000000000000000' || m1.clock_value, -64, 64) || m1.id"
var cursorField = cursor + " as cursor"
func ( db sqlitePersistence ) buildMessagesQueryWithAdditionalFields ( additionalSelectFields , whereAndTheRest string ) string {
allFields := db . tableUserMessagesAllFieldsJoin ( )
if additionalSelectFields != "" {
additionalSelectFields = "," + additionalSelectFields
}
base := fmt . Sprintf ( basicMessagesSelectQuery , allFields , additionalSelectFields )
return base + " " + whereAndTheRest
}
func ( db sqlitePersistence ) buildMessagesQuery ( whereAndTheRest string ) string {
return db . buildMessagesQueryWithAdditionalFields ( "" , whereAndTheRest )
}
2020-05-20 12:16:12 +00:00
func ( db sqlitePersistence ) tableUserMessagesAllFields ( ) string {
2019-08-06 21:50:13 +00:00
return ` id ,
whisper_timestamp ,
source ,
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
text ,
2019-08-06 21:50:13 +00:00
content_type ,
username ,
timestamp ,
chat_id ,
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
local_chat_id ,
2019-08-06 21:50:13 +00:00
message_type ,
clock_value ,
seen ,
2019-08-20 11:20:25 +00:00
outgoing_status ,
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
parsed_text ,
sticker_pack ,
sticker_hash ,
2020-05-13 13:16:17 +00:00
image_payload ,
image_type ,
2022-12-14 12:25:45 +00:00
album_id ,
2023-03-30 10:02:20 +00:00
album_images_count ,
2023-01-12 09:43:14 +00:00
image_width ,
image_height ,
2020-05-13 13:16:17 +00:00
image_base64 ,
2020-06-17 18:55:49 +00:00
audio_payload ,
audio_type ,
2020-06-23 14:30:39 +00:00
audio_duration_ms ,
2020-06-17 18:55:49 +00:00
audio_base64 ,
2020-11-18 09:16:51 +00:00
community_id ,
2020-09-01 10:34:28 +00:00
mentions ,
2020-10-27 17:35:28 +00:00
links ,
URL unfurling (initial implementation) (#3471)
This is the initial implementation for the new URL unfurling requirements. The
most important one is that only the message sender will pay the privacy cost for
unfurling and extracting metadata from websites. Once the message is sent, the
unfurled data will be stored at the protocol level and receivers will just
profit and happily decode the metadata to render it.
Further development of this URL unfurling capability will be mostly guided by
issues created on clients. For the moment in status-mobile:
https://github.com/status-im/status-mobile/labels/url-preview
- https://github.com/status-im/status-mobile/issues/15918
- https://github.com/status-im/status-mobile/issues/15917
- https://github.com/status-im/status-mobile/issues/15910
- https://github.com/status-im/status-mobile/issues/15909
- https://github.com/status-im/status-mobile/issues/15908
- https://github.com/status-im/status-mobile/issues/15906
- https://github.com/status-im/status-mobile/issues/15905
### Terminology
In the code, I've tried to stick to the word "unfurl URL" to really mean the
process of extracting metadata from a website, sort of lower level. I use "link
preview" to mean a higher level structure which is enriched by unfurled data.
"link preview" is also how designers refer to it.
### User flows
1. Carol needs to see link previews while typing in the chat input field. Notice
from the diagram nothing is persisted and that status-go endpoints are
essentially stateless.
```
#+begin_src plantuml :results verbatim
Client->>Server: Call wakuext_getTextURLs
Server-->>Client: Normalized URLs
Client->>Client: Render cached unfurled URLs
Client->>Server: Unfurl non-cached URLs.\nCall wakuext_unfurlURLs
Server->>Website: Fetch metadata
Website-->>Server: Metadata (thumbnail URL, title, etc)
Server->>Website: Fetch thumbnail
Server->>Website: Fetch favicon
Website-->>Server: Favicon bytes
Website-->>Server: Thumbnail bytes
Server->>Server: Decode & process images
Server-->>Client: Unfurled data (thumbnail data URI, etc)
#+end_src
```
```
,------. ,------. ,-------.
|Client| |Server| |Website|
`--+---' `--+---' `---+---'
| Call wakuext_getTextURLs | |
| ---------------------------------------> |
| | |
| Normalized URLs | |
| <- - - - - - - - - - - - - - - - - - - - |
| | |
|----. | |
| | Render cached unfurled URLs | |
|<---' | |
| | |
| Unfurl non-cached URLs. | |
| Call wakuext_unfurlURLs | |
| ---------------------------------------> |
| | |
| | Fetch metadata |
| | ------------------------------------>
| | |
| | Metadata (thumbnail URL, title, etc)|
| | <- - - - - - - - - - - - - - - - - -
| | |
| | Fetch thumbnail |
| | ------------------------------------>
| | |
| | Fetch favicon |
| | ------------------------------------>
| | |
| | Favicon bytes |
| | <- - - - - - - - - - - - - - - - - -
| | |
| | Thumbnail bytes |
| | <- - - - - - - - - - - - - - - - - -
| | |
| |----. |
| | | Decode & process images |
| |<---' |
| | |
| Unfurled data (thumbnail data URI, etc)| |
| <- - - - - - - - - - - - - - - - - - - - |
,--+---. ,--+---. ,---+---.
|Client| |Server| |Website|
`------' `------' `-------'
```
2. Carol sends the text message with link previews in the RPC request
wakuext_sendChatMessages. status-go assumes the link previews are good
because it can't and shouldn't attempt to re-unfurl them.
```
#+begin_src plantuml :results verbatim
Client->>Server: Call wakuext_sendChatMessages
Server->>Server: Transform link previews to\nbe proto-marshalled
Server->DB: Write link previews serialized as JSON
Server-->>Client: Updated message response
#+end_src
```
```
,------. ,------. ,--.
|Client| |Server| |DB|
`--+---' `--+---' `+-'
| Call wakuext_sendChatMessages| |
| -----------------------------> |
| | |
| |----. |
| | | Transform link previews to |
| |<---' be proto-marshalled |
| | |
| | |
| | Write link previews serialized as JSON|
| | -------------------------------------->
| | |
| Updated message response | |
| <- - - - - - - - - - - - - - - |
,--+---. ,--+---. ,+-.
|Client| |Server| |DB|
`------' `------' `--'
```
3. The message was sent over waku and persisted locally in Carol's device. She
should now see the link previews in the chat history. There can be many link
previews shared by other chat members, therefore it is important to serve the
assets via the media server to avoid overloading the ReactNative bridge with
lots of big JSON payloads containing base64 encoded data URIs (maybe this
concern is meaningless for desktop). When a client is rendering messages with
link previews, they will have the field linkPreviews, and the thumbnail URL
will point to the local media server.
```
#+begin_src plantuml :results verbatim
Client->>Server: GET /link-preview/thumbnail (media server)
Server->>DB: Read from user_messages.unfurled_links
Server->Server: Unmarshal JSON
Server-->>Client: HTTP Content-Type: image/jpeg/etc
#+end_src
```
```
,------. ,------. ,--.
|Client| |Server| |DB|
`--+---' `--+---' `+-'
| GET /link-preview/thumbnail (media server)| |
| ------------------------------------------> |
| | |
| | Read from user_messages.unfurled_links|
| | -------------------------------------->
| | |
| |----. |
| | | Unmarshal JSON |
| |<---' |
| | |
| HTTP Content-Type: image/jpeg/etc | |
| <- - - - - - - - - - - - - - - - - - - - - |
,--+---. ,--+---. ,+-.
|Client| |Server| |DB|
`------' `------' `--'
```
### Some limitations of the current implementation
The following points will become separate issues in status-go that I'll work on
over the next couple weeks. In no order of importance:
- Improve how multiple links are fetched; retries on failure and testing how
unfurling behaves around the timeout limits (deterministically, not by making
real HTTP calls as I did). https://github.com/status-im/status-go/issues/3498
- Unfurl favicons and store them in the protobuf too.
- For this PR, I added unfurling support only for websites with OpenGraph
https://ogp.me/ meta tags. Other unfurlers will be implemented on demand. The
next one will probably be for oEmbed https://oembed.com/, the protocol
supported by YouTube, for example.
- Resize and/or compress thumbnails (and favicons). Often times, thumbnails are
huge for the purposes of link previews. There is already support for
compressing JPEGs in status-go, but I prefer to work with compression in a
separate PR because I'd like to also solve the problem for PNGs (probably
convert them to JPEGs, plus compress them). This would be a safe choice for
thumbnails, favicons not so much because transparency is desirable.
- Editing messages is not yet supported.
- I haven't coded any artificial limit on the number of previews or on the size
of the thumbnail payload. This will be done in a separate issue. I have heard
the ideal solution may be to split messages into smaller chunks of ~125 KiB
because of libp2p, but that might be too complicated at this stage of the
product (?).
- Link preview deletion.
- For the moment, OpenGraph metadata is extracted by requesting data for the
English language (and fallback to whatever is available). In the future, we'll
want to unfurl by respecting the user's local device language. Some websites,
like GoDaddy, are already localized based on the device's IP, but many aren't.
- The website's description text should be limited by a certain number of
characters, especially because it's outside our control. Exactly how much has
not been decided yet, so it'll be done separately.
- URL normalization can be tricky, so I implemented only the basics to help with
caching. For example, the url https://status.im and HTTPS://status.im are
considered identical. Also, a URL is considered valid for unfurling if its TLD
exists according to publicsuffix.EffectiveTLDPlusOne. This was essential,
otherwise the default Go url.Parse approach would consider many invalid URLs
valid, and thus the server would waste resources trying to unfurl the
unfurleable.
### Other requirements
- If the message is edited, the link previews should reflect the edited text,
not the original one. This has been aligned with the design team as well.
- If the website's thumbnail or the favicon can't be fetched, just ignore them.
The only mandatory piece of metadata is the website's title and URL.
- Link previews in clients should be generated in near real-time, that is, as
the user types, previews are updated. In mobile this performs very well, and
it's what other clients like WhatsApp, Telegram, and Facebook do.
### Decisions
- While the user typing in the input field, the client is constantly (debounced)
asking status-go to parse the text and extract normalized URLs and then the
client checks if they're already in its in-memory cache. If they are, no RPC
call is made. I chose this approach to achieve the best possible performance
in mobile and avoid the whole RPC overhead, since the chat experience is
already not smooth enough. The mobile client uses URLs as cache keys in a
hashmap, i.e. if the key is present, it means the preview is readily available
(naive, but good enough for now). This decision also gave me more flexibility
to find the best UX at this stage of the feature.
- Due to the requirement that users should be able to see independent loading
indicators for each link preview, when status-go can't unfurl a URL, it
doesn't return it in the response.
- As an initial implementation, I added the BLOB column unfurled_links to the
user_messages table. The preview data is then serialized as JSON before being
stored in this column. I felt that creating a separate table and the related
code for this initial PR would be inconvenient. Is that reasonable to you?
Once things stabilize I can create a proper table if we want to avoid this
kind of solution with serialized columns.
2023-05-18 18:43:06 +00:00
unfurled_links ,
2020-01-10 18:59:01 +00:00
command_id ,
command_value ,
command_from ,
command_address ,
command_contract ,
command_transaction_hash ,
command_state ,
command_signature ,
Add replies to messages
Currently replies to messages are handled in status-react.
This causes some issues with the fact that sometimes replies might come
out of order, they might be offloaded to the database etc.
This commit changes the behavior so that status-go always returns the
replies, and in case a reply comes out of order (first the reply, later
the message being replied to), it will include in the messages the
updated message.
It also adds some fields (RTL,Replace,LineCount) to the database which
were not previously saved, resulting in some potential bugs.
The method that we use to pull replies is currently a bit naive, we just
pull all the message again from the database, but has the advantage of
being simple. It will go through performance testing to make sure
performnace are acceptable, if so I think it's reasonable to avoid some
complexity.
2020-04-08 13:42:02 +00:00
replace_message ,
2021-06-07 08:31:27 +00:00
edited_at ,
2021-07-26 21:06:32 +00:00
deleted ,
2023-02-01 00:57:35 +00:00
deleted_by ,
2022-09-28 11:42:17 +00:00
deleted_for_me ,
Add replies to messages
Currently replies to messages are handled in status-react.
This causes some issues with the fact that sometimes replies might come
out of order, they might be offloaded to the database etc.
This commit changes the behavior so that status-go always returns the
replies, and in case a reply comes out of order (first the reply, later
the message being replied to), it will include in the messages the
updated message.
It also adds some fields (RTL,Replace,LineCount) to the database which
were not previously saved, resulting in some potential bugs.
The method that we use to pull replies is currently a bit naive, we just
pull all the message again from the database, but has the advantage of
being simple. It will go through performance testing to make sure
performnace are acceptable, if so I think it's reasonable to avoid some
complexity.
2020-04-08 13:42:02 +00:00
rtl ,
line_count ,
2021-03-25 15:15:22 +00:00
response_to ,
gap_from ,
2021-05-25 09:40:02 +00:00
gap_to ,
2022-01-18 16:31:34 +00:00
contact_request_state ,
2022-08-31 14:41:58 +00:00
contact_verification_status ,
2022-08-04 16:16:56 +00:00
mentioned ,
2023-01-10 17:59:32 +00:00
replied ,
2022-08-04 16:16:56 +00:00
discord_message_id `
2019-08-20 11:20:25 +00:00
}
2020-05-20 12:16:12 +00:00
func ( db sqlitePersistence ) tableUserMessagesAllFieldsJoin ( ) string {
2019-08-20 11:20:25 +00:00
return ` m1 . id ,
m1 . whisper_timestamp ,
m1 . source ,
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
m1 . text ,
2019-08-20 11:20:25 +00:00
m1 . content_type ,
m1 . username ,
m1 . timestamp ,
m1 . chat_id ,
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
m1 . local_chat_id ,
2019-08-20 11:20:25 +00:00
m1 . message_type ,
m1 . clock_value ,
m1 . seen ,
m1 . outgoing_status ,
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
m1 . parsed_text ,
m1 . sticker_pack ,
m1 . sticker_hash ,
2022-02-24 16:08:44 +00:00
m1 . image_payload ,
2022-03-10 21:05:17 +00:00
m1 . image_type ,
2022-12-14 15:34:03 +00:00
COALESCE ( m1 . album_id , "" ) ,
2023-03-30 10:02:20 +00:00
COALESCE ( m1 . album_images_count , 0 ) ,
2023-01-12 09:43:14 +00:00
COALESCE ( m1 . image_width , 0 ) ,
COALESCE ( m1 . image_height , 0 ) ,
2020-07-30 06:26:19 +00:00
COALESCE ( m1 . audio_duration_ms , 0 ) ,
2020-11-18 09:16:51 +00:00
m1 . community_id ,
2020-09-01 10:34:28 +00:00
m1 . mentions ,
2020-10-27 17:35:28 +00:00
m1 . links ,
URL unfurling (initial implementation) (#3471)
This is the initial implementation for the new URL unfurling requirements. The
most important one is that only the message sender will pay the privacy cost for
unfurling and extracting metadata from websites. Once the message is sent, the
unfurled data will be stored at the protocol level and receivers will just
profit and happily decode the metadata to render it.
Further development of this URL unfurling capability will be mostly guided by
issues created on clients. For the moment in status-mobile:
https://github.com/status-im/status-mobile/labels/url-preview
- https://github.com/status-im/status-mobile/issues/15918
- https://github.com/status-im/status-mobile/issues/15917
- https://github.com/status-im/status-mobile/issues/15910
- https://github.com/status-im/status-mobile/issues/15909
- https://github.com/status-im/status-mobile/issues/15908
- https://github.com/status-im/status-mobile/issues/15906
- https://github.com/status-im/status-mobile/issues/15905
### Terminology
In the code, I've tried to stick to the word "unfurl URL" to really mean the
process of extracting metadata from a website, sort of lower level. I use "link
preview" to mean a higher level structure which is enriched by unfurled data.
"link preview" is also how designers refer to it.
### User flows
1. Carol needs to see link previews while typing in the chat input field. Notice
from the diagram nothing is persisted and that status-go endpoints are
essentially stateless.
```
#+begin_src plantuml :results verbatim
Client->>Server: Call wakuext_getTextURLs
Server-->>Client: Normalized URLs
Client->>Client: Render cached unfurled URLs
Client->>Server: Unfurl non-cached URLs.\nCall wakuext_unfurlURLs
Server->>Website: Fetch metadata
Website-->>Server: Metadata (thumbnail URL, title, etc)
Server->>Website: Fetch thumbnail
Server->>Website: Fetch favicon
Website-->>Server: Favicon bytes
Website-->>Server: Thumbnail bytes
Server->>Server: Decode & process images
Server-->>Client: Unfurled data (thumbnail data URI, etc)
#+end_src
```
```
,------. ,------. ,-------.
|Client| |Server| |Website|
`--+---' `--+---' `---+---'
| Call wakuext_getTextURLs | |
| ---------------------------------------> |
| | |
| Normalized URLs | |
| <- - - - - - - - - - - - - - - - - - - - |
| | |
|----. | |
| | Render cached unfurled URLs | |
|<---' | |
| | |
| Unfurl non-cached URLs. | |
| Call wakuext_unfurlURLs | |
| ---------------------------------------> |
| | |
| | Fetch metadata |
| | ------------------------------------>
| | |
| | Metadata (thumbnail URL, title, etc)|
| | <- - - - - - - - - - - - - - - - - -
| | |
| | Fetch thumbnail |
| | ------------------------------------>
| | |
| | Fetch favicon |
| | ------------------------------------>
| | |
| | Favicon bytes |
| | <- - - - - - - - - - - - - - - - - -
| | |
| | Thumbnail bytes |
| | <- - - - - - - - - - - - - - - - - -
| | |
| |----. |
| | | Decode & process images |
| |<---' |
| | |
| Unfurled data (thumbnail data URI, etc)| |
| <- - - - - - - - - - - - - - - - - - - - |
,--+---. ,--+---. ,---+---.
|Client| |Server| |Website|
`------' `------' `-------'
```
2. Carol sends the text message with link previews in the RPC request
wakuext_sendChatMessages. status-go assumes the link previews are good
because it can't and shouldn't attempt to re-unfurl them.
```
#+begin_src plantuml :results verbatim
Client->>Server: Call wakuext_sendChatMessages
Server->>Server: Transform link previews to\nbe proto-marshalled
Server->DB: Write link previews serialized as JSON
Server-->>Client: Updated message response
#+end_src
```
```
,------. ,------. ,--.
|Client| |Server| |DB|
`--+---' `--+---' `+-'
| Call wakuext_sendChatMessages| |
| -----------------------------> |
| | |
| |----. |
| | | Transform link previews to |
| |<---' be proto-marshalled |
| | |
| | |
| | Write link previews serialized as JSON|
| | -------------------------------------->
| | |
| Updated message response | |
| <- - - - - - - - - - - - - - - |
,--+---. ,--+---. ,+-.
|Client| |Server| |DB|
`------' `------' `--'
```
3. The message was sent over waku and persisted locally in Carol's device. She
should now see the link previews in the chat history. There can be many link
previews shared by other chat members, therefore it is important to serve the
assets via the media server to avoid overloading the ReactNative bridge with
lots of big JSON payloads containing base64 encoded data URIs (maybe this
concern is meaningless for desktop). When a client is rendering messages with
link previews, they will have the field linkPreviews, and the thumbnail URL
will point to the local media server.
```
#+begin_src plantuml :results verbatim
Client->>Server: GET /link-preview/thumbnail (media server)
Server->>DB: Read from user_messages.unfurled_links
Server->Server: Unmarshal JSON
Server-->>Client: HTTP Content-Type: image/jpeg/etc
#+end_src
```
```
,------. ,------. ,--.
|Client| |Server| |DB|
`--+---' `--+---' `+-'
| GET /link-preview/thumbnail (media server)| |
| ------------------------------------------> |
| | |
| | Read from user_messages.unfurled_links|
| | -------------------------------------->
| | |
| |----. |
| | | Unmarshal JSON |
| |<---' |
| | |
| HTTP Content-Type: image/jpeg/etc | |
| <- - - - - - - - - - - - - - - - - - - - - |
,--+---. ,--+---. ,+-.
|Client| |Server| |DB|
`------' `------' `--'
```
### Some limitations of the current implementation
The following points will become separate issues in status-go that I'll work on
over the next couple weeks. In no order of importance:
- Improve how multiple links are fetched; retries on failure and testing how
unfurling behaves around the timeout limits (deterministically, not by making
real HTTP calls as I did). https://github.com/status-im/status-go/issues/3498
- Unfurl favicons and store them in the protobuf too.
- For this PR, I added unfurling support only for websites with OpenGraph
https://ogp.me/ meta tags. Other unfurlers will be implemented on demand. The
next one will probably be for oEmbed https://oembed.com/, the protocol
supported by YouTube, for example.
- Resize and/or compress thumbnails (and favicons). Often times, thumbnails are
huge for the purposes of link previews. There is already support for
compressing JPEGs in status-go, but I prefer to work with compression in a
separate PR because I'd like to also solve the problem for PNGs (probably
convert them to JPEGs, plus compress them). This would be a safe choice for
thumbnails, favicons not so much because transparency is desirable.
- Editing messages is not yet supported.
- I haven't coded any artificial limit on the number of previews or on the size
of the thumbnail payload. This will be done in a separate issue. I have heard
the ideal solution may be to split messages into smaller chunks of ~125 KiB
because of libp2p, but that might be too complicated at this stage of the
product (?).
- Link preview deletion.
- For the moment, OpenGraph metadata is extracted by requesting data for the
English language (and fallback to whatever is available). In the future, we'll
want to unfurl by respecting the user's local device language. Some websites,
like GoDaddy, are already localized based on the device's IP, but many aren't.
- The website's description text should be limited by a certain number of
characters, especially because it's outside our control. Exactly how much has
not been decided yet, so it'll be done separately.
- URL normalization can be tricky, so I implemented only the basics to help with
caching. For example, the url https://status.im and HTTPS://status.im are
considered identical. Also, a URL is considered valid for unfurling if its TLD
exists according to publicsuffix.EffectiveTLDPlusOne. This was essential,
otherwise the default Go url.Parse approach would consider many invalid URLs
valid, and thus the server would waste resources trying to unfurl the
unfurleable.
### Other requirements
- If the message is edited, the link previews should reflect the edited text,
not the original one. This has been aligned with the design team as well.
- If the website's thumbnail or the favicon can't be fetched, just ignore them.
The only mandatory piece of metadata is the website's title and URL.
- Link previews in clients should be generated in near real-time, that is, as
the user types, previews are updated. In mobile this performs very well, and
it's what other clients like WhatsApp, Telegram, and Facebook do.
### Decisions
- While the user typing in the input field, the client is constantly (debounced)
asking status-go to parse the text and extract normalized URLs and then the
client checks if they're already in its in-memory cache. If they are, no RPC
call is made. I chose this approach to achieve the best possible performance
in mobile and avoid the whole RPC overhead, since the chat experience is
already not smooth enough. The mobile client uses URLs as cache keys in a
hashmap, i.e. if the key is present, it means the preview is readily available
(naive, but good enough for now). This decision also gave me more flexibility
to find the best UX at this stage of the feature.
- Due to the requirement that users should be able to see independent loading
indicators for each link preview, when status-go can't unfurl a URL, it
doesn't return it in the response.
- As an initial implementation, I added the BLOB column unfurled_links to the
user_messages table. The preview data is then serialized as JSON before being
stored in this column. I felt that creating a separate table and the related
code for this initial PR would be inconvenient. Is that reasonable to you?
Once things stabilize I can create a proper table if we want to avoid this
kind of solution with serialized columns.
2023-05-18 18:43:06 +00:00
m1 . unfurled_links ,
2020-01-10 18:59:01 +00:00
m1 . command_id ,
m1 . command_value ,
m1 . command_from ,
m1 . command_address ,
m1 . command_contract ,
m1 . command_transaction_hash ,
m1 . command_state ,
m1 . command_signature ,
Add replies to messages
Currently replies to messages are handled in status-react.
This causes some issues with the fact that sometimes replies might come
out of order, they might be offloaded to the database etc.
This commit changes the behavior so that status-go always returns the
replies, and in case a reply comes out of order (first the reply, later
the message being replied to), it will include in the messages the
updated message.
It also adds some fields (RTL,Replace,LineCount) to the database which
were not previously saved, resulting in some potential bugs.
The method that we use to pull replies is currently a bit naive, we just
pull all the message again from the database, but has the advantage of
being simple. It will go through performance testing to make sure
performnace are acceptable, if so I think it's reasonable to avoid some
complexity.
2020-04-08 13:42:02 +00:00
m1 . replace_message ,
2021-06-07 08:31:27 +00:00
m1 . edited_at ,
2021-07-26 21:06:32 +00:00
m1 . deleted ,
2023-02-01 00:57:35 +00:00
m1 . deleted_by ,
2022-09-28 11:42:17 +00:00
m1 . deleted_for_me ,
Add replies to messages
Currently replies to messages are handled in status-react.
This causes some issues with the fact that sometimes replies might come
out of order, they might be offloaded to the database etc.
This commit changes the behavior so that status-go always returns the
replies, and in case a reply comes out of order (first the reply, later
the message being replied to), it will include in the messages the
updated message.
It also adds some fields (RTL,Replace,LineCount) to the database which
were not previously saved, resulting in some potential bugs.
The method that we use to pull replies is currently a bit naive, we just
pull all the message again from the database, but has the advantage of
being simple. It will go through performance testing to make sure
performnace are acceptable, if so I think it's reasonable to avoid some
complexity.
2020-04-08 13:42:02 +00:00
m1 . rtl ,
m1 . line_count ,
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
m1 . response_to ,
2021-03-25 15:15:22 +00:00
m1 . gap_from ,
m1 . gap_to ,
2022-01-18 16:31:34 +00:00
m1 . contact_request_state ,
2022-08-31 14:41:58 +00:00
m1 . contact_verification_status ,
2021-05-25 09:40:02 +00:00
m1 . mentioned ,
2023-01-10 17:59:32 +00:00
m1 . replied ,
2022-08-04 16:16:56 +00:00
COALESCE ( m1 . discord_message_id , "" ) ,
COALESCE ( dm . author_id , "" ) ,
COALESCE ( dm . type , "" ) ,
COALESCE ( dm . timestamp , "" ) ,
COALESCE ( dm . timestamp_edited , "" ) ,
COALESCE ( dm . content , "" ) ,
COALESCE ( dm . reference_message_id , "" ) ,
COALESCE ( dm . reference_channel_id , "" ) ,
COALESCE ( dm_author . name , "" ) ,
COALESCE ( dm_author . discriminator , "" ) ,
COALESCE ( dm_author . nickname , "" ) ,
COALESCE ( dm_author . avatar_url , "" ) ,
2022-09-20 09:13:44 +00:00
COALESCE ( dm_attachment . id , "" ) ,
COALESCE ( dm_attachment . discord_message_id , "" ) ,
COALESCE ( dm_attachment . url , "" ) ,
COALESCE ( dm_attachment . file_name , "" ) ,
COALESCE ( dm_attachment . content_type , "" ) ,
2019-08-20 11:20:25 +00:00
m2 . source ,
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
m2 . text ,
2020-09-09 11:03:29 +00:00
m2 . parsed_text ,
2023-06-06 11:52:07 +00:00
m2 . album_images_count ,
2020-06-23 14:30:39 +00:00
m2 . audio_duration_ms ,
2020-11-18 09:16:51 +00:00
m2 . community_id ,
2022-03-16 16:28:14 +00:00
m2 . id ,
m2 . content_type ,
2023-01-11 21:09:40 +00:00
m2 . deleted ,
2023-04-17 14:44:48 +00:00
m2 . deleted_for_me ,
2019-09-26 07:01:17 +00:00
c . alias ,
2023-01-13 15:28:49 +00:00
c . identicon ,
COALESCE ( m2 . discord_message_id , "" ) ,
COALESCE ( m2_dm_author . name , "" ) ,
COALESCE ( m2_dm_author . nickname , "" ) ,
COALESCE ( m2_dm_author . avatar_url , "" ) `
2019-08-06 21:50:13 +00:00
}
2020-05-20 12:16:12 +00:00
func ( db sqlitePersistence ) tableUserMessagesAllFieldsCount ( ) int {
return strings . Count ( db . tableUserMessagesAllFields ( ) , "," ) + 1
2019-08-06 21:50:13 +00:00
}
type scanner interface {
Scan ( dest ... interface { } ) error
}
2020-09-01 13:27:01 +00:00
func ( db sqlitePersistence ) tableUserMessagesScanAllFields ( row scanner , message * common . Message , others ... interface { } ) error {
2022-03-16 16:28:14 +00:00
var quotedID sql . NullString
var ContentType sql . NullInt64
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
var quotedText sql . NullString
2020-09-09 11:03:29 +00:00
var quotedParsedText [ ] byte
2023-06-06 11:52:07 +00:00
var quotedAlbumImagesCount sql . NullInt64
2019-08-20 11:20:25 +00:00
var quotedFrom sql . NullString
2020-06-23 14:30:39 +00:00
var quotedAudioDuration sql . NullInt64
2020-11-18 09:16:51 +00:00
var quotedCommunityID sql . NullString
2023-01-11 21:09:40 +00:00
var quotedDeleted sql . NullBool
2023-04-17 14:44:48 +00:00
var quotedDeletedForMe sql . NullBool
2020-09-01 10:34:28 +00:00
var serializedMentions [ ] byte
2020-10-27 17:35:28 +00:00
var serializedLinks [ ] byte
URL unfurling (initial implementation) (#3471)
This is the initial implementation for the new URL unfurling requirements. The
most important one is that only the message sender will pay the privacy cost for
unfurling and extracting metadata from websites. Once the message is sent, the
unfurled data will be stored at the protocol level and receivers will just
profit and happily decode the metadata to render it.
Further development of this URL unfurling capability will be mostly guided by
issues created on clients. For the moment in status-mobile:
https://github.com/status-im/status-mobile/labels/url-preview
- https://github.com/status-im/status-mobile/issues/15918
- https://github.com/status-im/status-mobile/issues/15917
- https://github.com/status-im/status-mobile/issues/15910
- https://github.com/status-im/status-mobile/issues/15909
- https://github.com/status-im/status-mobile/issues/15908
- https://github.com/status-im/status-mobile/issues/15906
- https://github.com/status-im/status-mobile/issues/15905
### Terminology
In the code, I've tried to stick to the word "unfurl URL" to really mean the
process of extracting metadata from a website, sort of lower level. I use "link
preview" to mean a higher level structure which is enriched by unfurled data.
"link preview" is also how designers refer to it.
### User flows
1. Carol needs to see link previews while typing in the chat input field. Notice
from the diagram nothing is persisted and that status-go endpoints are
essentially stateless.
```
#+begin_src plantuml :results verbatim
Client->>Server: Call wakuext_getTextURLs
Server-->>Client: Normalized URLs
Client->>Client: Render cached unfurled URLs
Client->>Server: Unfurl non-cached URLs.\nCall wakuext_unfurlURLs
Server->>Website: Fetch metadata
Website-->>Server: Metadata (thumbnail URL, title, etc)
Server->>Website: Fetch thumbnail
Server->>Website: Fetch favicon
Website-->>Server: Favicon bytes
Website-->>Server: Thumbnail bytes
Server->>Server: Decode & process images
Server-->>Client: Unfurled data (thumbnail data URI, etc)
#+end_src
```
```
,------. ,------. ,-------.
|Client| |Server| |Website|
`--+---' `--+---' `---+---'
| Call wakuext_getTextURLs | |
| ---------------------------------------> |
| | |
| Normalized URLs | |
| <- - - - - - - - - - - - - - - - - - - - |
| | |
|----. | |
| | Render cached unfurled URLs | |
|<---' | |
| | |
| Unfurl non-cached URLs. | |
| Call wakuext_unfurlURLs | |
| ---------------------------------------> |
| | |
| | Fetch metadata |
| | ------------------------------------>
| | |
| | Metadata (thumbnail URL, title, etc)|
| | <- - - - - - - - - - - - - - - - - -
| | |
| | Fetch thumbnail |
| | ------------------------------------>
| | |
| | Fetch favicon |
| | ------------------------------------>
| | |
| | Favicon bytes |
| | <- - - - - - - - - - - - - - - - - -
| | |
| | Thumbnail bytes |
| | <- - - - - - - - - - - - - - - - - -
| | |
| |----. |
| | | Decode & process images |
| |<---' |
| | |
| Unfurled data (thumbnail data URI, etc)| |
| <- - - - - - - - - - - - - - - - - - - - |
,--+---. ,--+---. ,---+---.
|Client| |Server| |Website|
`------' `------' `-------'
```
2. Carol sends the text message with link previews in the RPC request
wakuext_sendChatMessages. status-go assumes the link previews are good
because it can't and shouldn't attempt to re-unfurl them.
```
#+begin_src plantuml :results verbatim
Client->>Server: Call wakuext_sendChatMessages
Server->>Server: Transform link previews to\nbe proto-marshalled
Server->DB: Write link previews serialized as JSON
Server-->>Client: Updated message response
#+end_src
```
```
,------. ,------. ,--.
|Client| |Server| |DB|
`--+---' `--+---' `+-'
| Call wakuext_sendChatMessages| |
| -----------------------------> |
| | |
| |----. |
| | | Transform link previews to |
| |<---' be proto-marshalled |
| | |
| | |
| | Write link previews serialized as JSON|
| | -------------------------------------->
| | |
| Updated message response | |
| <- - - - - - - - - - - - - - - |
,--+---. ,--+---. ,+-.
|Client| |Server| |DB|
`------' `------' `--'
```
3. The message was sent over waku and persisted locally in Carol's device. She
should now see the link previews in the chat history. There can be many link
previews shared by other chat members, therefore it is important to serve the
assets via the media server to avoid overloading the ReactNative bridge with
lots of big JSON payloads containing base64 encoded data URIs (maybe this
concern is meaningless for desktop). When a client is rendering messages with
link previews, they will have the field linkPreviews, and the thumbnail URL
will point to the local media server.
```
#+begin_src plantuml :results verbatim
Client->>Server: GET /link-preview/thumbnail (media server)
Server->>DB: Read from user_messages.unfurled_links
Server->Server: Unmarshal JSON
Server-->>Client: HTTP Content-Type: image/jpeg/etc
#+end_src
```
```
,------. ,------. ,--.
|Client| |Server| |DB|
`--+---' `--+---' `+-'
| GET /link-preview/thumbnail (media server)| |
| ------------------------------------------> |
| | |
| | Read from user_messages.unfurled_links|
| | -------------------------------------->
| | |
| |----. |
| | | Unmarshal JSON |
| |<---' |
| | |
| HTTP Content-Type: image/jpeg/etc | |
| <- - - - - - - - - - - - - - - - - - - - - |
,--+---. ,--+---. ,+-.
|Client| |Server| |DB|
`------' `------' `--'
```
### Some limitations of the current implementation
The following points will become separate issues in status-go that I'll work on
over the next couple weeks. In no order of importance:
- Improve how multiple links are fetched; retries on failure and testing how
unfurling behaves around the timeout limits (deterministically, not by making
real HTTP calls as I did). https://github.com/status-im/status-go/issues/3498
- Unfurl favicons and store them in the protobuf too.
- For this PR, I added unfurling support only for websites with OpenGraph
https://ogp.me/ meta tags. Other unfurlers will be implemented on demand. The
next one will probably be for oEmbed https://oembed.com/, the protocol
supported by YouTube, for example.
- Resize and/or compress thumbnails (and favicons). Often times, thumbnails are
huge for the purposes of link previews. There is already support for
compressing JPEGs in status-go, but I prefer to work with compression in a
separate PR because I'd like to also solve the problem for PNGs (probably
convert them to JPEGs, plus compress them). This would be a safe choice for
thumbnails, favicons not so much because transparency is desirable.
- Editing messages is not yet supported.
- I haven't coded any artificial limit on the number of previews or on the size
of the thumbnail payload. This will be done in a separate issue. I have heard
the ideal solution may be to split messages into smaller chunks of ~125 KiB
because of libp2p, but that might be too complicated at this stage of the
product (?).
- Link preview deletion.
- For the moment, OpenGraph metadata is extracted by requesting data for the
English language (and fallback to whatever is available). In the future, we'll
want to unfurl by respecting the user's local device language. Some websites,
like GoDaddy, are already localized based on the device's IP, but many aren't.
- The website's description text should be limited by a certain number of
characters, especially because it's outside our control. Exactly how much has
not been decided yet, so it'll be done separately.
- URL normalization can be tricky, so I implemented only the basics to help with
caching. For example, the url https://status.im and HTTPS://status.im are
considered identical. Also, a URL is considered valid for unfurling if its TLD
exists according to publicsuffix.EffectiveTLDPlusOne. This was essential,
otherwise the default Go url.Parse approach would consider many invalid URLs
valid, and thus the server would waste resources trying to unfurl the
unfurleable.
### Other requirements
- If the message is edited, the link previews should reflect the edited text,
not the original one. This has been aligned with the design team as well.
- If the website's thumbnail or the favicon can't be fetched, just ignore them.
The only mandatory piece of metadata is the website's title and URL.
- Link previews in clients should be generated in near real-time, that is, as
the user types, previews are updated. In mobile this performs very well, and
it's what other clients like WhatsApp, Telegram, and Facebook do.
### Decisions
- While the user typing in the input field, the client is constantly (debounced)
asking status-go to parse the text and extract normalized URLs and then the
client checks if they're already in its in-memory cache. If they are, no RPC
call is made. I chose this approach to achieve the best possible performance
in mobile and avoid the whole RPC overhead, since the chat experience is
already not smooth enough. The mobile client uses URLs as cache keys in a
hashmap, i.e. if the key is present, it means the preview is readily available
(naive, but good enough for now). This decision also gave me more flexibility
to find the best UX at this stage of the feature.
- Due to the requirement that users should be able to see independent loading
indicators for each link preview, when status-go can't unfurl a URL, it
doesn't return it in the response.
- As an initial implementation, I added the BLOB column unfurled_links to the
user_messages table. The preview data is then serialized as JSON before being
stored in this column. I felt that creating a separate table and the related
code for this initial PR would be inconvenient. Is that reasonable to you?
Once things stabilize I can create a proper table if we want to avoid this
kind of solution with serialized columns.
2023-05-18 18:43:06 +00:00
var serializedUnfurledLinks [ ] byte
2019-09-26 07:01:17 +00:00
var alias sql . NullString
var identicon sql . NullString
2021-01-07 11:16:19 +00:00
var communityID sql . NullString
2021-03-25 15:15:22 +00:00
var gapFrom sql . NullInt64
var gapTo sql . NullInt64
2021-06-07 08:31:27 +00:00
var editedAt sql . NullInt64
2021-07-26 21:06:32 +00:00
var deleted sql . NullBool
2023-02-01 00:57:35 +00:00
var deletedBy sql . NullString
2022-09-28 11:42:17 +00:00
var deletedForMe sql . NullBool
2022-01-18 16:31:34 +00:00
var contactRequestState sql . NullInt64
2022-08-31 14:41:58 +00:00
var contactVerificationState sql . NullInt64
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
sticker := & protobuf . StickerMessage { }
2020-09-01 13:27:01 +00:00
command := & common . CommandParameters { }
2020-06-23 14:30:39 +00:00
audio := & protobuf . AudioMessage { }
2022-02-24 16:08:44 +00:00
image := & protobuf . ImageMessage { }
2022-08-04 16:16:56 +00:00
discordMessage := & protobuf . DiscordMessage {
2022-09-20 09:13:44 +00:00
Author : & protobuf . DiscordMessageAuthor { } ,
Reference : & protobuf . DiscordMessageReference { } ,
Attachments : [ ] * protobuf . DiscordMessageAttachment { } ,
2022-08-04 16:16:56 +00:00
}
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
2023-01-13 15:28:49 +00:00
quotedDiscordMessage := & protobuf . DiscordMessage {
Author : & protobuf . DiscordMessageAuthor { } ,
}
2022-09-20 09:13:44 +00:00
attachment := & protobuf . DiscordMessageAttachment { }
2019-08-06 21:50:13 +00:00
args := [ ] interface { } {
& message . ID ,
& message . WhisperTimestamp ,
& message . From , // source in table
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 . Text ,
2019-08-06 21:50:13 +00:00
& message . ContentType ,
2019-09-26 07:01:17 +00:00
& message . Alias ,
2019-08-06 21:50:13 +00:00
& message . Timestamp ,
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 . ChatId ,
& message . LocalChatID ,
2019-08-06 21:50:13 +00:00
& message . MessageType ,
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 . Clock ,
2019-08-06 21:50:13 +00:00
& message . Seen ,
& message . OutgoingStatus ,
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 . ParsedText ,
& sticker . Pack ,
& sticker . Hash ,
2022-02-24 16:08:44 +00:00
& image . Payload ,
2022-03-10 21:05:17 +00:00
& image . Type ,
2023-02-02 08:00:49 +00:00
& image . AlbumId ,
2023-04-05 13:24:55 +00:00
& image . AlbumImagesCount ,
2023-02-02 08:00:49 +00:00
& image . Width ,
& image . Height ,
2020-06-23 14:30:39 +00:00
& audio . DurationMs ,
2021-01-07 11:16:19 +00:00
& communityID ,
2020-09-01 10:34:28 +00:00
& serializedMentions ,
2020-10-27 17:35:28 +00:00
& serializedLinks ,
URL unfurling (initial implementation) (#3471)
This is the initial implementation for the new URL unfurling requirements. The
most important one is that only the message sender will pay the privacy cost for
unfurling and extracting metadata from websites. Once the message is sent, the
unfurled data will be stored at the protocol level and receivers will just
profit and happily decode the metadata to render it.
Further development of this URL unfurling capability will be mostly guided by
issues created on clients. For the moment in status-mobile:
https://github.com/status-im/status-mobile/labels/url-preview
- https://github.com/status-im/status-mobile/issues/15918
- https://github.com/status-im/status-mobile/issues/15917
- https://github.com/status-im/status-mobile/issues/15910
- https://github.com/status-im/status-mobile/issues/15909
- https://github.com/status-im/status-mobile/issues/15908
- https://github.com/status-im/status-mobile/issues/15906
- https://github.com/status-im/status-mobile/issues/15905
### Terminology
In the code, I've tried to stick to the word "unfurl URL" to really mean the
process of extracting metadata from a website, sort of lower level. I use "link
preview" to mean a higher level structure which is enriched by unfurled data.
"link preview" is also how designers refer to it.
### User flows
1. Carol needs to see link previews while typing in the chat input field. Notice
from the diagram nothing is persisted and that status-go endpoints are
essentially stateless.
```
#+begin_src plantuml :results verbatim
Client->>Server: Call wakuext_getTextURLs
Server-->>Client: Normalized URLs
Client->>Client: Render cached unfurled URLs
Client->>Server: Unfurl non-cached URLs.\nCall wakuext_unfurlURLs
Server->>Website: Fetch metadata
Website-->>Server: Metadata (thumbnail URL, title, etc)
Server->>Website: Fetch thumbnail
Server->>Website: Fetch favicon
Website-->>Server: Favicon bytes
Website-->>Server: Thumbnail bytes
Server->>Server: Decode & process images
Server-->>Client: Unfurled data (thumbnail data URI, etc)
#+end_src
```
```
,------. ,------. ,-------.
|Client| |Server| |Website|
`--+---' `--+---' `---+---'
| Call wakuext_getTextURLs | |
| ---------------------------------------> |
| | |
| Normalized URLs | |
| <- - - - - - - - - - - - - - - - - - - - |
| | |
|----. | |
| | Render cached unfurled URLs | |
|<---' | |
| | |
| Unfurl non-cached URLs. | |
| Call wakuext_unfurlURLs | |
| ---------------------------------------> |
| | |
| | Fetch metadata |
| | ------------------------------------>
| | |
| | Metadata (thumbnail URL, title, etc)|
| | <- - - - - - - - - - - - - - - - - -
| | |
| | Fetch thumbnail |
| | ------------------------------------>
| | |
| | Fetch favicon |
| | ------------------------------------>
| | |
| | Favicon bytes |
| | <- - - - - - - - - - - - - - - - - -
| | |
| | Thumbnail bytes |
| | <- - - - - - - - - - - - - - - - - -
| | |
| |----. |
| | | Decode & process images |
| |<---' |
| | |
| Unfurled data (thumbnail data URI, etc)| |
| <- - - - - - - - - - - - - - - - - - - - |
,--+---. ,--+---. ,---+---.
|Client| |Server| |Website|
`------' `------' `-------'
```
2. Carol sends the text message with link previews in the RPC request
wakuext_sendChatMessages. status-go assumes the link previews are good
because it can't and shouldn't attempt to re-unfurl them.
```
#+begin_src plantuml :results verbatim
Client->>Server: Call wakuext_sendChatMessages
Server->>Server: Transform link previews to\nbe proto-marshalled
Server->DB: Write link previews serialized as JSON
Server-->>Client: Updated message response
#+end_src
```
```
,------. ,------. ,--.
|Client| |Server| |DB|
`--+---' `--+---' `+-'
| Call wakuext_sendChatMessages| |
| -----------------------------> |
| | |
| |----. |
| | | Transform link previews to |
| |<---' be proto-marshalled |
| | |
| | |
| | Write link previews serialized as JSON|
| | -------------------------------------->
| | |
| Updated message response | |
| <- - - - - - - - - - - - - - - |
,--+---. ,--+---. ,+-.
|Client| |Server| |DB|
`------' `------' `--'
```
3. The message was sent over waku and persisted locally in Carol's device. She
should now see the link previews in the chat history. There can be many link
previews shared by other chat members, therefore it is important to serve the
assets via the media server to avoid overloading the ReactNative bridge with
lots of big JSON payloads containing base64 encoded data URIs (maybe this
concern is meaningless for desktop). When a client is rendering messages with
link previews, they will have the field linkPreviews, and the thumbnail URL
will point to the local media server.
```
#+begin_src plantuml :results verbatim
Client->>Server: GET /link-preview/thumbnail (media server)
Server->>DB: Read from user_messages.unfurled_links
Server->Server: Unmarshal JSON
Server-->>Client: HTTP Content-Type: image/jpeg/etc
#+end_src
```
```
,------. ,------. ,--.
|Client| |Server| |DB|
`--+---' `--+---' `+-'
| GET /link-preview/thumbnail (media server)| |
| ------------------------------------------> |
| | |
| | Read from user_messages.unfurled_links|
| | -------------------------------------->
| | |
| |----. |
| | | Unmarshal JSON |
| |<---' |
| | |
| HTTP Content-Type: image/jpeg/etc | |
| <- - - - - - - - - - - - - - - - - - - - - |
,--+---. ,--+---. ,+-.
|Client| |Server| |DB|
`------' `------' `--'
```
### Some limitations of the current implementation
The following points will become separate issues in status-go that I'll work on
over the next couple weeks. In no order of importance:
- Improve how multiple links are fetched; retries on failure and testing how
unfurling behaves around the timeout limits (deterministically, not by making
real HTTP calls as I did). https://github.com/status-im/status-go/issues/3498
- Unfurl favicons and store them in the protobuf too.
- For this PR, I added unfurling support only for websites with OpenGraph
https://ogp.me/ meta tags. Other unfurlers will be implemented on demand. The
next one will probably be for oEmbed https://oembed.com/, the protocol
supported by YouTube, for example.
- Resize and/or compress thumbnails (and favicons). Often times, thumbnails are
huge for the purposes of link previews. There is already support for
compressing JPEGs in status-go, but I prefer to work with compression in a
separate PR because I'd like to also solve the problem for PNGs (probably
convert them to JPEGs, plus compress them). This would be a safe choice for
thumbnails, favicons not so much because transparency is desirable.
- Editing messages is not yet supported.
- I haven't coded any artificial limit on the number of previews or on the size
of the thumbnail payload. This will be done in a separate issue. I have heard
the ideal solution may be to split messages into smaller chunks of ~125 KiB
because of libp2p, but that might be too complicated at this stage of the
product (?).
- Link preview deletion.
- For the moment, OpenGraph metadata is extracted by requesting data for the
English language (and fallback to whatever is available). In the future, we'll
want to unfurl by respecting the user's local device language. Some websites,
like GoDaddy, are already localized based on the device's IP, but many aren't.
- The website's description text should be limited by a certain number of
characters, especially because it's outside our control. Exactly how much has
not been decided yet, so it'll be done separately.
- URL normalization can be tricky, so I implemented only the basics to help with
caching. For example, the url https://status.im and HTTPS://status.im are
considered identical. Also, a URL is considered valid for unfurling if its TLD
exists according to publicsuffix.EffectiveTLDPlusOne. This was essential,
otherwise the default Go url.Parse approach would consider many invalid URLs
valid, and thus the server would waste resources trying to unfurl the
unfurleable.
### Other requirements
- If the message is edited, the link previews should reflect the edited text,
not the original one. This has been aligned with the design team as well.
- If the website's thumbnail or the favicon can't be fetched, just ignore them.
The only mandatory piece of metadata is the website's title and URL.
- Link previews in clients should be generated in near real-time, that is, as
the user types, previews are updated. In mobile this performs very well, and
it's what other clients like WhatsApp, Telegram, and Facebook do.
### Decisions
- While the user typing in the input field, the client is constantly (debounced)
asking status-go to parse the text and extract normalized URLs and then the
client checks if they're already in its in-memory cache. If they are, no RPC
call is made. I chose this approach to achieve the best possible performance
in mobile and avoid the whole RPC overhead, since the chat experience is
already not smooth enough. The mobile client uses URLs as cache keys in a
hashmap, i.e. if the key is present, it means the preview is readily available
(naive, but good enough for now). This decision also gave me more flexibility
to find the best UX at this stage of the feature.
- Due to the requirement that users should be able to see independent loading
indicators for each link preview, when status-go can't unfurl a URL, it
doesn't return it in the response.
- As an initial implementation, I added the BLOB column unfurled_links to the
user_messages table. The preview data is then serialized as JSON before being
stored in this column. I felt that creating a separate table and the related
code for this initial PR would be inconvenient. Is that reasonable to you?
Once things stabilize I can create a proper table if we want to avoid this
kind of solution with serialized columns.
2023-05-18 18:43:06 +00:00
& serializedUnfurledLinks ,
2020-01-10 18:59:01 +00:00
& command . ID ,
& command . Value ,
& command . From ,
& command . Address ,
& command . Contract ,
& command . TransactionHash ,
& command . CommandState ,
& command . Signature ,
Add replies to messages
Currently replies to messages are handled in status-react.
This causes some issues with the fact that sometimes replies might come
out of order, they might be offloaded to the database etc.
This commit changes the behavior so that status-go always returns the
replies, and in case a reply comes out of order (first the reply, later
the message being replied to), it will include in the messages the
updated message.
It also adds some fields (RTL,Replace,LineCount) to the database which
were not previously saved, resulting in some potential bugs.
The method that we use to pull replies is currently a bit naive, we just
pull all the message again from the database, but has the advantage of
being simple. It will go through performance testing to make sure
performnace are acceptable, if so I think it's reasonable to avoid some
complexity.
2020-04-08 13:42:02 +00:00
& message . Replace ,
2021-06-07 08:31:27 +00:00
& editedAt ,
2021-07-26 21:06:32 +00:00
& deleted ,
2023-02-01 00:57:35 +00:00
& deletedBy ,
2022-09-28 11:42:17 +00:00
& deletedForMe ,
Add replies to messages
Currently replies to messages are handled in status-react.
This causes some issues with the fact that sometimes replies might come
out of order, they might be offloaded to the database etc.
This commit changes the behavior so that status-go always returns the
replies, and in case a reply comes out of order (first the reply, later
the message being replied to), it will include in the messages the
updated message.
It also adds some fields (RTL,Replace,LineCount) to the database which
were not previously saved, resulting in some potential bugs.
The method that we use to pull replies is currently a bit naive, we just
pull all the message again from the database, but has the advantage of
being simple. It will go through performance testing to make sure
performnace are acceptable, if so I think it's reasonable to avoid some
complexity.
2020-04-08 13:42:02 +00:00
& message . RTL ,
& message . LineCount ,
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 . ResponseTo ,
2021-03-25 15:15:22 +00:00
& gapFrom ,
& gapTo ,
2022-01-18 16:31:34 +00:00
& contactRequestState ,
2022-08-31 14:41:58 +00:00
& contactVerificationState ,
2021-05-25 09:40:02 +00:00
& message . Mentioned ,
2023-01-10 17:59:32 +00:00
& message . Replied ,
2022-08-04 16:16:56 +00:00
& discordMessage . Id ,
& discordMessage . Author . Id ,
& discordMessage . Type ,
& discordMessage . Timestamp ,
& discordMessage . TimestampEdited ,
& discordMessage . Content ,
& discordMessage . Reference . MessageId ,
& discordMessage . Reference . ChannelId ,
& discordMessage . Author . Name ,
& discordMessage . Author . Discriminator ,
& discordMessage . Author . Nickname ,
& discordMessage . Author . AvatarUrl ,
2022-09-20 09:13:44 +00:00
& attachment . Id ,
& attachment . MessageId ,
& attachment . Url ,
& attachment . FileName ,
& attachment . ContentType ,
2019-08-20 11:20:25 +00:00
& quotedFrom ,
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
& quotedText ,
2020-09-09 11:03:29 +00:00
& quotedParsedText ,
2023-06-06 11:52:07 +00:00
& quotedAlbumImagesCount ,
2020-06-23 14:30:39 +00:00
& quotedAudioDuration ,
2020-11-18 09:16:51 +00:00
& quotedCommunityID ,
2022-03-16 16:28:14 +00:00
& quotedID ,
& ContentType ,
2023-01-11 21:09:40 +00:00
& quotedDeleted ,
2023-04-17 14:44:48 +00:00
& quotedDeletedForMe ,
2019-09-26 07:01:17 +00:00
& alias ,
& identicon ,
2023-01-13 15:28:49 +00:00
& quotedDiscordMessage . Id ,
& quotedDiscordMessage . Author . Name ,
& quotedDiscordMessage . Author . Nickname ,
& quotedDiscordMessage . Author . AvatarUrl ,
2019-08-20 11:20:25 +00:00
}
err := row . Scan ( append ( args , others ... ) ... )
if err != nil {
return err
}
2021-06-07 08:31:27 +00:00
if editedAt . Valid {
message . EditedAt = uint64 ( editedAt . Int64 )
2021-06-03 13:11:55 +00:00
}
2021-07-26 21:06:32 +00:00
if deleted . Valid {
message . Deleted = deleted . Bool
}
2023-02-01 00:57:35 +00:00
if deletedBy . Valid {
message . DeletedBy = deletedBy . String
}
2022-09-28 11:42:17 +00:00
if deletedForMe . Valid {
message . DeletedForMe = deletedForMe . Bool
}
2022-01-18 16:31:34 +00:00
if contactRequestState . Valid {
message . ContactRequestState = common . ContactRequestState ( contactRequestState . Int64 )
}
2022-08-31 14:41:58 +00:00
if contactVerificationState . Valid {
message . ContactVerificationState = common . ContactVerificationState ( contactVerificationState . Int64 )
}
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
if quotedText . Valid {
2023-04-17 14:44:48 +00:00
if quotedDeleted . Bool || quotedDeletedForMe . Bool {
2023-01-11 21:09:40 +00:00
message . QuotedMessage = & common . QuotedMessage {
2023-04-17 14:44:48 +00:00
ID : quotedID . String ,
Deleted : quotedDeleted . Bool ,
DeletedForMe : quotedDeletedForMe . Bool ,
2023-01-11 21:09:40 +00:00
}
} else {
message . QuotedMessage = & common . QuotedMessage {
2023-06-06 11:52:07 +00:00
ID : quotedID . String ,
ContentType : ContentType . Int64 ,
From : quotedFrom . String ,
Text : quotedText . String ,
ParsedText : quotedParsedText ,
AlbumImagesCount : quotedAlbumImagesCount . Int64 ,
CommunityID : quotedCommunityID . String ,
Deleted : quotedDeleted . Bool ,
2023-01-11 21:09:40 +00:00
}
2023-01-13 15:28:49 +00:00
if message . QuotedMessage . ContentType == int64 ( protobuf . ChatMessage_DISCORD_MESSAGE ) {
message . QuotedMessage . DiscordMessage = quotedDiscordMessage
}
2019-08-20 11:20:25 +00:00
}
2019-08-06 21:50:13 +00:00
}
2019-09-26 07:01:17 +00:00
message . Alias = alias . String
message . Identicon = identicon . String
2020-07-10 14:18:01 +00:00
2021-03-25 15:15:22 +00:00
if gapFrom . Valid && gapTo . Valid {
message . GapParameters = & common . GapParameters {
From : uint32 ( gapFrom . Int64 ) ,
To : uint32 ( gapTo . Int64 ) ,
}
}
2023-02-02 08:00:49 +00:00
2021-01-07 11:16:19 +00:00
if communityID . Valid {
message . CommunityID = communityID . String
}
2020-09-01 10:34:28 +00:00
if serializedMentions != nil {
err := json . Unmarshal ( serializedMentions , & message . Mentions )
if err != nil {
return err
}
}
2020-10-27 17:35:28 +00:00
if serializedLinks != nil {
err := json . Unmarshal ( serializedLinks , & message . Links )
if err != nil {
return err
}
}
URL unfurling (initial implementation) (#3471)
This is the initial implementation for the new URL unfurling requirements. The
most important one is that only the message sender will pay the privacy cost for
unfurling and extracting metadata from websites. Once the message is sent, the
unfurled data will be stored at the protocol level and receivers will just
profit and happily decode the metadata to render it.
Further development of this URL unfurling capability will be mostly guided by
issues created on clients. For the moment in status-mobile:
https://github.com/status-im/status-mobile/labels/url-preview
- https://github.com/status-im/status-mobile/issues/15918
- https://github.com/status-im/status-mobile/issues/15917
- https://github.com/status-im/status-mobile/issues/15910
- https://github.com/status-im/status-mobile/issues/15909
- https://github.com/status-im/status-mobile/issues/15908
- https://github.com/status-im/status-mobile/issues/15906
- https://github.com/status-im/status-mobile/issues/15905
### Terminology
In the code, I've tried to stick to the word "unfurl URL" to really mean the
process of extracting metadata from a website, sort of lower level. I use "link
preview" to mean a higher level structure which is enriched by unfurled data.
"link preview" is also how designers refer to it.
### User flows
1. Carol needs to see link previews while typing in the chat input field. Notice
from the diagram nothing is persisted and that status-go endpoints are
essentially stateless.
```
#+begin_src plantuml :results verbatim
Client->>Server: Call wakuext_getTextURLs
Server-->>Client: Normalized URLs
Client->>Client: Render cached unfurled URLs
Client->>Server: Unfurl non-cached URLs.\nCall wakuext_unfurlURLs
Server->>Website: Fetch metadata
Website-->>Server: Metadata (thumbnail URL, title, etc)
Server->>Website: Fetch thumbnail
Server->>Website: Fetch favicon
Website-->>Server: Favicon bytes
Website-->>Server: Thumbnail bytes
Server->>Server: Decode & process images
Server-->>Client: Unfurled data (thumbnail data URI, etc)
#+end_src
```
```
,------. ,------. ,-------.
|Client| |Server| |Website|
`--+---' `--+---' `---+---'
| Call wakuext_getTextURLs | |
| ---------------------------------------> |
| | |
| Normalized URLs | |
| <- - - - - - - - - - - - - - - - - - - - |
| | |
|----. | |
| | Render cached unfurled URLs | |
|<---' | |
| | |
| Unfurl non-cached URLs. | |
| Call wakuext_unfurlURLs | |
| ---------------------------------------> |
| | |
| | Fetch metadata |
| | ------------------------------------>
| | |
| | Metadata (thumbnail URL, title, etc)|
| | <- - - - - - - - - - - - - - - - - -
| | |
| | Fetch thumbnail |
| | ------------------------------------>
| | |
| | Fetch favicon |
| | ------------------------------------>
| | |
| | Favicon bytes |
| | <- - - - - - - - - - - - - - - - - -
| | |
| | Thumbnail bytes |
| | <- - - - - - - - - - - - - - - - - -
| | |
| |----. |
| | | Decode & process images |
| |<---' |
| | |
| Unfurled data (thumbnail data URI, etc)| |
| <- - - - - - - - - - - - - - - - - - - - |
,--+---. ,--+---. ,---+---.
|Client| |Server| |Website|
`------' `------' `-------'
```
2. Carol sends the text message with link previews in the RPC request
wakuext_sendChatMessages. status-go assumes the link previews are good
because it can't and shouldn't attempt to re-unfurl them.
```
#+begin_src plantuml :results verbatim
Client->>Server: Call wakuext_sendChatMessages
Server->>Server: Transform link previews to\nbe proto-marshalled
Server->DB: Write link previews serialized as JSON
Server-->>Client: Updated message response
#+end_src
```
```
,------. ,------. ,--.
|Client| |Server| |DB|
`--+---' `--+---' `+-'
| Call wakuext_sendChatMessages| |
| -----------------------------> |
| | |
| |----. |
| | | Transform link previews to |
| |<---' be proto-marshalled |
| | |
| | |
| | Write link previews serialized as JSON|
| | -------------------------------------->
| | |
| Updated message response | |
| <- - - - - - - - - - - - - - - |
,--+---. ,--+---. ,+-.
|Client| |Server| |DB|
`------' `------' `--'
```
3. The message was sent over waku and persisted locally in Carol's device. She
should now see the link previews in the chat history. There can be many link
previews shared by other chat members, therefore it is important to serve the
assets via the media server to avoid overloading the ReactNative bridge with
lots of big JSON payloads containing base64 encoded data URIs (maybe this
concern is meaningless for desktop). When a client is rendering messages with
link previews, they will have the field linkPreviews, and the thumbnail URL
will point to the local media server.
```
#+begin_src plantuml :results verbatim
Client->>Server: GET /link-preview/thumbnail (media server)
Server->>DB: Read from user_messages.unfurled_links
Server->Server: Unmarshal JSON
Server-->>Client: HTTP Content-Type: image/jpeg/etc
#+end_src
```
```
,------. ,------. ,--.
|Client| |Server| |DB|
`--+---' `--+---' `+-'
| GET /link-preview/thumbnail (media server)| |
| ------------------------------------------> |
| | |
| | Read from user_messages.unfurled_links|
| | -------------------------------------->
| | |
| |----. |
| | | Unmarshal JSON |
| |<---' |
| | |
| HTTP Content-Type: image/jpeg/etc | |
| <- - - - - - - - - - - - - - - - - - - - - |
,--+---. ,--+---. ,+-.
|Client| |Server| |DB|
`------' `------' `--'
```
### Some limitations of the current implementation
The following points will become separate issues in status-go that I'll work on
over the next couple weeks. In no order of importance:
- Improve how multiple links are fetched; retries on failure and testing how
unfurling behaves around the timeout limits (deterministically, not by making
real HTTP calls as I did). https://github.com/status-im/status-go/issues/3498
- Unfurl favicons and store them in the protobuf too.
- For this PR, I added unfurling support only for websites with OpenGraph
https://ogp.me/ meta tags. Other unfurlers will be implemented on demand. The
next one will probably be for oEmbed https://oembed.com/, the protocol
supported by YouTube, for example.
- Resize and/or compress thumbnails (and favicons). Often times, thumbnails are
huge for the purposes of link previews. There is already support for
compressing JPEGs in status-go, but I prefer to work with compression in a
separate PR because I'd like to also solve the problem for PNGs (probably
convert them to JPEGs, plus compress them). This would be a safe choice for
thumbnails, favicons not so much because transparency is desirable.
- Editing messages is not yet supported.
- I haven't coded any artificial limit on the number of previews or on the size
of the thumbnail payload. This will be done in a separate issue. I have heard
the ideal solution may be to split messages into smaller chunks of ~125 KiB
because of libp2p, but that might be too complicated at this stage of the
product (?).
- Link preview deletion.
- For the moment, OpenGraph metadata is extracted by requesting data for the
English language (and fallback to whatever is available). In the future, we'll
want to unfurl by respecting the user's local device language. Some websites,
like GoDaddy, are already localized based on the device's IP, but many aren't.
- The website's description text should be limited by a certain number of
characters, especially because it's outside our control. Exactly how much has
not been decided yet, so it'll be done separately.
- URL normalization can be tricky, so I implemented only the basics to help with
caching. For example, the url https://status.im and HTTPS://status.im are
considered identical. Also, a URL is considered valid for unfurling if its TLD
exists according to publicsuffix.EffectiveTLDPlusOne. This was essential,
otherwise the default Go url.Parse approach would consider many invalid URLs
valid, and thus the server would waste resources trying to unfurl the
unfurleable.
### Other requirements
- If the message is edited, the link previews should reflect the edited text,
not the original one. This has been aligned with the design team as well.
- If the website's thumbnail or the favicon can't be fetched, just ignore them.
The only mandatory piece of metadata is the website's title and URL.
- Link previews in clients should be generated in near real-time, that is, as
the user types, previews are updated. In mobile this performs very well, and
it's what other clients like WhatsApp, Telegram, and Facebook do.
### Decisions
- While the user typing in the input field, the client is constantly (debounced)
asking status-go to parse the text and extract normalized URLs and then the
client checks if they're already in its in-memory cache. If they are, no RPC
call is made. I chose this approach to achieve the best possible performance
in mobile and avoid the whole RPC overhead, since the chat experience is
already not smooth enough. The mobile client uses URLs as cache keys in a
hashmap, i.e. if the key is present, it means the preview is readily available
(naive, but good enough for now). This decision also gave me more flexibility
to find the best UX at this stage of the feature.
- Due to the requirement that users should be able to see independent loading
indicators for each link preview, when status-go can't unfurl a URL, it
doesn't return it in the response.
- As an initial implementation, I added the BLOB column unfurled_links to the
user_messages table. The preview data is then serialized as JSON before being
stored in this column. I felt that creating a separate table and the related
code for this initial PR would be inconvenient. Is that reasonable to you?
Once things stabilize I can create a proper table if we want to avoid this
kind of solution with serialized columns.
2023-05-18 18:43:06 +00:00
if serializedUnfurledLinks != nil {
err = json . Unmarshal ( serializedUnfurledLinks , & message . UnfurledLinks )
if err != nil {
return err
}
}
2022-09-20 09:13:44 +00:00
if attachment . Id != "" {
discordMessage . Attachments = append ( discordMessage . Attachments , attachment )
}
2020-07-10 14:20:18 +00:00
switch message . ContentType {
case protobuf . ChatMessage_STICKER :
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 . Payload = & protobuf . ChatMessage_Sticker { Sticker : sticker }
2019-09-26 07:01:17 +00:00
2020-08-13 17:57:17 +00:00
case protobuf . ChatMessage_AUDIO :
message . Payload = & protobuf . ChatMessage_Audio { Audio : audio }
2020-06-23 14:30:39 +00:00
2020-07-10 14:20:18 +00:00
case protobuf . ChatMessage_TRANSACTION_COMMAND :
2020-01-10 18:59:01 +00:00
message . CommandParameters = command
2022-02-24 16:08:44 +00:00
case protobuf . ChatMessage_IMAGE :
2023-02-02 08:00:49 +00:00
message . Payload = & protobuf . ChatMessage_Image { Image : image }
2022-08-04 16:16:56 +00:00
case protobuf . ChatMessage_DISCORD_MESSAGE :
message . Payload = & protobuf . ChatMessage_DiscordMessage {
DiscordMessage : discordMessage ,
}
2020-01-10 18:59:01 +00:00
}
2019-08-20 11:20:25 +00:00
return nil
2019-08-06 21:50:13 +00:00
}
2020-09-01 13:27:01 +00:00
func ( db sqlitePersistence ) tableUserMessagesAllValues ( message * common . Message ) ( [ ] interface { } , error ) {
2021-03-25 15:15:22 +00:00
var gapFrom , gapTo uint32
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
sticker := message . GetSticker ( )
if sticker == nil {
sticker = & protobuf . StickerMessage { }
}
2020-05-13 13:16:17 +00:00
image := message . GetImage ( )
if image == nil {
image = & protobuf . ImageMessage { }
}
2020-06-17 18:55:49 +00:00
audio := message . GetAudio ( )
if audio == nil {
audio = & protobuf . AudioMessage { }
}
2020-01-10 18:59:01 +00:00
command := message . CommandParameters
if command == nil {
2020-09-01 13:27:01 +00:00
command = & common . CommandParameters { }
2020-01-10 18:59:01 +00:00
}
2020-09-01 10:34:28 +00:00
2022-08-04 16:16:56 +00:00
discordMessage := message . GetDiscordMessage ( )
if discordMessage == nil {
discordMessage = & protobuf . DiscordMessage {
2022-09-20 09:13:44 +00:00
Author : & protobuf . DiscordMessageAuthor { } ,
Reference : & protobuf . DiscordMessageReference { } ,
Attachments : make ( [ ] * protobuf . DiscordMessageAttachment , 0 ) ,
2022-08-04 16:16:56 +00:00
}
}
2021-03-25 15:15:22 +00:00
if message . GapParameters != nil {
gapFrom = message . GapParameters . From
gapTo = message . GapParameters . To
}
2020-09-01 10:34:28 +00:00
var serializedMentions [ ] byte
var err error
if len ( message . Mentions ) != 0 {
serializedMentions , err = json . Marshal ( message . Mentions )
if err != nil {
return nil , err
}
}
2020-10-27 17:35:28 +00:00
var serializedLinks [ ] byte
if len ( message . Links ) != 0 {
serializedLinks , err = json . Marshal ( message . Links )
if err != nil {
return nil , err
}
}
URL unfurling (initial implementation) (#3471)
This is the initial implementation for the new URL unfurling requirements. The
most important one is that only the message sender will pay the privacy cost for
unfurling and extracting metadata from websites. Once the message is sent, the
unfurled data will be stored at the protocol level and receivers will just
profit and happily decode the metadata to render it.
Further development of this URL unfurling capability will be mostly guided by
issues created on clients. For the moment in status-mobile:
https://github.com/status-im/status-mobile/labels/url-preview
- https://github.com/status-im/status-mobile/issues/15918
- https://github.com/status-im/status-mobile/issues/15917
- https://github.com/status-im/status-mobile/issues/15910
- https://github.com/status-im/status-mobile/issues/15909
- https://github.com/status-im/status-mobile/issues/15908
- https://github.com/status-im/status-mobile/issues/15906
- https://github.com/status-im/status-mobile/issues/15905
### Terminology
In the code, I've tried to stick to the word "unfurl URL" to really mean the
process of extracting metadata from a website, sort of lower level. I use "link
preview" to mean a higher level structure which is enriched by unfurled data.
"link preview" is also how designers refer to it.
### User flows
1. Carol needs to see link previews while typing in the chat input field. Notice
from the diagram nothing is persisted and that status-go endpoints are
essentially stateless.
```
#+begin_src plantuml :results verbatim
Client->>Server: Call wakuext_getTextURLs
Server-->>Client: Normalized URLs
Client->>Client: Render cached unfurled URLs
Client->>Server: Unfurl non-cached URLs.\nCall wakuext_unfurlURLs
Server->>Website: Fetch metadata
Website-->>Server: Metadata (thumbnail URL, title, etc)
Server->>Website: Fetch thumbnail
Server->>Website: Fetch favicon
Website-->>Server: Favicon bytes
Website-->>Server: Thumbnail bytes
Server->>Server: Decode & process images
Server-->>Client: Unfurled data (thumbnail data URI, etc)
#+end_src
```
```
,------. ,------. ,-------.
|Client| |Server| |Website|
`--+---' `--+---' `---+---'
| Call wakuext_getTextURLs | |
| ---------------------------------------> |
| | |
| Normalized URLs | |
| <- - - - - - - - - - - - - - - - - - - - |
| | |
|----. | |
| | Render cached unfurled URLs | |
|<---' | |
| | |
| Unfurl non-cached URLs. | |
| Call wakuext_unfurlURLs | |
| ---------------------------------------> |
| | |
| | Fetch metadata |
| | ------------------------------------>
| | |
| | Metadata (thumbnail URL, title, etc)|
| | <- - - - - - - - - - - - - - - - - -
| | |
| | Fetch thumbnail |
| | ------------------------------------>
| | |
| | Fetch favicon |
| | ------------------------------------>
| | |
| | Favicon bytes |
| | <- - - - - - - - - - - - - - - - - -
| | |
| | Thumbnail bytes |
| | <- - - - - - - - - - - - - - - - - -
| | |
| |----. |
| | | Decode & process images |
| |<---' |
| | |
| Unfurled data (thumbnail data URI, etc)| |
| <- - - - - - - - - - - - - - - - - - - - |
,--+---. ,--+---. ,---+---.
|Client| |Server| |Website|
`------' `------' `-------'
```
2. Carol sends the text message with link previews in the RPC request
wakuext_sendChatMessages. status-go assumes the link previews are good
because it can't and shouldn't attempt to re-unfurl them.
```
#+begin_src plantuml :results verbatim
Client->>Server: Call wakuext_sendChatMessages
Server->>Server: Transform link previews to\nbe proto-marshalled
Server->DB: Write link previews serialized as JSON
Server-->>Client: Updated message response
#+end_src
```
```
,------. ,------. ,--.
|Client| |Server| |DB|
`--+---' `--+---' `+-'
| Call wakuext_sendChatMessages| |
| -----------------------------> |
| | |
| |----. |
| | | Transform link previews to |
| |<---' be proto-marshalled |
| | |
| | |
| | Write link previews serialized as JSON|
| | -------------------------------------->
| | |
| Updated message response | |
| <- - - - - - - - - - - - - - - |
,--+---. ,--+---. ,+-.
|Client| |Server| |DB|
`------' `------' `--'
```
3. The message was sent over waku and persisted locally in Carol's device. She
should now see the link previews in the chat history. There can be many link
previews shared by other chat members, therefore it is important to serve the
assets via the media server to avoid overloading the ReactNative bridge with
lots of big JSON payloads containing base64 encoded data URIs (maybe this
concern is meaningless for desktop). When a client is rendering messages with
link previews, they will have the field linkPreviews, and the thumbnail URL
will point to the local media server.
```
#+begin_src plantuml :results verbatim
Client->>Server: GET /link-preview/thumbnail (media server)
Server->>DB: Read from user_messages.unfurled_links
Server->Server: Unmarshal JSON
Server-->>Client: HTTP Content-Type: image/jpeg/etc
#+end_src
```
```
,------. ,------. ,--.
|Client| |Server| |DB|
`--+---' `--+---' `+-'
| GET /link-preview/thumbnail (media server)| |
| ------------------------------------------> |
| | |
| | Read from user_messages.unfurled_links|
| | -------------------------------------->
| | |
| |----. |
| | | Unmarshal JSON |
| |<---' |
| | |
| HTTP Content-Type: image/jpeg/etc | |
| <- - - - - - - - - - - - - - - - - - - - - |
,--+---. ,--+---. ,+-.
|Client| |Server| |DB|
`------' `------' `--'
```
### Some limitations of the current implementation
The following points will become separate issues in status-go that I'll work on
over the next couple weeks. In no order of importance:
- Improve how multiple links are fetched; retries on failure and testing how
unfurling behaves around the timeout limits (deterministically, not by making
real HTTP calls as I did). https://github.com/status-im/status-go/issues/3498
- Unfurl favicons and store them in the protobuf too.
- For this PR, I added unfurling support only for websites with OpenGraph
https://ogp.me/ meta tags. Other unfurlers will be implemented on demand. The
next one will probably be for oEmbed https://oembed.com/, the protocol
supported by YouTube, for example.
- Resize and/or compress thumbnails (and favicons). Often times, thumbnails are
huge for the purposes of link previews. There is already support for
compressing JPEGs in status-go, but I prefer to work with compression in a
separate PR because I'd like to also solve the problem for PNGs (probably
convert them to JPEGs, plus compress them). This would be a safe choice for
thumbnails, favicons not so much because transparency is desirable.
- Editing messages is not yet supported.
- I haven't coded any artificial limit on the number of previews or on the size
of the thumbnail payload. This will be done in a separate issue. I have heard
the ideal solution may be to split messages into smaller chunks of ~125 KiB
because of libp2p, but that might be too complicated at this stage of the
product (?).
- Link preview deletion.
- For the moment, OpenGraph metadata is extracted by requesting data for the
English language (and fallback to whatever is available). In the future, we'll
want to unfurl by respecting the user's local device language. Some websites,
like GoDaddy, are already localized based on the device's IP, but many aren't.
- The website's description text should be limited by a certain number of
characters, especially because it's outside our control. Exactly how much has
not been decided yet, so it'll be done separately.
- URL normalization can be tricky, so I implemented only the basics to help with
caching. For example, the url https://status.im and HTTPS://status.im are
considered identical. Also, a URL is considered valid for unfurling if its TLD
exists according to publicsuffix.EffectiveTLDPlusOne. This was essential,
otherwise the default Go url.Parse approach would consider many invalid URLs
valid, and thus the server would waste resources trying to unfurl the
unfurleable.
### Other requirements
- If the message is edited, the link previews should reflect the edited text,
not the original one. This has been aligned with the design team as well.
- If the website's thumbnail or the favicon can't be fetched, just ignore them.
The only mandatory piece of metadata is the website's title and URL.
- Link previews in clients should be generated in near real-time, that is, as
the user types, previews are updated. In mobile this performs very well, and
it's what other clients like WhatsApp, Telegram, and Facebook do.
### Decisions
- While the user typing in the input field, the client is constantly (debounced)
asking status-go to parse the text and extract normalized URLs and then the
client checks if they're already in its in-memory cache. If they are, no RPC
call is made. I chose this approach to achieve the best possible performance
in mobile and avoid the whole RPC overhead, since the chat experience is
already not smooth enough. The mobile client uses URLs as cache keys in a
hashmap, i.e. if the key is present, it means the preview is readily available
(naive, but good enough for now). This decision also gave me more flexibility
to find the best UX at this stage of the feature.
- Due to the requirement that users should be able to see independent loading
indicators for each link preview, when status-go can't unfurl a URL, it
doesn't return it in the response.
- As an initial implementation, I added the BLOB column unfurled_links to the
user_messages table. The preview data is then serialized as JSON before being
stored in this column. I felt that creating a separate table and the related
code for this initial PR would be inconvenient. Is that reasonable to you?
Once things stabilize I can create a proper table if we want to avoid this
kind of solution with serialized columns.
2023-05-18 18:43:06 +00:00
var serializedUnfurledLinks [ ] byte
if links := message . GetUnfurledLinks ( ) ; links != nil {
serializedUnfurledLinks , err = json . Marshal ( links )
if err != nil {
return nil , err
}
}
2019-08-06 21:50:13 +00:00
return [ ] interface { } {
message . ID ,
message . WhisperTimestamp ,
message . From , // source in table
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 . Text ,
2019-08-06 21:50:13 +00:00
message . ContentType ,
2019-09-26 07:01:17 +00:00
message . Alias ,
2019-08-06 21:50:13 +00:00
message . Timestamp ,
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 . ChatId ,
message . LocalChatID ,
2019-08-06 21:50:13 +00:00
message . MessageType ,
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 . Clock ,
2019-08-06 21:50:13 +00:00
message . Seen ,
message . OutgoingStatus ,
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 . ParsedText ,
sticker . Pack ,
sticker . Hash ,
2020-05-13 13:16:17 +00:00
image . Payload ,
image . Type ,
2023-02-02 08:00:49 +00:00
image . AlbumId ,
2023-04-05 13:24:55 +00:00
image . AlbumImagesCount ,
2023-02-02 08:00:49 +00:00
image . Width ,
image . Height ,
2020-05-13 13:16:17 +00:00
message . Base64Image ,
2020-06-17 18:55:49 +00:00
audio . Payload ,
audio . Type ,
2020-06-23 14:30:39 +00:00
audio . DurationMs ,
2020-06-17 18:55:49 +00:00
message . Base64Audio ,
2020-11-18 09:16:51 +00:00
message . CommunityID ,
2020-09-01 10:34:28 +00:00
serializedMentions ,
2020-10-27 17:35:28 +00:00
serializedLinks ,
URL unfurling (initial implementation) (#3471)
This is the initial implementation for the new URL unfurling requirements. The
most important one is that only the message sender will pay the privacy cost for
unfurling and extracting metadata from websites. Once the message is sent, the
unfurled data will be stored at the protocol level and receivers will just
profit and happily decode the metadata to render it.
Further development of this URL unfurling capability will be mostly guided by
issues created on clients. For the moment in status-mobile:
https://github.com/status-im/status-mobile/labels/url-preview
- https://github.com/status-im/status-mobile/issues/15918
- https://github.com/status-im/status-mobile/issues/15917
- https://github.com/status-im/status-mobile/issues/15910
- https://github.com/status-im/status-mobile/issues/15909
- https://github.com/status-im/status-mobile/issues/15908
- https://github.com/status-im/status-mobile/issues/15906
- https://github.com/status-im/status-mobile/issues/15905
### Terminology
In the code, I've tried to stick to the word "unfurl URL" to really mean the
process of extracting metadata from a website, sort of lower level. I use "link
preview" to mean a higher level structure which is enriched by unfurled data.
"link preview" is also how designers refer to it.
### User flows
1. Carol needs to see link previews while typing in the chat input field. Notice
from the diagram nothing is persisted and that status-go endpoints are
essentially stateless.
```
#+begin_src plantuml :results verbatim
Client->>Server: Call wakuext_getTextURLs
Server-->>Client: Normalized URLs
Client->>Client: Render cached unfurled URLs
Client->>Server: Unfurl non-cached URLs.\nCall wakuext_unfurlURLs
Server->>Website: Fetch metadata
Website-->>Server: Metadata (thumbnail URL, title, etc)
Server->>Website: Fetch thumbnail
Server->>Website: Fetch favicon
Website-->>Server: Favicon bytes
Website-->>Server: Thumbnail bytes
Server->>Server: Decode & process images
Server-->>Client: Unfurled data (thumbnail data URI, etc)
#+end_src
```
```
,------. ,------. ,-------.
|Client| |Server| |Website|
`--+---' `--+---' `---+---'
| Call wakuext_getTextURLs | |
| ---------------------------------------> |
| | |
| Normalized URLs | |
| <- - - - - - - - - - - - - - - - - - - - |
| | |
|----. | |
| | Render cached unfurled URLs | |
|<---' | |
| | |
| Unfurl non-cached URLs. | |
| Call wakuext_unfurlURLs | |
| ---------------------------------------> |
| | |
| | Fetch metadata |
| | ------------------------------------>
| | |
| | Metadata (thumbnail URL, title, etc)|
| | <- - - - - - - - - - - - - - - - - -
| | |
| | Fetch thumbnail |
| | ------------------------------------>
| | |
| | Fetch favicon |
| | ------------------------------------>
| | |
| | Favicon bytes |
| | <- - - - - - - - - - - - - - - - - -
| | |
| | Thumbnail bytes |
| | <- - - - - - - - - - - - - - - - - -
| | |
| |----. |
| | | Decode & process images |
| |<---' |
| | |
| Unfurled data (thumbnail data URI, etc)| |
| <- - - - - - - - - - - - - - - - - - - - |
,--+---. ,--+---. ,---+---.
|Client| |Server| |Website|
`------' `------' `-------'
```
2. Carol sends the text message with link previews in the RPC request
wakuext_sendChatMessages. status-go assumes the link previews are good
because it can't and shouldn't attempt to re-unfurl them.
```
#+begin_src plantuml :results verbatim
Client->>Server: Call wakuext_sendChatMessages
Server->>Server: Transform link previews to\nbe proto-marshalled
Server->DB: Write link previews serialized as JSON
Server-->>Client: Updated message response
#+end_src
```
```
,------. ,------. ,--.
|Client| |Server| |DB|
`--+---' `--+---' `+-'
| Call wakuext_sendChatMessages| |
| -----------------------------> |
| | |
| |----. |
| | | Transform link previews to |
| |<---' be proto-marshalled |
| | |
| | |
| | Write link previews serialized as JSON|
| | -------------------------------------->
| | |
| Updated message response | |
| <- - - - - - - - - - - - - - - |
,--+---. ,--+---. ,+-.
|Client| |Server| |DB|
`------' `------' `--'
```
3. The message was sent over waku and persisted locally in Carol's device. She
should now see the link previews in the chat history. There can be many link
previews shared by other chat members, therefore it is important to serve the
assets via the media server to avoid overloading the ReactNative bridge with
lots of big JSON payloads containing base64 encoded data URIs (maybe this
concern is meaningless for desktop). When a client is rendering messages with
link previews, they will have the field linkPreviews, and the thumbnail URL
will point to the local media server.
```
#+begin_src plantuml :results verbatim
Client->>Server: GET /link-preview/thumbnail (media server)
Server->>DB: Read from user_messages.unfurled_links
Server->Server: Unmarshal JSON
Server-->>Client: HTTP Content-Type: image/jpeg/etc
#+end_src
```
```
,------. ,------. ,--.
|Client| |Server| |DB|
`--+---' `--+---' `+-'
| GET /link-preview/thumbnail (media server)| |
| ------------------------------------------> |
| | |
| | Read from user_messages.unfurled_links|
| | -------------------------------------->
| | |
| |----. |
| | | Unmarshal JSON |
| |<---' |
| | |
| HTTP Content-Type: image/jpeg/etc | |
| <- - - - - - - - - - - - - - - - - - - - - |
,--+---. ,--+---. ,+-.
|Client| |Server| |DB|
`------' `------' `--'
```
### Some limitations of the current implementation
The following points will become separate issues in status-go that I'll work on
over the next couple weeks. In no order of importance:
- Improve how multiple links are fetched; retries on failure and testing how
unfurling behaves around the timeout limits (deterministically, not by making
real HTTP calls as I did). https://github.com/status-im/status-go/issues/3498
- Unfurl favicons and store them in the protobuf too.
- For this PR, I added unfurling support only for websites with OpenGraph
https://ogp.me/ meta tags. Other unfurlers will be implemented on demand. The
next one will probably be for oEmbed https://oembed.com/, the protocol
supported by YouTube, for example.
- Resize and/or compress thumbnails (and favicons). Often times, thumbnails are
huge for the purposes of link previews. There is already support for
compressing JPEGs in status-go, but I prefer to work with compression in a
separate PR because I'd like to also solve the problem for PNGs (probably
convert them to JPEGs, plus compress them). This would be a safe choice for
thumbnails, favicons not so much because transparency is desirable.
- Editing messages is not yet supported.
- I haven't coded any artificial limit on the number of previews or on the size
of the thumbnail payload. This will be done in a separate issue. I have heard
the ideal solution may be to split messages into smaller chunks of ~125 KiB
because of libp2p, but that might be too complicated at this stage of the
product (?).
- Link preview deletion.
- For the moment, OpenGraph metadata is extracted by requesting data for the
English language (and fallback to whatever is available). In the future, we'll
want to unfurl by respecting the user's local device language. Some websites,
like GoDaddy, are already localized based on the device's IP, but many aren't.
- The website's description text should be limited by a certain number of
characters, especially because it's outside our control. Exactly how much has
not been decided yet, so it'll be done separately.
- URL normalization can be tricky, so I implemented only the basics to help with
caching. For example, the url https://status.im and HTTPS://status.im are
considered identical. Also, a URL is considered valid for unfurling if its TLD
exists according to publicsuffix.EffectiveTLDPlusOne. This was essential,
otherwise the default Go url.Parse approach would consider many invalid URLs
valid, and thus the server would waste resources trying to unfurl the
unfurleable.
### Other requirements
- If the message is edited, the link previews should reflect the edited text,
not the original one. This has been aligned with the design team as well.
- If the website's thumbnail or the favicon can't be fetched, just ignore them.
The only mandatory piece of metadata is the website's title and URL.
- Link previews in clients should be generated in near real-time, that is, as
the user types, previews are updated. In mobile this performs very well, and
it's what other clients like WhatsApp, Telegram, and Facebook do.
### Decisions
- While the user typing in the input field, the client is constantly (debounced)
asking status-go to parse the text and extract normalized URLs and then the
client checks if they're already in its in-memory cache. If they are, no RPC
call is made. I chose this approach to achieve the best possible performance
in mobile and avoid the whole RPC overhead, since the chat experience is
already not smooth enough. The mobile client uses URLs as cache keys in a
hashmap, i.e. if the key is present, it means the preview is readily available
(naive, but good enough for now). This decision also gave me more flexibility
to find the best UX at this stage of the feature.
- Due to the requirement that users should be able to see independent loading
indicators for each link preview, when status-go can't unfurl a URL, it
doesn't return it in the response.
- As an initial implementation, I added the BLOB column unfurled_links to the
user_messages table. The preview data is then serialized as JSON before being
stored in this column. I felt that creating a separate table and the related
code for this initial PR would be inconvenient. Is that reasonable to you?
Once things stabilize I can create a proper table if we want to avoid this
kind of solution with serialized columns.
2023-05-18 18:43:06 +00:00
serializedUnfurledLinks ,
2020-01-10 18:59:01 +00:00
command . ID ,
command . Value ,
command . From ,
command . Address ,
command . Contract ,
command . TransactionHash ,
command . CommandState ,
command . Signature ,
Add replies to messages
Currently replies to messages are handled in status-react.
This causes some issues with the fact that sometimes replies might come
out of order, they might be offloaded to the database etc.
This commit changes the behavior so that status-go always returns the
replies, and in case a reply comes out of order (first the reply, later
the message being replied to), it will include in the messages the
updated message.
It also adds some fields (RTL,Replace,LineCount) to the database which
were not previously saved, resulting in some potential bugs.
The method that we use to pull replies is currently a bit naive, we just
pull all the message again from the database, but has the advantage of
being simple. It will go through performance testing to make sure
performnace are acceptable, if so I think it's reasonable to avoid some
complexity.
2020-04-08 13:42:02 +00:00
message . Replace ,
2021-06-07 11:45:06 +00:00
int64 ( message . EditedAt ) ,
2021-07-26 21:06:32 +00:00
message . Deleted ,
2023-02-01 00:57:35 +00:00
message . DeletedBy ,
2022-09-28 11:42:17 +00:00
message . DeletedForMe ,
Add replies to messages
Currently replies to messages are handled in status-react.
This causes some issues with the fact that sometimes replies might come
out of order, they might be offloaded to the database etc.
This commit changes the behavior so that status-go always returns the
replies, and in case a reply comes out of order (first the reply, later
the message being replied to), it will include in the messages the
updated message.
It also adds some fields (RTL,Replace,LineCount) to the database which
were not previously saved, resulting in some potential bugs.
The method that we use to pull replies is currently a bit naive, we just
pull all the message again from the database, but has the advantage of
being simple. It will go through performance testing to make sure
performnace are acceptable, if so I think it's reasonable to avoid some
complexity.
2020-04-08 13:42:02 +00:00
message . RTL ,
message . LineCount ,
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 . ResponseTo ,
2021-03-25 15:15:22 +00:00
gapFrom ,
gapTo ,
2022-01-18 16:31:34 +00:00
message . ContactRequestState ,
2022-08-31 14:41:58 +00:00
message . ContactVerificationState ,
2021-05-25 09:40:02 +00:00
message . Mentioned ,
2023-01-10 17:59:32 +00:00
message . Replied ,
2022-08-04 16:16:56 +00:00
discordMessage . Id ,
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
} , nil
2019-08-06 21:50:13 +00:00
}
2020-09-01 13:27:01 +00:00
func ( db sqlitePersistence ) messageByID ( tx * sql . Tx , id string ) ( * common . Message , error ) {
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
var err error
if tx == nil {
tx , err = db . db . BeginTx ( context . Background ( ) , & sql . TxOptions { } )
if err != nil {
return nil , err
}
defer func ( ) {
if err == nil {
err = tx . Commit ( )
return
}
// don't shadow original error
_ = tx . Rollback ( )
} ( )
}
2022-08-25 17:20:26 +00:00
query := db . buildMessagesQuery ( "WHERE m1.id = ?" )
2022-09-20 09:13:44 +00:00
rows , err := tx . Query ( query , id )
if err != nil {
2019-08-06 21:50:13 +00:00
return nil , err
}
2022-09-20 09:13:44 +00:00
defer rows . Close ( )
return getMessageFromScanRows ( db , rows )
2019-08-06 21:50:13 +00:00
}
2023-03-31 09:15:06 +00:00
func ( db sqlitePersistence ) albumMessages ( chatID , albumID string ) ( [ ] * common . Message , error ) {
query := db . buildMessagesQuery ( "WHERE m1.album_id = ? and m1.local_chat_id = ?" )
rows , err := db . db . Query ( query , albumID , chatID )
if err != nil {
return nil , err
}
defer rows . Close ( )
return getMessagesFromScanRows ( db , rows , false )
}
2020-09-01 13:27:01 +00:00
func ( db sqlitePersistence ) MessageByCommandID ( chatID , id string ) ( * common . Message , error ) {
2020-01-10 18:59:01 +00:00
2022-08-25 17:20:26 +00:00
where := ` WHERE
m1 . command_id = ?
AND
m1 . local_chat_id = ?
ORDER BY m1 . clock_value DESC
LIMIT 1 `
query := db . buildMessagesQuery ( where )
2022-09-20 09:13:44 +00:00
rows , err := db . db . Query ( query , id , chatID )
if err != nil {
2020-01-10 18:59:01 +00:00
return nil , err
}
2022-09-20 09:13:44 +00:00
defer rows . Close ( )
return getMessageFromScanRows ( db , rows )
2020-01-10 18:59:01 +00:00
}
2020-09-01 13:27:01 +00:00
func ( db sqlitePersistence ) MessageByID ( id string ) ( * common . Message , error ) {
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
return db . messageByID ( nil , id )
}
2023-03-31 09:15:06 +00:00
func ( db sqlitePersistence ) AlbumMessages ( chatID , albumID string ) ( [ ] * common . Message , error ) {
return db . albumMessages ( chatID , albumID )
}
2019-08-20 11:20:25 +00:00
func ( db sqlitePersistence ) MessagesExist ( ids [ ] string ) ( map [ string ] bool , error ) {
result := make ( map [ string ] bool )
if len ( ids ) == 0 {
2019-08-06 21:50:13 +00:00
return result , nil
}
2019-08-20 11:20:25 +00:00
idsArgs := make ( [ ] interface { } , 0 , len ( ids ) )
for _ , id := range ids {
idsArgs = append ( idsArgs , id )
}
inVector := strings . Repeat ( "?, " , len ( ids ) - 1 ) + "?"
2020-02-10 11:22:37 +00:00
query := "SELECT id FROM user_messages WHERE id IN (" + inVector + ")" // nolint: gosec
2019-08-20 11:20:25 +00:00
rows , err := db . db . Query ( query , idsArgs ... )
if err != nil {
return nil , err
}
defer rows . Close ( )
for rows . Next ( ) {
var id string
err := rows . Scan ( & id )
if err != nil {
return nil , err
}
result [ id ] = true
}
return result , nil
2019-08-06 21:50:13 +00:00
}
2020-09-01 13:27:01 +00:00
func ( db sqlitePersistence ) MessagesByIDs ( ids [ ] string ) ( [ ] * common . Message , error ) {
Add replies to messages
Currently replies to messages are handled in status-react.
This causes some issues with the fact that sometimes replies might come
out of order, they might be offloaded to the database etc.
This commit changes the behavior so that status-go always returns the
replies, and in case a reply comes out of order (first the reply, later
the message being replied to), it will include in the messages the
updated message.
It also adds some fields (RTL,Replace,LineCount) to the database which
were not previously saved, resulting in some potential bugs.
The method that we use to pull replies is currently a bit naive, we just
pull all the message again from the database, but has the advantage of
being simple. It will go through performance testing to make sure
performnace are acceptable, if so I think it's reasonable to avoid some
complexity.
2020-04-08 13:42:02 +00:00
if len ( ids ) == 0 {
return nil , nil
}
idsArgs := make ( [ ] interface { } , 0 , len ( ids ) )
for _ , id := range ids {
idsArgs = append ( idsArgs , id )
}
inVector := strings . Repeat ( "?, " , len ( ids ) - 1 ) + "?"
// nolint: gosec
2022-08-25 17:20:26 +00:00
where := fmt . Sprintf ( "WHERE NOT(m1.hide) AND m1.id IN (%s)" , inVector )
query := db . buildMessagesQuery ( where )
rows , err := db . db . Query ( query , idsArgs ... )
Add replies to messages
Currently replies to messages are handled in status-react.
This causes some issues with the fact that sometimes replies might come
out of order, they might be offloaded to the database etc.
This commit changes the behavior so that status-go always returns the
replies, and in case a reply comes out of order (first the reply, later
the message being replied to), it will include in the messages the
updated message.
It also adds some fields (RTL,Replace,LineCount) to the database which
were not previously saved, resulting in some potential bugs.
The method that we use to pull replies is currently a bit naive, we just
pull all the message again from the database, but has the advantage of
being simple. It will go through performance testing to make sure
performnace are acceptable, if so I think it's reasonable to avoid some
complexity.
2020-04-08 13:42:02 +00:00
if err != nil {
return nil , err
}
defer rows . Close ( )
2022-10-07 17:38:28 +00:00
return getMessagesFromScanRows ( db , rows , false )
Add replies to messages
Currently replies to messages are handled in status-react.
This causes some issues with the fact that sometimes replies might come
out of order, they might be offloaded to the database etc.
This commit changes the behavior so that status-go always returns the
replies, and in case a reply comes out of order (first the reply, later
the message being replied to), it will include in the messages the
updated message.
It also adds some fields (RTL,Replace,LineCount) to the database which
were not previously saved, resulting in some potential bugs.
The method that we use to pull replies is currently a bit naive, we just
pull all the message again from the database, but has the advantage of
being simple. It will go through performance testing to make sure
performnace are acceptable, if so I think it's reasonable to avoid some
complexity.
2020-04-08 13:42:02 +00:00
}
2023-04-17 14:44:48 +00:00
func ( db sqlitePersistence ) MessagesByResponseTo ( responseTo string ) ( [ ] * common . Message , error ) {
where := "WHERE m1.response_to = ?"
query := db . buildMessagesQuery ( where )
rows , err := db . db . Query ( query , responseTo )
if err != nil {
return nil , err
}
defer rows . Close ( )
return getMessagesFromScanRows ( db , rows , false )
}
2019-08-06 21:50:13 +00:00
// MessageByChatID returns all messages for a given chatID in descending order.
// Ordering is accomplished using two concatenated values: ClockValue and ID.
// These two values are also used to compose a cursor which is returned to the result.
2020-09-01 13:27:01 +00:00
func ( db sqlitePersistence ) MessageByChatID ( chatID string , currCursor string , limit int ) ( [ ] * common . Message , string , error ) {
2019-08-06 21:50:13 +00:00
cursorWhere := ""
if currCursor != "" {
2020-11-05 16:07:24 +00:00
cursorWhere = "AND cursor <= ?" //nolint: goconst
2019-08-06 21:50:13 +00:00
}
args := [ ] interface { } { chatID }
if currCursor != "" {
args = append ( args , currCursor )
}
// Build a new column `cursor` at the query time by having a fixed-sized clock value at the beginning
2019-09-26 07:01:17 +00:00
// concatenated with message ID. Results are sorted using this new column.
2019-08-06 21:50:13 +00:00
// This new column values can also be returned as a cursor for subsequent requests.
2022-08-25 17:20:26 +00:00
where := fmt . Sprintf ( `
WHERE
2022-12-08 10:13:56 +00:00
NOT ( m1 . hide ) AND m1 . local_chat_id = ? % s
2022-08-25 17:20:26 +00:00
ORDER BY cursor DESC
LIMIT ? ` , cursorWhere )
2022-08-04 16:16:56 +00:00
2022-08-25 17:20:26 +00:00
query := db . buildMessagesQueryWithAdditionalFields ( cursorField , where )
2022-08-04 16:16:56 +00:00
2022-08-25 17:20:26 +00:00
rows , err := db . db . Query (
query ,
2019-08-06 21:50:13 +00:00
append ( args , limit + 1 ) ... , // take one more to figure our whether a cursor should be returned
)
if err != nil {
return nil , "" , err
}
defer rows . Close ( )
2022-09-20 09:13:44 +00:00
result , cursors , err := getMessagesAndCursorsFromScanRows ( db , rows )
if err != nil {
return nil , "" , err
2019-08-06 21:50:13 +00:00
}
var newCursor string
if len ( result ) > limit {
newCursor = cursors [ limit ]
result = result [ : limit ]
}
return result , newCursor , nil
}
2022-12-11 19:08:51 +00:00
func ( db sqlitePersistence ) FirstUnseenMessageID ( chatID string ) ( string , error ) {
var id string
2023-04-26 17:02:01 +00:00
err := db . db . QueryRow ( `
2022-12-11 19:08:51 +00:00
SELECT
id
FROM
user_messages m1
WHERE
2023-04-26 17:02:01 +00:00
m1 . local_chat_id = ?
AND NOT ( m1 . seen ) AND NOT ( m1 . hide ) AND NOT ( m1 . deleted ) AND NOT ( m1 . deleted_for_me )
ORDER BY m1 . clock_value ASC
LIMIT 1 ` ,
2022-12-11 19:08:51 +00:00
chatID ) . Scan ( & id )
if err == sql . ErrNoRows {
return "" , nil
}
if err != nil {
return "" , err
}
return id , nil
}
2022-11-17 10:11:58 +00:00
// Get last chat message that is not hide or deleted or deleted_for_me
func ( db sqlitePersistence ) LatestMessageByChatID ( chatID string ) ( [ ] * common . Message , error ) {
args := [ ] interface { } { chatID }
where := ` WHERE
NOT ( m1 . hide ) AND NOT ( m1 . deleted ) AND NOT ( m1 . deleted_for_me ) AND m1 . local_chat_id = ?
ORDER BY cursor DESC
LIMIT ? `
query := db . buildMessagesQueryWithAdditionalFields ( cursorField , where )
rows , err := db . db . Query (
query ,
append ( args , 2 ) ... , // take one more to figure our whether a cursor should be returned
)
if err != nil {
return nil , err
}
defer rows . Close ( )
result , _ , err := getMessagesAndCursorsFromScanRows ( db , rows )
if err != nil {
return nil , err
}
if len ( result ) > 1 {
result = result [ : 1 ]
}
return result , nil
}
2022-06-21 16:31:15 +00:00
func ( db sqlitePersistence ) latestIncomingMessageClock ( chatID string ) ( uint64 , error ) {
var clock uint64
err := db . db . QueryRow (
2022-08-25 17:20:26 +00:00
fmt . Sprintf (
`
2022-06-21 16:31:15 +00:00
SELECT
clock_value
FROM
user_messages m1
WHERE
m1 . local_chat_id = ? AND m1 . outgoing_status = ' '
2022-08-25 17:20:26 +00:00
% s DESC
2022-06-21 16:31:15 +00:00
LIMIT 1
2022-08-25 17:20:26 +00:00
` , cursor ) ,
chatID ) . Scan ( & clock )
2022-06-21 16:31:15 +00:00
if err != nil {
return 0 , err
}
return clock , nil
}
2022-01-18 16:31:34 +00:00
func ( db sqlitePersistence ) PendingContactRequests ( currCursor string , limit int ) ( [ ] * common . Message , string , error ) {
cursorWhere := ""
if currCursor != "" {
cursorWhere = "AND cursor <= ?" //nolint: goconst
}
args := [ ] interface { } { protobuf . ChatMessage_CONTACT_REQUEST }
if currCursor != "" {
args = append ( args , currCursor )
}
// Build a new column `cursor` at the query time by having a fixed-sized clock value at the beginning
// concatenated with message ID. Results are sorted using this new column.
// This new column values can also be returned as a cursor for subsequent requests.
2022-08-25 17:20:26 +00:00
where := fmt . Sprintf ( `
WHERE
NOT ( m1 . hide ) AND NOT ( m1 . seen ) AND m1 . content_type = ? % s
ORDER BY cursor DESC
LIMIT ? ` , cursorWhere )
2022-01-18 16:31:34 +00:00
2022-08-25 17:20:26 +00:00
query := db . buildMessagesQueryWithAdditionalFields ( cursorField , where )
rows , err := db . db . Query (
query ,
2022-01-18 16:31:34 +00:00
append ( args , limit + 1 ) ... , // take one more to figure our whether a cursor should be returned
)
if err != nil {
return nil , "" , err
}
defer rows . Close ( )
2022-09-20 09:13:44 +00:00
result , cursors , err := getMessagesAndCursorsFromScanRows ( db , rows )
if err != nil {
return nil , "" , err
2022-01-18 16:31:34 +00:00
}
var newCursor string
if len ( result ) > limit {
newCursor = cursors [ limit ]
result = result [ : limit ]
}
return result , newCursor , nil
}
2022-06-17 16:20:43 +00:00
func ( db sqlitePersistence ) LatestPendingContactRequestIDForContact ( contactID string ) ( string , error ) {
var id string
err := db . db . QueryRow (
2022-08-25 17:20:26 +00:00
fmt . Sprintf (
`
2022-06-17 16:20:43 +00:00
SELECT
id
FROM
user_messages m1
WHERE
m1 . local_chat_id = ? AND m1 . content_type = ?
2022-08-25 17:20:26 +00:00
ORDER BY % s DESC
2022-06-17 16:20:43 +00:00
LIMIT 1
2022-08-25 17:20:26 +00:00
` , cursor ) ,
contactID , protobuf . ChatMessage_CONTACT_REQUEST ) . Scan ( & id )
2022-06-24 13:08:14 +00:00
if err == sql . ErrNoRows {
return "" , nil
}
2022-06-17 16:20:43 +00:00
if err != nil {
return "" , err
}
return id , nil
}
2022-08-25 17:20:26 +00:00
func ( db sqlitePersistence ) LatestContactRequestIDs ( ) ( map [ string ] common . ContactRequestState , error ) {
res := map [ string ] common . ContactRequestState { }
rows , err := db . db . Query (
fmt . Sprintf (
`
SELECT
id , contact_request_state
FROM
user_messages m1
WHERE
m1 . content_type = ?
ORDER BY % s DESC
LIMIT 20
` , cursor ) , protobuf . ChatMessage_CONTACT_REQUEST )
if err != nil {
return res , err
}
2023-01-13 17:12:46 +00:00
defer rows . Close ( )
2022-08-25 17:20:26 +00:00
for rows . Next ( ) {
var id string
var contactRequestState sql . NullInt64
err := rows . Scan ( & id , & contactRequestState )
if err != nil {
return nil , err
}
res [ id ] = common . ContactRequestState ( contactRequestState . Int64 )
}
return res , nil
}
2021-08-04 19:31:44 +00:00
// AllMessageByChatIDWhichMatchPattern returns all messages which match the search
// term, for a given chatID in descending order.
// Ordering is accomplished using two concatenated values: ClockValue and ID.
// These two values are also used to compose a cursor which is returned to the result.
func ( db sqlitePersistence ) AllMessageByChatIDWhichMatchTerm ( chatID string , searchTerm string , caseSensitive bool ) ( [ ] * common . Message , error ) {
if searchTerm == "" {
return nil , fmt . Errorf ( "empty search term" )
}
searchCond := ""
if caseSensitive {
searchCond = "AND m1.text LIKE '%' || ? || '%'"
} else {
searchCond = "AND LOWER(m1.text) LIKE LOWER('%' || ? || '%')"
}
2022-08-25 17:20:26 +00:00
where := fmt . Sprintf ( `
WHERE
NOT ( m1 . hide ) AND m1 . local_chat_id = ? % s
ORDER BY cursor DESC ` , searchCond )
2021-08-04 19:31:44 +00:00
2022-08-25 17:20:26 +00:00
query := db . buildMessagesQueryWithAdditionalFields ( cursorField , where )
2021-08-04 19:31:44 +00:00
rows , err := db . db . Query (
2022-08-25 17:20:26 +00:00
query ,
2021-08-04 19:31:44 +00:00
chatID , searchTerm ,
)
if err != nil {
return nil , err
}
defer rows . Close ( )
2022-10-07 17:38:28 +00:00
return getMessagesFromScanRows ( db , rows , true )
2021-08-04 19:31:44 +00:00
}
2021-08-19 19:47:03 +00:00
// AllMessagesFromChatsAndCommunitiesWhichMatchTerm returns all messages which match the search
// term, if they belong to either any chat from the chatIds array or any channel of any community
// from communityIds array.
// Ordering is accomplished using two concatenated values: ClockValue and ID.
// These two values are also used to compose a cursor which is returned to the result.
func ( db sqlitePersistence ) AllMessagesFromChatsAndCommunitiesWhichMatchTerm ( communityIds [ ] string , chatIds [ ] string , searchTerm string , caseSensitive bool ) ( [ ] * common . Message , error ) {
if searchTerm == "" {
return nil , fmt . Errorf ( "empty search term" )
}
chatsCond := ""
if len ( chatIds ) > 0 {
inVector := strings . Repeat ( "?, " , len ( chatIds ) - 1 ) + "?"
chatsCond = ` m1.local_chat_id IN (%s) `
chatsCond = fmt . Sprintf ( chatsCond , inVector )
}
communitiesCond := ""
if len ( communityIds ) > 0 {
inVector := strings . Repeat ( "?, " , len ( communityIds ) - 1 ) + "?"
communitiesCond = ` m1.local_chat_id IN (SELECT id FROM chats WHERE community_id IN (%s)) `
communitiesCond = fmt . Sprintf ( communitiesCond , inVector )
}
searchCond := ""
if caseSensitive {
searchCond = "m1.text LIKE '%' || ? || '%'"
} else {
searchCond = "LOWER(m1.text) LIKE LOWER('%' || ? || '%')"
}
finalCond := "AND %s AND %s"
if len ( communityIds ) > 0 && len ( chatIds ) > 0 {
finalCond = "AND (%s OR %s) AND %s"
finalCond = fmt . Sprintf ( finalCond , chatsCond , communitiesCond , searchCond )
} else if len ( chatIds ) > 0 {
finalCond = fmt . Sprintf ( finalCond , chatsCond , searchCond )
} else if len ( communityIds ) > 0 {
finalCond = fmt . Sprintf ( finalCond , communitiesCond , searchCond )
} else {
return nil , fmt . Errorf ( "you must specify either community ids or chat ids or both" )
}
var parameters [ ] string
parameters = append ( parameters , chatIds ... )
parameters = append ( parameters , communityIds ... )
parameters = append ( parameters , searchTerm )
idsArgs := make ( [ ] interface { } , 0 , len ( parameters ) )
for _ , param := range parameters {
idsArgs = append ( idsArgs , param )
}
2022-08-25 17:20:26 +00:00
where := fmt . Sprintf ( `
WHERE
NOT ( m1 . hide ) % s
ORDER BY cursor DESC ` , finalCond )
2021-08-19 19:47:03 +00:00
2022-08-25 17:20:26 +00:00
finalQuery := db . buildMessagesQueryWithAdditionalFields ( cursorField , where )
2021-08-19 19:47:03 +00:00
rows , err := db . db . Query ( finalQuery , idsArgs ... )
if err != nil {
return nil , err
}
defer rows . Close ( )
2022-10-07 17:38:28 +00:00
return getMessagesFromScanRows ( db , rows , true )
2021-08-19 19:47:03 +00:00
}
2021-09-20 06:33:36 +00:00
func ( db sqlitePersistence ) AllChatIDsByCommunity ( communityID string ) ( [ ] string , error ) {
rows , err := db . db . Query ( "SELECT id FROM chats WHERE community_id = ?" , communityID )
if err != nil {
return nil , err
}
defer rows . Close ( )
var rst [ ] string
for rows . Next ( ) {
var chatID string
err = rows . Scan ( & chatID )
if err != nil {
return nil , err
}
rst = append ( rst , chatID )
}
return rst , nil
}
2023-03-28 14:40:00 +00:00
func ( db sqlitePersistence ) CountActiveChattersInCommunity ( communityID string , activeAfterTimestamp int64 ) ( uint , error ) {
var activeChattersCount uint
err := db . db . QueryRow (
`
SELECT COUNT ( DISTINCT source )
FROM user_messages
JOIN chats ON user_messages . local_chat_id = chats . id
WHERE chats . community_id = ?
AND user_messages . timestamp >= ?
` , communityID , activeAfterTimestamp ) . Scan ( & activeChattersCount )
if err == sql . ErrNoRows {
return 0 , nil
}
if err != nil {
return 0 , err
}
return activeChattersCount , nil
}
2021-05-14 21:22:50 +00:00
// PinnedMessageByChatID returns all pinned messages for a given chatID in descending order.
// Ordering is accomplished using two concatenated values: ClockValue and ID.
// These two values are also used to compose a cursor which is returned to the result.
func ( db sqlitePersistence ) PinnedMessageByChatIDs ( chatIDs [ ] string , currCursor string , limit int ) ( [ ] * common . PinnedMessage , string , error ) {
cursorWhere := ""
if currCursor != "" {
cursorWhere = "AND cursor <= ?" //nolint: goconst
}
args := make ( [ ] interface { } , len ( chatIDs ) )
for i , v := range chatIDs {
args [ i ] = v
}
if currCursor != "" {
args = append ( args , currCursor )
}
2022-02-09 21:58:33 +00:00
limitStr := ""
if limit > - 1 {
args = append ( args , limit + 1 ) // take one more to figure our whether a cursor should be returned
}
2021-05-14 21:22:50 +00:00
// Build a new column `cursor` at the query time by having a fixed-sized clock value at the beginning
// concatenated with message ID. Results are sorted using this new column.
// This new column values can also be returned as a cursor for subsequent requests.
2022-08-25 17:20:26 +00:00
allFields := db . tableUserMessagesAllFieldsJoin ( )
2021-05-14 21:22:50 +00:00
rows , err := db . db . Query (
fmt . Sprintf ( `
2022-08-25 17:20:26 +00:00
SELECT
% s ,
pm . clock_value as pinnedAt ,
pm . pinned_by as pinnedBy ,
% s
FROM
pin_messages pm
JOIN
user_messages m1
ON
pm . message_id = m1 . id
LEFT JOIN
user_messages m2
ON
m1 . response_to = m2 . id
LEFT JOIN
contacts c
ON
m1 . source = c . id
LEFT JOIN
discord_messages dm
ON
m1 . discord_message_id = dm . id
LEFT JOIN
discord_message_authors dm_author
ON
dm . author_id = dm_author . id
2023-04-17 14:44:48 +00:00
LEFT JOIN
2022-09-20 09:13:44 +00:00
discord_message_attachments dm_attachment
2023-04-17 14:44:48 +00:00
ON
2023-01-13 15:28:49 +00:00
dm . id = dm_attachment . discord_message_id
2023-04-17 14:44:48 +00:00
LEFT JOIN
2023-01-13 15:28:49 +00:00
discord_messages m2_dm
2023-04-17 14:44:48 +00:00
ON
2023-01-13 15:28:49 +00:00
m2 . discord_message_id = m2_dm . id
2023-04-17 14:44:48 +00:00
LEFT JOIN
2023-01-13 15:28:49 +00:00
discord_message_authors m2_dm_author
2023-04-17 14:44:48 +00:00
ON
2023-01-13 15:28:49 +00:00
m2_dm . author_id = m2_dm_author . id
2022-09-20 09:13:44 +00:00
2022-08-25 17:20:26 +00:00
WHERE
pm . pinned = 1
AND NOT ( m1 . hide ) AND m1 . local_chat_id IN % s % s
ORDER BY cursor DESC
% s
` , allFields , cursorField , "(?" + strings . Repeat ( ",?" , len ( chatIDs ) - 1 ) + ")" , cursorWhere , limitStr ) ,
2022-02-09 21:58:33 +00:00
args ... , // take one more to figure our whether a cursor should be returned
2021-05-14 21:22:50 +00:00
)
if err != nil {
return nil , "" , err
}
defer rows . Close ( )
2022-09-20 09:13:44 +00:00
result , cursors , err := getPinnedMessagesAndCursorsFromScanRows ( db , rows )
if err != nil {
return nil , "" , err
2021-05-14 21:22:50 +00:00
}
var newCursor string
2022-02-09 21:58:33 +00:00
if limit > - 1 && len ( result ) > limit && cursors != nil {
2021-05-14 21:22:50 +00:00
newCursor = cursors [ limit ]
result = result [ : limit ]
}
return result , newCursor , nil
}
func ( db sqlitePersistence ) PinnedMessageByChatID ( chatID string , currCursor string , limit int ) ( [ ] * common . PinnedMessage , string , error ) {
return db . PinnedMessageByChatIDs ( [ ] string { chatID } , currCursor , limit )
}
2020-11-03 10:16:05 +00:00
// MessageByChatIDs returns all messages for a given chatIDs in descending order.
// Ordering is accomplished using two concatenated values: ClockValue and ID.
// These two values are also used to compose a cursor which is returned to the result.
func ( db sqlitePersistence ) MessageByChatIDs ( chatIDs [ ] string , currCursor string , limit int ) ( [ ] * common . Message , string , error ) {
cursorWhere := ""
if currCursor != "" {
2020-11-05 16:07:24 +00:00
cursorWhere = "AND cursor <= ?" //nolint: goconst
2020-11-03 10:16:05 +00:00
}
args := make ( [ ] interface { } , len ( chatIDs ) )
for i , v := range chatIDs {
args [ i ] = v
}
if currCursor != "" {
args = append ( args , currCursor )
}
// Build a new column `cursor` at the query time by having a fixed-sized clock value at the beginning
// concatenated with message ID. Results are sorted using this new column.
// This new column values can also be returned as a cursor for subsequent requests.
2022-08-25 17:20:26 +00:00
where := fmt . Sprintf ( `
2020-11-03 10:16:05 +00:00
WHERE
NOT ( m1 . hide ) AND m1 . local_chat_id IN % s % s
ORDER BY cursor DESC
LIMIT ?
2022-08-25 17:20:26 +00:00
` , "(?" + strings . Repeat ( ",?" , len ( chatIDs ) - 1 ) + ")" , cursorWhere )
query := db . buildMessagesQueryWithAdditionalFields ( cursorField , where )
rows , err := db . db . Query (
query ,
2020-11-03 10:16:05 +00:00
append ( args , limit + 1 ) ... , // take one more to figure our whether a cursor should be returned
)
if err != nil {
return nil , "" , err
}
defer rows . Close ( )
2022-09-20 09:13:44 +00:00
result , cursors , err := getMessagesAndCursorsFromScanRows ( db , rows )
if err != nil {
return nil , "" , err
2020-11-03 10:16:05 +00:00
}
var newCursor string
if len ( result ) > limit {
newCursor = cursors [ limit ]
result = result [ : limit ]
}
return result , newCursor , nil
}
2022-09-02 08:36:07 +00:00
func ( db sqlitePersistence ) OldestMessageWhisperTimestampByChatID ( chatID string ) ( timestamp uint64 , hasAnyMessage bool , err error ) {
var whisperTimestamp uint64
err = db . db . QueryRow (
`
SELECT
whisper_timestamp
FROM
user_messages m1
WHERE
m1 . local_chat_id = ?
ORDER BY substr ( ' 0000000000000000000000000000000000000000000000000000000000000000 ' || m1 . clock_value , - 64 , 64 ) || m1 . id ASC
LIMIT 1
` , chatID ) . Scan ( & whisperTimestamp )
if err == sql . ErrNoRows {
return 0 , false , nil
}
if err != nil {
return 0 , false , err
}
return whisperTimestamp , true , nil
}
2020-07-27 15:57:01 +00:00
// EmojiReactionsByChatID returns the emoji reactions for the queried messages, up to a maximum of 100, as it's a potentially unbound number.
// NOTE: This is not completely accurate, as the messages in the database might have change since the last call to `MessageByChatID`.
func ( db sqlitePersistence ) EmojiReactionsByChatID ( chatID string , currCursor string , limit int ) ( [ ] * EmojiReaction , error ) {
cursorWhere := ""
if currCursor != "" {
2022-08-25 17:20:26 +00:00
cursorWhere = fmt . Sprintf ( "AND %s <= ?" , cursor ) //nolint: goconst
2020-07-27 15:57:01 +00:00
}
2020-07-28 07:53:32 +00:00
args := [ ] interface { } { chatID , chatID }
2020-07-27 15:57:01 +00:00
if currCursor != "" {
args = append ( args , currCursor )
}
2020-07-28 05:41:50 +00:00
args = append ( args , limit )
2020-07-28 07:53:32 +00:00
// NOTE: We match against local_chat_id for security reasons.
// As a user could potentially send an emoji reaction for a one to
// one/group chat that has no access to.
2020-07-29 12:00:51 +00:00
// We also limit the number of emoji to a reasonable number (1000)
// for now, as we don't want the client to choke on this.
// The issue is that your own emoji might not be returned in such cases,
// allowing the user to react to a post multiple times.
// Jakubgs: Returning the whole list seems like a real overkill.
// This will get very heavy in threads that have loads of reactions on loads of messages.
// A more sensible response would just include a count and a bool telling you if you are in the list.
2020-07-28 08:02:51 +00:00
// nolint: gosec
2020-07-28 05:41:50 +00:00
query := fmt . Sprintf ( `
2020-07-27 15:57:01 +00:00
SELECT
e . clock_value ,
e . source ,
e . emoji_id ,
e . message_id ,
e . chat_id ,
2020-07-28 07:53:32 +00:00
e . local_chat_id ,
2020-07-27 15:57:01 +00:00
e . retracted
FROM
emoji_reactions e
WHERE NOT ( e . retracted )
AND
2020-07-28 07:53:32 +00:00
e . local_chat_id = ?
AND
2020-07-27 15:57:01 +00:00
e . message_id IN
2022-08-25 17:20:26 +00:00
( SELECT id FROM user_messages m1 WHERE NOT ( m1 . hide ) AND m1 . local_chat_id = ? % s
ORDER BY % s DESC LIMIT ? )
2020-07-29 12:00:51 +00:00
LIMIT 1000
2022-08-25 17:20:26 +00:00
` , cursorWhere , cursor )
2020-07-28 05:41:50 +00:00
rows , err := db . db . Query (
2021-11-05 13:48:20 +00:00
query ,
args ... ,
)
if err != nil {
return nil , err
}
defer rows . Close ( )
var result [ ] * EmojiReaction
for rows . Next ( ) {
2023-08-18 11:39:59 +00:00
emojiReaction := NewEmojiReaction ( )
2021-11-05 13:48:20 +00:00
err := rows . Scan ( & emojiReaction . Clock ,
& emojiReaction . From ,
& emojiReaction . Type ,
& emojiReaction . MessageId ,
& emojiReaction . ChatId ,
& emojiReaction . LocalChatID ,
& emojiReaction . Retracted )
if err != nil {
return nil , err
}
2023-08-18 11:39:59 +00:00
result = append ( result , emojiReaction )
2021-11-05 13:48:20 +00:00
}
return result , nil
}
// EmojiReactionsByChatIDMessageID returns the emoji reactions for the queried message.
func ( db sqlitePersistence ) EmojiReactionsByChatIDMessageID ( chatID string , messageID string ) ( [ ] * EmojiReaction , error ) {
args := [ ] interface { } { chatID , messageID }
query := ` SELECT
e . clock_value ,
e . source ,
e . emoji_id ,
e . message_id ,
e . chat_id ,
e . local_chat_id ,
e . retracted
FROM
emoji_reactions e
WHERE NOT ( e . retracted )
AND
e . local_chat_id = ?
AND
e . message_id = ?
LIMIT 1000 `
rows , err := db . db . Query (
2020-07-28 05:41:50 +00:00
query ,
args ... ,
2020-07-27 15:57:01 +00:00
)
if err != nil {
return nil , err
}
defer rows . Close ( )
2020-11-16 11:54:39 +00:00
var result [ ] * EmojiReaction
for rows . Next ( ) {
2023-08-18 11:39:59 +00:00
emojiReaction := NewEmojiReaction ( )
2020-11-16 11:54:39 +00:00
err := rows . Scan ( & emojiReaction . Clock ,
& emojiReaction . From ,
& emojiReaction . Type ,
& emojiReaction . MessageId ,
& emojiReaction . ChatId ,
& emojiReaction . LocalChatID ,
& emojiReaction . Retracted )
if err != nil {
return nil , err
}
2023-08-18 11:39:59 +00:00
result = append ( result , emojiReaction )
2020-11-16 11:54:39 +00:00
}
return result , nil
}
// EmojiReactionsByChatIDs returns the emoji reactions for the queried messages, up to a maximum of 100, as it's a potentially unbound number.
// NOTE: This is not completely accurate, as the messages in the database might have change since the last call to `MessageByChatID`.
func ( db sqlitePersistence ) EmojiReactionsByChatIDs ( chatIDs [ ] string , currCursor string , limit int ) ( [ ] * EmojiReaction , error ) {
cursorWhere := ""
if currCursor != "" {
2022-08-25 17:20:26 +00:00
cursorWhere = fmt . Sprintf ( "AND %s <= ?" , cursor ) //nolint: goconst
2020-11-16 11:54:39 +00:00
}
chatsLen := len ( chatIDs )
args := make ( [ ] interface { } , chatsLen * 2 )
for i , v := range chatIDs {
args [ i ] = v
}
for i , v := range chatIDs {
args [ chatsLen + i ] = v
}
if currCursor != "" {
args = append ( args , currCursor )
}
args = append ( args , limit )
// NOTE: We match against local_chat_id for security reasons.
// As a user could potentially send an emoji reaction for a one to
// one/group chat that has no access to.
// We also limit the number of emoji to a reasonable number (1000)
// for now, as we don't want the client to choke on this.
// The issue is that your own emoji might not be returned in such cases,
// allowing the user to react to a post multiple times.
// Jakubgs: Returning the whole list seems like a real overkill.
// This will get very heavy in threads that have loads of reactions on loads of messages.
// A more sensible response would just include a count and a bool telling you if you are in the list.
// nolint: gosec
query := fmt . Sprintf ( `
SELECT
e . clock_value ,
e . source ,
e . emoji_id ,
e . message_id ,
e . chat_id ,
e . local_chat_id ,
e . retracted
FROM
emoji_reactions e
WHERE NOT ( e . retracted )
AND
e . local_chat_id IN % s
AND
e . message_id IN
( SELECT id FROM user_messages m WHERE NOT ( m . hide ) AND m . local_chat_id IN % s % s
2022-08-25 17:20:26 +00:00
ORDER BY % s DESC LIMIT ? )
2020-11-16 11:54:39 +00:00
LIMIT 1000
2022-08-25 17:20:26 +00:00
` , "(?" + strings . Repeat ( ",?" , chatsLen - 1 ) + ")" , "(?" + strings . Repeat ( ",?" , chatsLen - 1 ) + ")" , cursorWhere , cursor )
2020-11-16 11:54:39 +00:00
rows , err := db . db . Query (
query ,
args ... ,
)
if err != nil {
return nil , err
}
defer rows . Close ( )
2020-07-27 15:57:01 +00:00
var result [ ] * EmojiReaction
for rows . Next ( ) {
2023-08-18 11:39:59 +00:00
emojiReaction := NewEmojiReaction ( )
2020-07-27 15:57:01 +00:00
err := rows . Scan ( & emojiReaction . Clock ,
& emojiReaction . From ,
& emojiReaction . Type ,
& emojiReaction . MessageId ,
& emojiReaction . ChatId ,
2020-07-28 07:53:32 +00:00
& emojiReaction . LocalChatID ,
2020-07-27 15:57:01 +00:00
& emojiReaction . Retracted )
if err != nil {
return nil , err
}
2023-08-18 11:39:59 +00:00
result = append ( result , emojiReaction )
2020-07-27 15:57:01 +00:00
}
return result , nil
}
2020-09-01 13:27:01 +00:00
func ( db sqlitePersistence ) SaveMessages ( messages [ ] * common . Message ) ( err error ) {
2019-11-15 08:52:28 +00:00
tx , err := db . db . BeginTx ( context . Background ( ) , & sql . TxOptions { } )
2019-08-06 21:50:13 +00:00
if err != nil {
2019-11-15 08:52:28 +00:00
return
2019-08-06 21:50:13 +00:00
}
2019-08-20 11:20:25 +00:00
defer func ( ) {
if err == nil {
err = tx . Commit ( )
return
2019-08-06 21:50:13 +00:00
}
2019-08-20 11:20:25 +00:00
// don't shadow original error
_ = tx . Rollback ( )
} ( )
2019-08-06 21:50:13 +00:00
2020-05-20 12:16:12 +00:00
allFields := db . tableUserMessagesAllFields ( )
valuesVector := strings . Repeat ( "?, " , db . tableUserMessagesAllFieldsCount ( ) - 1 ) + "?"
2020-02-10 11:22:37 +00:00
query := "INSERT INTO user_messages(" + allFields + ") VALUES (" + valuesVector + ")" // nolint: gosec
2019-11-15 08:52:28 +00:00
stmt , err := tx . Prepare ( query )
2019-08-06 21:50:13 +00:00
if err != nil {
2019-11-15 08:52:28 +00:00
return
2019-08-06 21:50:13 +00:00
}
2019-08-20 11:20:25 +00:00
for _ , msg := range messages {
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
var allValues [ ] interface { }
2020-05-20 12:16:12 +00:00
allValues , err = db . tableUserMessagesAllValues ( msg )
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
if err != nil {
return
}
_ , err = stmt . Exec ( allValues ... )
2019-08-20 11:20:25 +00:00
if err != nil {
2019-11-15 08:52:28 +00:00
return
2019-08-06 21:50:13 +00:00
}
}
2019-11-15 08:52:28 +00:00
return
2019-08-06 21:50:13 +00:00
}
2023-04-17 14:44:48 +00:00
type insertPinMessagesQueries struct {
selectStmt string
insertStmt * sql . Stmt
updateStmt * sql . Stmt
transaction * sql . Tx
}
func ( db sqlitePersistence ) buildPinMessageQueries ( ) ( * insertPinMessagesQueries , error ) {
2021-05-14 21:22:50 +00:00
tx , err := db . db . BeginTx ( context . Background ( ) , nil )
if err != nil {
2023-04-17 14:44:48 +00:00
return nil , err
2021-05-14 21:22:50 +00:00
}
2023-04-17 14:44:48 +00:00
queries := & insertPinMessagesQueries { }
2021-05-14 21:22:50 +00:00
// select
2023-04-17 14:44:48 +00:00
queries . selectStmt = "SELECT clock_value FROM pin_messages WHERE id = ?"
2021-05-14 21:22:50 +00:00
// insert
2021-06-08 15:23:32 +00:00
allInsertFields := ` id, message_id, whisper_timestamp, chat_id, local_chat_id, clock_value, pinned, pinned_by `
2021-05-14 21:22:50 +00:00
insertValues := strings . Repeat ( "?, " , strings . Count ( allInsertFields , "," ) ) + "?"
insertQuery := "INSERT INTO pin_messages(" + allInsertFields + ") VALUES (" + insertValues + ")" // nolint: gosec
insertStmt , err := tx . Prepare ( insertQuery )
if err != nil {
2023-04-17 14:44:48 +00:00
return nil , err
2021-05-14 21:22:50 +00:00
}
2023-04-17 14:44:48 +00:00
queries . insertStmt = insertStmt
2021-05-14 21:22:50 +00:00
// update
2021-06-08 15:23:32 +00:00
updateQuery := "UPDATE pin_messages SET pinned = ?, clock_value = ?, pinned_by = ? WHERE id = ?"
2021-05-14 21:22:50 +00:00
updateStmt , err := tx . Prepare ( updateQuery )
if err != nil {
2023-04-17 14:44:48 +00:00
return nil , err
2021-05-14 21:22:50 +00:00
}
2023-04-17 14:44:48 +00:00
queries . updateStmt = updateStmt
queries . transaction = tx
return queries , nil
}
2021-05-14 21:22:50 +00:00
2023-04-17 14:44:48 +00:00
func ( db sqlitePersistence ) SavePinMessages ( messages [ ] * common . PinMessage ) ( err error ) {
queries , err := db . buildPinMessageQueries ( )
if err != nil {
return
}
defer func ( ) {
if err == nil {
err = queries . transaction . Commit ( )
return
}
// don't shadow original error
_ = queries . transaction . Rollback ( )
} ( )
2021-05-14 21:22:50 +00:00
for _ , message := range messages {
2023-04-17 14:44:48 +00:00
_ , err = db . savePinMessage ( message , queries )
if err != nil {
return
}
}
return
}
func ( db sqlitePersistence ) savePinMessage ( message * common . PinMessage , queries * insertPinMessagesQueries ) ( inserted bool , err error ) {
tx := queries . transaction
selectQuery := queries . selectStmt
updateStmt := queries . updateStmt
insertStmt := queries . insertStmt
row := tx . QueryRow ( selectQuery , message . ID )
var existingClock uint64
switch err = row . Scan ( & existingClock ) ; err {
case sql . ErrNoRows :
// not found, insert new record
allValues := [ ] interface { } {
message . ID ,
message . MessageId ,
message . WhisperTimestamp ,
message . ChatId ,
message . LocalChatID ,
message . Clock ,
message . Pinned ,
message . From ,
}
_ , err = insertStmt . Exec ( allValues ... )
if err != nil {
return
}
inserted = true
case nil :
// found, update if current message is more recent, otherwise skip
if existingClock < message . Clock {
// update
_ , err = updateStmt . Exec ( message . Pinned , message . Clock , message . From , message . ID )
2021-05-14 21:22:50 +00:00
if err != nil {
return
}
2023-04-17 14:44:48 +00:00
inserted = true
2021-05-14 21:22:50 +00:00
}
2023-04-17 14:44:48 +00:00
default :
return
2021-05-14 21:22:50 +00:00
}
return
}
2023-04-17 14:44:48 +00:00
func ( db sqlitePersistence ) SavePinMessage ( message * common . PinMessage ) ( inserted bool , err error ) {
queries , err := db . buildPinMessageQueries ( )
if err != nil {
return
}
defer func ( ) {
if err == nil {
err = queries . transaction . Commit ( )
return
}
// don't shadow original error
_ = queries . transaction . Rollback ( )
} ( )
return db . savePinMessage ( message , queries )
}
2019-08-06 21:50:13 +00:00
func ( db sqlitePersistence ) DeleteMessage ( id string ) error {
2020-01-10 18:59:01 +00:00
_ , err := db . db . Exec ( ` DELETE FROM user_messages WHERE id = ? ` , id )
return err
}
2021-03-25 15:15:22 +00:00
func ( db sqlitePersistence ) DeleteMessages ( ids [ ] string ) error {
idsArgs := make ( [ ] interface { } , 0 , len ( ids ) )
for _ , id := range ids {
idsArgs = append ( idsArgs , id )
}
inVector := strings . Repeat ( "?, " , len ( ids ) - 1 ) + "?"
_ , err := db . db . Exec ( "DELETE FROM user_messages WHERE id IN (" + inVector + ")" , idsArgs ... ) // nolint: gosec
return err
}
2020-01-10 18:59:01 +00:00
func ( db sqlitePersistence ) HideMessage ( id string ) error {
2020-12-07 15:13:39 +00:00
_ , err := db . db . Exec ( ` UPDATE user_messages SET hide = 1, seen = 1 WHERE id = ? ` , id )
2019-08-06 21:50:13 +00:00
return err
}
2021-08-20 14:26:13 +00:00
// SetHideOnMessage set the hide flag, but not the seen flag, as it's needed by the client to understand whether the count should be updated
func ( db sqlitePersistence ) SetHideOnMessage ( id string ) error {
_ , err := db . db . Exec ( ` UPDATE user_messages SET hide = 1 WHERE id = ? ` , id )
return err
}
2022-09-29 11:50:23 +00:00
func ( db sqlitePersistence ) DeleteMessagesByCommunityID ( id string ) error {
return db . deleteMessagesByCommunityID ( id )
}
func ( db sqlitePersistence ) deleteMessagesByCommunityID ( id string ) ( err error ) {
tx , err := db . db . BeginTx ( context . Background ( ) , & sql . TxOptions { } )
if err != nil {
return err
}
defer func ( ) {
if err == nil {
err = tx . Commit ( )
return
}
// don't shadow original error
_ = tx . Rollback ( )
} ( )
_ , err = tx . Exec ( ` DELETE FROM user_messages WHERE community_id = ? ` , id )
if err != nil {
return
}
_ , err = tx . Exec ( ` DELETE FROM pin_messages WHERE community_id = ? ` , id )
return
}
2019-08-20 11:20:25 +00:00
func ( db sqlitePersistence ) DeleteMessagesByChatID ( id string ) error {
2020-12-22 10:49:25 +00:00
return db . deleteMessagesByChatID ( id , nil )
}
func ( db sqlitePersistence ) deleteMessagesByChatID ( id string , tx * sql . Tx ) ( err error ) {
if tx == nil {
tx , err = db . db . BeginTx ( context . Background ( ) , & sql . TxOptions { } )
if err != nil {
return err
}
defer func ( ) {
if err == nil {
err = tx . Commit ( )
return
}
// don't shadow original error
_ = tx . Rollback ( )
} ( )
}
_ , err = tx . Exec ( ` DELETE FROM user_messages WHERE local_chat_id = ? ` , id )
2021-05-14 21:22:50 +00:00
if err != nil {
return
}
_ , err = tx . Exec ( ` DELETE FROM pin_messages WHERE local_chat_id = ? ` , id )
2020-12-22 10:49:25 +00:00
return
2019-08-20 11:20:25 +00:00
}
2022-02-10 10:00:59 +00:00
func ( db sqlitePersistence ) deleteMessagesByChatIDAndClockValueLessThanOrEqual ( id string , clock uint64 , tx * sql . Tx ) ( unViewedMessages , unViewedMentions uint , err error ) {
if tx == nil {
tx , err = db . db . BeginTx ( context . Background ( ) , & sql . TxOptions { } )
if err != nil {
return 0 , 0 , err
}
defer func ( ) {
if err == nil {
err = tx . Commit ( )
return
}
// don't shadow original error
_ = tx . Rollback ( )
} ( )
}
_ , err = tx . Exec ( ` DELETE FROM user_messages WHERE local_chat_id = ? AND clock_value <= ? ` , id , clock )
if err != nil {
return
}
_ , err = tx . Exec ( ` DELETE FROM pin_messages WHERE local_chat_id = ? AND clock_value <= ? ` , id , clock )
if err != nil {
return
}
_ , err = tx . Exec (
` UPDATE chats
SET unviewed_message_count =
( SELECT COUNT ( 1 )
FROM user_messages
WHERE local_chat_id = ? AND seen = 0 ) ,
unviewed_mentions_count =
( SELECT COUNT ( 1 )
FROM user_messages
2023-01-10 17:59:32 +00:00
WHERE local_chat_id = ? AND seen = 0 AND ( mentioned OR replied ) ) ,
2022-02-10 10:00:59 +00:00
highlight = 0
WHERE id = ? ` , id , id , id )
if err != nil {
return 0 , 0 , err
}
2022-09-02 08:36:07 +00:00
err = tx . QueryRow ( ` SELECT unviewed_message_count , unviewed_mentions_count FROM chats
2022-02-10 10:00:59 +00:00
WHERE id = ? ` , id ) . Scan ( & unViewedMessages , & unViewedMentions )
return
}
2021-10-12 10:33:32 +00:00
func ( db sqlitePersistence ) MarkAllRead ( chatID string , clock uint64 ) ( int64 , int64 , error ) {
2020-02-26 12:31:48 +00:00
tx , err := db . db . BeginTx ( context . Background ( ) , & sql . TxOptions { } )
if err != nil {
2021-10-12 10:33:32 +00:00
return 0 , 0 , err
2020-02-26 12:31:48 +00:00
}
defer func ( ) {
if err == nil {
err = tx . Commit ( )
return
}
// don't shadow original error
_ = tx . Rollback ( )
} ( )
2023-01-10 17:59:32 +00:00
seenResult , err := tx . Exec ( ` UPDATE user_messages SET seen = 1 WHERE local_chat_id = ? AND seen = 0 AND clock_value <= ? AND not(mentioned) AND not(replied) ` , chatID , clock )
2020-02-26 12:31:48 +00:00
if err != nil {
2021-10-12 10:33:32 +00:00
return 0 , 0 , err
2020-02-26 12:31:48 +00:00
}
2021-10-12 10:33:32 +00:00
seen , err := seenResult . RowsAffected ( )
if err != nil {
return 0 , 0 , err
}
2023-01-10 17:59:32 +00:00
mentionedOrRepliedResult , err := tx . Exec ( ` UPDATE user_messages SET seen = 1 WHERE local_chat_id = ? AND seen = 0 AND clock_value <= ? AND (mentioned OR replied) ` , chatID , clock )
2021-10-12 10:33:32 +00:00
if err != nil {
return 0 , 0 , err
}
2023-01-10 17:59:32 +00:00
mentionedOrReplied , err := mentionedOrRepliedResult . RowsAffected ( )
2021-10-12 10:33:32 +00:00
if err != nil {
return 0 , 0 , err
}
_ , err = tx . Exec (
` UPDATE chats
2023-05-16 16:11:52 +00:00
SET unviewed_message_count = 0 ,
unviewed_mentions_count = 0 ,
2021-10-12 10:33:32 +00:00
highlight = 0
WHERE id = ? ` , chatID , chatID , chatID )
if err != nil {
return 0 , 0 , err
}
2023-01-10 17:59:32 +00:00
return ( seen + mentionedOrReplied ) , mentionedOrReplied , nil
2020-02-26 12:31:48 +00:00
}
2021-09-20 06:33:36 +00:00
func ( db sqlitePersistence ) MarkAllReadMultiple ( chatIDs [ ] string ) error {
tx , err := db . db . BeginTx ( context . Background ( ) , & sql . TxOptions { } )
if err != nil {
return err
}
defer func ( ) {
if err == nil {
err = tx . Commit ( )
return
}
// don't shadow original error
_ = tx . Rollback ( )
} ( )
idsArgs := make ( [ ] interface { } , 0 , len ( chatIDs ) )
for _ , id := range chatIDs {
idsArgs = append ( idsArgs , id )
}
inVector := strings . Repeat ( "?, " , len ( chatIDs ) - 1 ) + "?"
q := "UPDATE user_messages SET seen = 1 WHERE local_chat_id IN (%s) AND seen != 1"
q = fmt . Sprintf ( q , inVector )
_ , err = tx . Exec ( q , idsArgs ... )
if err != nil {
return err
}
2021-10-21 17:04:56 +00:00
q = "UPDATE chats SET unviewed_mentions_count = 0, unviewed_message_count = 0, highlight = 0 WHERE id IN (%s)"
2021-09-20 06:33:36 +00:00
q = fmt . Sprintf ( q , inVector )
_ , err = tx . Exec ( q , idsArgs ... )
return err
}
2021-08-31 08:49:39 +00:00
func ( db sqlitePersistence ) MarkMessagesSeen ( chatID string , ids [ ] string ) ( uint64 , uint64 , error ) {
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
tx , err := db . db . BeginTx ( context . Background ( ) , & sql . TxOptions { } )
if err != nil {
2021-08-31 08:49:39 +00:00
return 0 , 0 , err
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
}
defer func ( ) {
if err == nil {
err = tx . Commit ( )
return
}
// don't shadow original error
_ = tx . Rollback ( )
} ( )
2019-08-06 21:50:13 +00:00
idsArgs := make ( [ ] interface { } , 0 , len ( ids ) )
for _ , id := range ids {
idsArgs = append ( idsArgs , id )
}
inVector := strings . Repeat ( "?, " , len ( ids ) - 1 ) + "?"
2023-01-10 17:59:32 +00:00
q := "UPDATE user_messages SET seen = 1 WHERE NOT(seen) AND (mentioned OR replied) AND id IN (" + inVector + ")" // nolint: gosec
2020-02-10 11:22:37 +00:00
_ , err = tx . Exec ( q , idsArgs ... )
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
if err != nil {
2021-08-31 08:49:39 +00:00
return 0 , 0 , err
2020-04-06 12:08:53 +00:00
}
2021-08-31 08:49:39 +00:00
var countWithMentions uint64
2020-04-06 12:08:53 +00:00
row := tx . QueryRow ( "SELECT changes();" )
2021-08-31 08:49:39 +00:00
if err := row . Scan ( & countWithMentions ) ; err != nil {
return 0 , 0 , err
}
2023-01-10 17:59:32 +00:00
q = "UPDATE user_messages SET seen = 1 WHERE NOT(seen) AND NOT(mentioned) AND NOT(replied) AND id IN (" + inVector + ")" // nolint: gosec
2021-08-31 08:49:39 +00:00
_ , err = tx . Exec ( q , idsArgs ... )
if err != nil {
return 0 , 0 , err
}
var countNoMentions uint64
row = tx . QueryRow ( "SELECT changes();" )
if err := row . Scan ( & countNoMentions ) ; err != nil {
return 0 , 0 , err
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
}
// Update denormalized count
_ , err = tx . Exec (
` UPDATE chats
SET unviewed_message_count =
( SELECT COUNT ( 1 )
2020-01-10 18:59:01 +00:00
FROM user_messages
2021-05-26 06:38:25 +00:00
WHERE local_chat_id = ? AND seen = 0 ) ,
unviewed_mentions_count =
( SELECT COUNT ( 1 )
FROM user_messages
2023-01-10 17:59:32 +00:00
WHERE local_chat_id = ? AND seen = 0 AND ( mentioned OR replied ) ) ,
2021-10-21 17:04:56 +00:00
highlight = 0
2021-05-26 06:38:25 +00:00
WHERE id = ? ` , chatID , chatID , chatID )
2021-08-31 08:49:39 +00:00
return countWithMentions + countNoMentions , countWithMentions , err
2019-08-06 21:50:13 +00:00
}
func ( db sqlitePersistence ) UpdateMessageOutgoingStatus ( id string , newOutgoingStatus string ) error {
_ , err := db . db . Exec ( `
2020-01-10 18:59:01 +00:00
UPDATE user_messages
2019-08-06 21:50:13 +00:00
SET outgoing_status = ?
2022-01-31 10:33:56 +00:00
WHERE id = ? AND outgoing_status != ?
` , newOutgoingStatus , id , common . OutgoingStatusDelivered )
2019-08-06 21:50:13 +00:00
return err
}
2019-08-20 11:20:25 +00:00
// BlockContact updates a contact, deletes all the messages and 1-to-1 chat, updates the unread messages count and returns a map with the new count
2022-04-08 20:14:37 +00:00
func ( db sqlitePersistence ) BlockContact ( contact * Contact , isDesktopFunc bool ) ( [ ] * Chat , error ) {
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
var chats [ ] * Chat
2019-11-15 08:52:28 +00:00
tx , err := db . db . BeginTx ( context . Background ( ) , & sql . TxOptions { } )
2019-08-20 11:20:25 +00:00
if err != nil {
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
return nil , err
2019-08-20 11:20:25 +00:00
}
defer func ( ) {
if err == nil {
err = tx . Commit ( )
return
}
// don't shadow original error
_ = tx . Rollback ( )
} ( )
2022-04-08 20:14:37 +00:00
if ! isDesktopFunc {
// Delete messages
_ , err = tx . Exec (
` DELETE
FROM user_messages
WHERE source = ? ` ,
contact . ID ,
)
if err != nil {
return nil , err
}
2019-08-20 11:20:25 +00:00
}
// Update contact
err = db . SaveContact ( contact , tx )
if err != nil {
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
return nil , err
2019-08-20 11:20:25 +00:00
}
2022-04-08 20:14:37 +00:00
if ! isDesktopFunc {
// Delete one-to-one chat
_ , err = tx . Exec ( "DELETE FROM chats WHERE id = ?" , contact . ID )
if err != nil {
return nil , err
}
2019-08-20 11:20:25 +00:00
}
// Recalculate denormalized fields
_ , err = tx . Exec ( `
2019-11-15 08:52:28 +00:00
UPDATE chats
SET
2021-05-26 06:38:25 +00:00
unviewed_message_count = ( SELECT COUNT ( 1 ) FROM user_messages WHERE seen = 0 AND local_chat_id = chats . id ) ,
2023-01-10 17:59:32 +00:00
unviewed_mentions_count = ( SELECT COUNT ( 1 ) FROM user_messages WHERE seen = 0 AND local_chat_id = chats . id AND ( mentioned OR replied ) ) ` )
2019-08-20 11:20:25 +00:00
if err != nil {
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
return nil , err
2019-08-20 11:20:25 +00:00
}
// return the updated chats
2019-11-15 08:52:28 +00:00
chats , err = db . chats ( tx )
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
if err != nil {
return nil , err
}
for _ , c := range chats {
var lastMessageID string
2020-01-10 18:59:01 +00:00
row := tx . QueryRow ( ` SELECT id FROM user_messages WHERE local_chat_id = ? ORDER BY clock_value DESC LIMIT 1 ` , c . ID )
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
switch err := row . Scan ( & lastMessageID ) ; err {
case nil :
message , err := db . messageByID ( tx , lastMessageID )
if err != nil {
return nil , err
}
if message != nil {
encodedMessage , err := json . Marshal ( message )
if err != nil {
return nil , err
}
_ , err = tx . Exec ( ` UPDATE chats SET last_message = ? WHERE id = ? ` , encodedMessage , c . ID )
if err != nil {
return nil , err
}
2020-07-30 20:54:33 +00:00
c . LastMessage = message
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
}
case sql . ErrNoRows :
// Reset LastMessage
_ , err = tx . Exec ( ` UPDATE chats SET last_message = NULL WHERE id = ? ` , c . ID )
if err != nil {
return nil , err
}
c . LastMessage = nil
default :
return nil , err
}
}
return chats , err
2019-08-20 11:20:25 +00:00
}
2020-07-21 23:42:55 +00:00
2022-07-21 19:34:03 +00:00
func ( db sqlitePersistence ) HasDiscordMessageAuthor ( id string ) ( exists bool , err error ) {
err = db . db . QueryRow ( ` SELECT EXISTS(SELECT 1 FROM discord_message_authors WHERE id = ?) ` , id ) . Scan ( & exists )
return exists , err
}
2022-09-15 09:05:30 +00:00
func ( db sqlitePersistence ) HasDiscordMessageAuthorImagePayload ( id string ) ( hasPayload bool , err error ) {
err = db . db . QueryRow ( ` SELECT EXISTS(SELECT 1 FROM discord_message_authors WHERE id = ? AND avatar_image_payload NOT NULL) ` , id ) . Scan ( & hasPayload )
return hasPayload , err
}
2022-07-21 19:34:03 +00:00
func ( db sqlitePersistence ) SaveDiscordMessageAuthor ( author * protobuf . DiscordMessageAuthor ) ( err error ) {
2022-09-29 11:50:23 +00:00
stmt , err := db . db . Prepare ( basicInsertDiscordMessageAuthorQuery )
2022-07-21 19:34:03 +00:00
if err != nil {
return
}
_ , err = stmt . Exec (
author . GetId ( ) ,
author . GetName ( ) ,
author . GetDiscriminator ( ) ,
author . GetNickname ( ) ,
author . GetAvatarUrl ( ) ,
2022-09-15 09:05:30 +00:00
author . GetAvatarImagePayload ( ) ,
2022-07-21 19:34:03 +00:00
)
return
}
2022-09-29 11:50:23 +00:00
func ( db sqlitePersistence ) SaveDiscordMessageAuthors ( authors [ ] * protobuf . DiscordMessageAuthor ) ( err error ) {
tx , err := db . db . BeginTx ( context . Background ( ) , & sql . TxOptions { } )
if err != nil {
return
}
defer func ( ) {
if err == nil {
err = tx . Commit ( )
return
}
// don't shadow original error
_ = tx . Rollback ( )
} ( )
stmt , err := tx . Prepare ( basicInsertDiscordMessageAuthorQuery )
if err != nil {
return
}
defer stmt . Close ( )
for _ , author := range authors {
_ , err = stmt . Exec (
author . GetId ( ) ,
author . GetName ( ) ,
author . GetDiscriminator ( ) ,
author . GetNickname ( ) ,
author . GetAvatarUrl ( ) ,
author . GetAvatarImagePayload ( ) ,
)
if err != nil {
return
}
}
return
}
2022-09-15 09:05:30 +00:00
func ( db sqlitePersistence ) UpdateDiscordMessageAuthorImage ( authorID string , payload [ ] byte ) ( err error ) {
query := "UPDATE discord_message_authors SET avatar_image_payload = ? WHERE id = ?"
stmt , err := db . db . Prepare ( query )
if err != nil {
return
}
defer stmt . Close ( )
_ , err = stmt . Exec ( payload , authorID )
return
}
func ( db sqlitePersistence ) GetDiscordMessageAuthorImagePayloadByID ( id string ) ( [ ] byte , error ) {
payload := make ( [ ] byte , 0 )
row := db . db . QueryRow ( "SELECT avatar_image_payload FROM discord_message_authors WHERE id = ?" , id )
err := row . Scan ( & payload )
return payload , err
}
func ( db sqlitePersistence ) GetDiscordMessageAuthorByID ( id string ) ( * protobuf . DiscordMessageAuthor , error ) {
author := & protobuf . DiscordMessageAuthor { }
row := db . db . QueryRow ( "SELECT id, name, discriminator, nickname, avatar_url FROM discord_message_authors WHERE id = ?" , id )
err := row . Scan (
& author . Id ,
& author . Name ,
& author . Discriminator ,
& author . Nickname ,
& author . AvatarUrl )
return author , err
}
2022-08-04 16:16:56 +00:00
func ( db sqlitePersistence ) SaveDiscordMessage ( message * protobuf . DiscordMessage ) ( err error ) {
2022-10-05 10:39:05 +00:00
query := "INSERT OR REPLACE INTO discord_messages(id,type,timestamp,timestamp_edited,content,author_id, reference_message_id, reference_channel_id, reference_guild_id) VALUES (?,?,?,?,?,?,?,?,?)"
2022-08-04 16:16:56 +00:00
stmt , err := db . db . Prepare ( query )
if err != nil {
return
}
defer stmt . Close ( )
_ , err = stmt . Exec (
message . GetId ( ) ,
message . GetType ( ) ,
message . GetTimestamp ( ) ,
message . GetTimestampEdited ( ) ,
message . GetContent ( ) ,
message . Author . GetId ( ) ,
message . Reference . GetMessageId ( ) ,
message . Reference . GetChannelId ( ) ,
message . Reference . GetGuildId ( ) ,
)
return
}
func ( db sqlitePersistence ) SaveDiscordMessages ( messages [ ] * protobuf . DiscordMessage ) ( err error ) {
tx , err := db . db . BeginTx ( context . Background ( ) , & sql . TxOptions { } )
if err != nil {
return
}
defer func ( ) {
if err == nil {
err = tx . Commit ( )
return
}
// don't shadow original error
_ = tx . Rollback ( )
} ( )
2022-08-19 12:30:11 +00:00
query := "INSERT OR REPLACE INTO discord_messages(id, author_id, type, timestamp, timestamp_edited, content, reference_message_id, reference_channel_id, reference_guild_id) VALUES(?, ?, ?, ?, ?, ?, ?, ?, ?)"
2022-08-04 16:16:56 +00:00
stmt , err := tx . Prepare ( query )
if err != nil {
return
}
defer stmt . Close ( )
for _ , msg := range messages {
_ , err = stmt . Exec (
msg . GetId ( ) ,
2022-08-19 12:30:11 +00:00
msg . Author . GetId ( ) ,
2022-08-04 16:16:56 +00:00
msg . GetType ( ) ,
msg . GetTimestamp ( ) ,
msg . GetTimestampEdited ( ) ,
msg . GetContent ( ) ,
msg . Reference . GetMessageId ( ) ,
msg . Reference . GetChannelId ( ) ,
msg . Reference . GetGuildId ( ) ,
)
if err != nil {
return
}
}
return
}
2022-10-05 10:39:55 +00:00
func ( db sqlitePersistence ) HasDiscordMessageAttachmentPayload ( id string , messageID string ) ( hasPayload bool , err error ) {
err = db . db . QueryRow ( ` SELECT EXISTS(SELECT 1 FROM discord_message_attachments WHERE id = ? AND discord_message_id = ? AND payload NOT NULL) ` , id , messageID ) . Scan ( & hasPayload )
2022-09-20 09:13:44 +00:00
return hasPayload , err
}
func ( db sqlitePersistence ) SaveDiscordMessageAttachments ( attachments [ ] * protobuf . DiscordMessageAttachment ) ( err error ) {
tx , err := db . db . BeginTx ( context . Background ( ) , & sql . TxOptions { } )
if err != nil {
return
}
defer func ( ) {
if err == nil {
err = tx . Commit ( )
return
}
// don't shadow original error
_ = tx . Rollback ( )
} ( )
2022-09-29 11:50:23 +00:00
stmt , err := tx . Prepare ( "INSERT OR REPLACE INTO discord_message_attachments(id,discord_message_id,url,file_name,file_size_bytes,payload, content_type) VALUES (?,?,?,?,?,?,?)" )
2022-09-20 09:13:44 +00:00
if err != nil {
return
}
defer stmt . Close ( )
if err != nil {
return
}
for _ , attachment := range attachments {
_ , err = stmt . Exec (
attachment . GetId ( ) ,
attachment . GetMessageId ( ) ,
attachment . GetUrl ( ) ,
attachment . GetFileName ( ) ,
attachment . GetFileSizeBytes ( ) ,
attachment . GetPayload ( ) ,
attachment . GetContentType ( ) ,
)
if err != nil {
return
}
}
return
}
2020-07-21 23:42:55 +00:00
func ( db sqlitePersistence ) SaveEmojiReaction ( emojiReaction * EmojiReaction ) ( err error ) {
2020-07-28 07:53:32 +00:00
query := "INSERT INTO emoji_reactions(id,clock_value,source,emoji_id,message_id,chat_id,local_chat_id,retracted) VALUES (?,?,?,?,?,?,?,?)"
2020-07-27 12:27:48 +00:00
stmt , err := db . db . Prepare ( query )
2020-07-21 23:42:55 +00:00
if err != nil {
return
}
2020-07-27 12:27:48 +00:00
_ , err = stmt . Exec (
emojiReaction . ID ( ) ,
2020-07-21 23:42:55 +00:00
emojiReaction . Clock ,
emojiReaction . From ,
2020-07-25 16:13:08 +00:00
emojiReaction . Type ,
emojiReaction . MessageId ,
emojiReaction . ChatId ,
2020-07-28 07:53:32 +00:00
emojiReaction . LocalChatID ,
2020-07-21 23:42:55 +00:00
emojiReaction . Retracted ,
2020-07-27 12:27:48 +00:00
)
2020-07-21 23:42:55 +00:00
return
}
2020-07-22 00:21:05 +00:00
func ( db sqlitePersistence ) EmojiReactionByID ( id string ) ( * EmojiReaction , error ) {
2020-07-28 07:53:32 +00:00
row := db . db . QueryRow (
2020-07-27 12:27:48 +00:00
` SELECT
clock_value ,
source ,
emoji_id ,
message_id ,
chat_id ,
2020-07-28 07:53:32 +00:00
local_chat_id ,
2020-07-27 12:27:48 +00:00
retracted
2020-07-22 00:21:05 +00:00
FROM
emoji_reactions
WHERE
emoji_reactions . id = ?
2020-07-27 12:27:48 +00:00
` , id )
2020-07-22 00:21:05 +00:00
2023-08-18 11:39:59 +00:00
emojiReaction := NewEmojiReaction ( )
2020-07-28 07:53:32 +00:00
err := row . Scan ( & emojiReaction . Clock ,
2020-07-22 00:21:05 +00:00
& emojiReaction . From ,
2020-07-25 16:13:08 +00:00
& emojiReaction . Type ,
& emojiReaction . MessageId ,
& emojiReaction . ChatId ,
2020-07-28 07:53:32 +00:00
& emojiReaction . LocalChatID ,
2020-07-22 00:21:05 +00:00
& emojiReaction . Retracted ,
2020-07-27 12:27:48 +00:00
)
switch err {
case sql . ErrNoRows :
2020-10-08 10:46:03 +00:00
return nil , common . ErrRecordNotFound
2020-07-27 12:27:48 +00:00
case nil :
return emojiReaction , nil
default :
return nil , err
}
}
2020-08-07 13:49:37 +00:00
func ( db sqlitePersistence ) SaveInvitation ( invitation * GroupChatInvitation ) ( err error ) {
query := "INSERT INTO group_chat_invitations(id,source,chat_id,message,state,clock) VALUES (?,?,?,?,?,?)"
stmt , err := db . db . Prepare ( query )
if err != nil {
return
}
_ , err = stmt . Exec (
invitation . ID ( ) ,
invitation . From ,
invitation . ChatId ,
invitation . IntroductionMessage ,
invitation . State ,
invitation . Clock ,
)
return
}
func ( db sqlitePersistence ) GetGroupChatInvitations ( ) ( rst [ ] * GroupChatInvitation , err error ) {
tx , err := db . db . Begin ( )
if err != nil {
return
}
defer func ( ) {
if err == nil {
err = tx . Commit ( )
return
}
_ = tx . Rollback ( )
} ( )
bRows , err := tx . Query ( ` SELECT
source ,
chat_id ,
message ,
state ,
clock
FROM
group_chat_invitations ` )
if err != nil {
return
}
defer bRows . Close ( )
for bRows . Next ( ) {
invitation := GroupChatInvitation { }
err = bRows . Scan (
& invitation . From ,
& invitation . ChatId ,
& invitation . IntroductionMessage ,
& invitation . State ,
& invitation . Clock )
if err != nil {
return nil , err
}
rst = append ( rst , & invitation )
}
return rst , nil
}
func ( db sqlitePersistence ) InvitationByID ( id string ) ( * GroupChatInvitation , error ) {
row := db . db . QueryRow (
` SELECT
source ,
chat_id ,
message ,
state ,
clock
FROM
group_chat_invitations
WHERE
group_chat_invitations . id = ?
` , id )
2023-08-18 11:39:59 +00:00
chatInvitations := NewGroupChatInvitation ( )
2020-08-07 13:49:37 +00:00
err := row . Scan ( & chatInvitations . From ,
& chatInvitations . ChatId ,
& chatInvitations . IntroductionMessage ,
& chatInvitations . State ,
& chatInvitations . Clock ,
)
switch err {
case sql . ErrNoRows :
2020-10-08 10:46:03 +00:00
return nil , common . ErrRecordNotFound
2020-08-07 13:49:37 +00:00
case nil :
return chatInvitations , nil
default :
return nil , err
}
}
2020-12-22 10:49:25 +00:00
// ClearHistory deletes all the messages for a chat and updates it's values
func ( db sqlitePersistence ) ClearHistory ( chat * Chat , currentClockValue uint64 ) ( err error ) {
var tx * sql . Tx
tx , err = db . db . BeginTx ( context . Background ( ) , & sql . TxOptions { } )
if err != nil {
return
}
defer func ( ) {
if err == nil {
err = tx . Commit ( )
return
}
// don't shadow original error
_ = tx . Rollback ( )
} ( )
2021-05-14 10:55:42 +00:00
err = db . clearHistory ( chat , currentClockValue , tx , false )
2020-12-22 10:49:25 +00:00
return
}
2022-02-10 10:00:59 +00:00
func ( db sqlitePersistence ) ClearHistoryFromSyncMessage ( chat * Chat , currentClockValue uint64 ) ( err error ) {
var tx * sql . Tx
tx , err = db . db . BeginTx ( context . Background ( ) , & sql . TxOptions { } )
if err != nil {
return
}
defer func ( ) {
if err == nil {
err = tx . Commit ( )
return
}
// don't shadow original error
_ = tx . Rollback ( )
} ( )
err = db . clearHistoryFromSyncMessage ( chat , currentClockValue , tx )
return
}
2020-12-22 10:49:25 +00:00
// Deactivate chat sets a chat as inactive and clear its history
2022-12-07 19:34:48 +00:00
func ( db sqlitePersistence ) DeactivateChat ( chat * Chat , currentClockValue uint64 , doClearHistory bool ) ( err error ) {
2020-12-22 10:49:25 +00:00
var tx * sql . Tx
tx , err = db . db . BeginTx ( context . Background ( ) , & sql . TxOptions { } )
if err != nil {
return
}
defer func ( ) {
if err == nil {
err = tx . Commit ( )
return
}
// don't shadow original error
_ = tx . Rollback ( )
} ( )
2022-12-07 19:34:48 +00:00
err = db . deactivateChat ( chat , currentClockValue , tx , doClearHistory )
2020-12-22 10:49:25 +00:00
return
}
2022-12-07 19:34:48 +00:00
func ( db sqlitePersistence ) deactivateChat ( chat * Chat , currentClockValue uint64 , tx * sql . Tx , doClearHistory bool ) error {
2020-12-22 10:49:25 +00:00
chat . Active = false
err := db . saveChat ( tx , * chat )
if err != nil {
return err
}
2022-12-07 19:34:48 +00:00
if ! doClearHistory {
return nil
}
2021-05-14 10:55:42 +00:00
return db . clearHistory ( chat , currentClockValue , tx , true )
2020-12-22 10:49:25 +00:00
}
2023-08-18 11:39:59 +00:00
func ( db sqlitePersistence ) SaveDelete ( deleteMessage * DeleteMessage ) error {
2021-07-26 21:06:32 +00:00
_ , err := db . db . Exec ( ` INSERT INTO user_messages_deletes (clock, chat_id, message_id, source, id) VALUES(?,?,?,?,?) ` , deleteMessage . Clock , deleteMessage . ChatId , deleteMessage . MessageId , deleteMessage . From , deleteMessage . ID )
return err
}
func ( db sqlitePersistence ) GetDeletes ( messageID string , from string ) ( [ ] * DeleteMessage , error ) {
rows , err := db . db . Query ( ` SELECT clock, chat_id, message_id, source, id FROM user_messages_deletes WHERE message_id = ? AND source = ? ORDER BY CLOCK DESC ` , messageID , from )
if err != nil {
return nil , err
}
2023-05-12 08:31:34 +00:00
defer rows . Close ( )
2021-07-26 21:06:32 +00:00
var messages [ ] * DeleteMessage
for rows . Next ( ) {
2023-08-18 11:39:59 +00:00
d := NewDeleteMessage ( )
2021-07-26 21:06:32 +00:00
err := rows . Scan ( & d . Clock , & d . ChatId , & d . MessageId , & d . From , & d . ID )
if err != nil {
return nil , err
}
messages = append ( messages , d )
}
return messages , nil
}
2023-08-18 11:39:59 +00:00
func ( db sqlitePersistence ) SaveOrUpdateDeleteForMeMessage ( deleteForMeMessage * protobuf . SyncDeleteForMeMessage ) error {
2023-05-12 08:31:34 +00:00
_ , err := db . db . Exec ( ` INSERT OR REPLACE INTO user_messages_deleted_for_mes ( clock , message_id )
SELECT ? , ? WHERE NOT EXISTS ( SELECT 1 FROM user_messages_deleted_for_mes WHERE message_id = ? AND clock >= ? ) ` ,
deleteForMeMessage . Clock , deleteForMeMessage . MessageId , deleteForMeMessage . MessageId , deleteForMeMessage . Clock )
2022-09-28 11:42:17 +00:00
return err
}
2023-08-18 11:39:59 +00:00
func ( db sqlitePersistence ) GetDeleteForMeMessagesByMessageID ( messageID string ) ( [ ] * protobuf . SyncDeleteForMeMessage , error ) {
2023-05-12 08:31:34 +00:00
rows , err := db . db . Query ( ` SELECT clock, message_id FROM user_messages_deleted_for_mes WHERE message_id = ? ` , messageID )
2022-09-28 11:42:17 +00:00
if err != nil {
return nil , err
}
2023-05-12 08:31:34 +00:00
defer rows . Close ( )
2022-09-28 11:42:17 +00:00
2023-08-18 11:39:59 +00:00
var messages [ ] * protobuf . SyncDeleteForMeMessage
2022-09-28 11:42:17 +00:00
for rows . Next ( ) {
2023-08-18 11:39:59 +00:00
d := & protobuf . SyncDeleteForMeMessage { }
2023-05-12 08:31:34 +00:00
err := rows . Scan ( & d . Clock , & d . MessageId )
2022-09-28 11:42:17 +00:00
if err != nil {
return nil , err
}
messages = append ( messages , d )
2023-05-12 08:31:34 +00:00
}
return messages , nil
}
2023-08-18 11:39:59 +00:00
func ( db sqlitePersistence ) GetDeleteForMeMessages ( ) ( [ ] * protobuf . SyncDeleteForMeMessage , error ) {
2023-05-12 08:31:34 +00:00
rows , err := db . db . Query ( ` SELECT clock, message_id FROM user_messages_deleted_for_mes ` )
if err != nil {
return nil , err
}
defer rows . Close ( )
2022-09-28 11:42:17 +00:00
2023-08-18 11:39:59 +00:00
var messages [ ] * protobuf . SyncDeleteForMeMessage
2023-05-12 08:31:34 +00:00
for rows . Next ( ) {
2023-08-18 11:39:59 +00:00
d := & protobuf . SyncDeleteForMeMessage { }
2023-05-12 08:31:34 +00:00
err := rows . Scan ( & d . Clock , & d . MessageId )
if err != nil {
return nil , err
}
messages = append ( messages , d )
2022-09-28 11:42:17 +00:00
}
return messages , nil
}
2023-08-18 11:39:59 +00:00
func ( db sqlitePersistence ) SaveEdit ( editMessage * EditMessage ) error {
if editMessage == nil {
return nil
}
2021-06-08 06:07:45 +00:00
_ , err := db . db . Exec ( ` INSERT INTO user_messages_edits (clock, chat_id, message_id, text, source, id) VALUES(?,?,?,?,?,?) ` , editMessage . Clock , editMessage . ChatId , editMessage . MessageId , editMessage . Text , editMessage . From , editMessage . ID )
2021-06-07 11:45:06 +00:00
return err
}
2021-06-08 06:07:45 +00:00
func ( db sqlitePersistence ) GetEdits ( messageID string , from string ) ( [ ] * EditMessage , error ) {
rows , err := db . db . Query ( ` SELECT clock, chat_id, message_id, source, text, id FROM user_messages_edits WHERE message_id = ? AND source = ? ORDER BY CLOCK DESC ` , messageID , from )
if err != nil {
return nil , err
}
2023-05-12 08:31:34 +00:00
defer rows . Close ( )
2021-06-08 06:07:45 +00:00
var messages [ ] * EditMessage
for rows . Next ( ) {
2023-08-18 11:39:59 +00:00
e := NewEditMessage ( )
2021-06-08 06:07:45 +00:00
err := rows . Scan ( & e . Clock , & e . ChatId , & e . MessageId , & e . From , & e . Text , & e . ID )
if err != nil {
return nil , err
}
messages = append ( messages , e )
}
return messages , nil
}
2021-05-14 10:55:42 +00:00
func ( db sqlitePersistence ) clearHistory ( chat * Chat , currentClockValue uint64 , tx * sql . Tx , deactivate bool ) error {
2020-12-22 10:49:25 +00:00
// Set deleted at clock value if it's not a public chat so that
2021-05-14 10:55:42 +00:00
// old messages will be discarded, or if it's a straight clear history
if ! deactivate || ( ! chat . Public ( ) && ! chat . ProfileUpdates ( ) && ! chat . Timeline ( ) ) {
2020-12-22 10:49:25 +00:00
if chat . LastMessage != nil && chat . LastMessage . Clock != 0 {
chat . DeletedAtClockValue = chat . LastMessage . Clock
}
chat . DeletedAtClockValue = currentClockValue
}
2021-03-25 15:15:22 +00:00
// Reset synced-to/from
syncedTo := uint32 ( currentClockValue / 1000 )
chat . SyncedTo = syncedTo
2022-02-08 11:12:11 +00:00
chat . SyncedFrom = 0
2021-03-25 15:15:22 +00:00
2020-12-22 10:49:25 +00:00
chat . LastMessage = nil
chat . UnviewedMessagesCount = 0
2021-05-26 06:38:25 +00:00
chat . UnviewedMentionsCount = 0
2021-10-21 17:04:56 +00:00
chat . Highlight = true
2020-12-22 10:49:25 +00:00
err := db . deleteMessagesByChatID ( chat . ID , tx )
if err != nil {
return err
}
err = db . saveChat ( tx , * chat )
return err
}
2022-02-10 10:00:59 +00:00
func ( db sqlitePersistence ) clearHistoryFromSyncMessage ( chat * Chat , clearedAt uint64 , tx * sql . Tx ) error {
chat . DeletedAtClockValue = clearedAt
// Reset synced-to/from
syncedTo := uint32 ( clearedAt / 1000 )
chat . SyncedTo = syncedTo
chat . SyncedFrom = 0
unViewedMessagesCount , unViewedMentionsCount , err := db . deleteMessagesByChatIDAndClockValueLessThanOrEqual ( chat . ID , clearedAt , tx )
if err != nil {
return err
}
chat . UnviewedMessagesCount = unViewedMessagesCount
chat . UnviewedMentionsCount = unViewedMentionsCount
if chat . LastMessage != nil && chat . LastMessage . Clock <= clearedAt {
chat . LastMessage = nil
}
err = db . saveChat ( tx , * chat )
return err
}
2022-01-18 16:31:34 +00:00
func ( db sqlitePersistence ) SetContactRequestState ( id string , state common . ContactRequestState ) error {
_ , err := db . db . Exec ( ` UPDATE user_messages SET contact_request_state = ? WHERE id = ? ` , state , id )
return err
}
2022-09-20 09:13:44 +00:00
func getUpdatedChatMessagePayload ( originalMessage * protobuf . DiscordMessage , attachmentMessage * protobuf . DiscordMessage ) * protobuf . ChatMessage_DiscordMessage {
originalMessage . Attachments = append ( originalMessage . Attachments , attachmentMessage . Attachments ... )
return & protobuf . ChatMessage_DiscordMessage {
DiscordMessage : originalMessage ,
}
}
func getMessageFromScanRows ( db sqlitePersistence , rows * sql . Rows ) ( * common . Message , error ) {
var msg * common . Message
for rows . Next ( ) {
// There's a possibility of multiple rows per message if the
// message has a discordMessage and the discordMessage has multiple
// attachments
//
// Hence, we make sure we're aggregating all attachments on a single
// common.Message
2023-08-18 11:39:59 +00:00
message := common . NewMessage ( )
err := db . tableUserMessagesScanAllFields ( rows , message )
2022-09-20 09:13:44 +00:00
if err != nil {
return nil , err
}
if msg == nil {
2023-08-18 11:39:59 +00:00
msg = message
2022-09-20 09:13:44 +00:00
} else if discordMessage := msg . GetDiscordMessage ( ) ; discordMessage != nil {
msg . Payload = getUpdatedChatMessagePayload ( discordMessage , message . GetDiscordMessage ( ) )
}
}
if msg == nil {
return nil , common . ErrRecordNotFound
}
return msg , nil
}
type HasClocks interface {
GetClock ( i int ) uint64
}
func SortByClock ( msgs HasClocks ) {
sort . Slice ( msgs , func ( i , j int ) bool {
return msgs . GetClock ( j ) < msgs . GetClock ( i )
} )
}
2022-10-07 17:38:28 +00:00
func getMessagesFromScanRows ( db sqlitePersistence , rows * sql . Rows , withCursor bool ) ( [ ] * common . Message , error ) {
2022-09-20 09:13:44 +00:00
messageIdx := make ( map [ string ] * common . Message , 0 )
2022-12-02 10:21:47 +00:00
var messages common . Messages
2022-09-20 09:13:44 +00:00
for rows . Next ( ) {
// There's a possibility of multiple rows per message if the
// message has a discordMessage and the discordMessage has multiple
// attachments
//
// Hence, we make sure we're aggregating all attachments on a single
// common.Message
2023-08-18 11:39:59 +00:00
message := common . NewMessage ( )
2022-10-07 17:38:28 +00:00
if withCursor {
var cursor string
2023-08-18 11:39:59 +00:00
if err := db . tableUserMessagesScanAllFields ( rows , message , & cursor ) ; err != nil {
2022-10-07 17:38:28 +00:00
return nil , err
}
} else {
2023-08-18 11:39:59 +00:00
if err := db . tableUserMessagesScanAllFields ( rows , message ) ; err != nil {
2022-10-07 17:38:28 +00:00
return nil , err
}
2022-09-20 09:13:44 +00:00
}
if msg , ok := messageIdx [ message . ID ] ; ! ok {
2023-08-18 11:39:59 +00:00
messageIdx [ message . ID ] = message
messages = append ( messages , message )
2022-09-20 09:13:44 +00:00
} else if discordMessage := msg . GetDiscordMessage ( ) ; discordMessage != nil {
msg . Payload = getUpdatedChatMessagePayload ( discordMessage , message . GetDiscordMessage ( ) )
}
}
SortByClock ( messages )
return messages , nil
}
func getMessagesAndCursorsFromScanRows ( db sqlitePersistence , rows * sql . Rows ) ( [ ] * common . Message , [ ] string , error ) {
var cursors [ ] string
2022-12-02 10:21:47 +00:00
var messages common . Messages
2022-09-20 09:13:44 +00:00
messageIdx := make ( map [ string ] * common . Message , 0 )
for rows . Next ( ) {
// There's a possibility of multiple rows per message if the
// message has a discordMessage and the discordMessage has multiple
// attachments
//
// Hence, we make sure we're aggregating all attachments on a single
// common.Message
2023-08-18 11:39:59 +00:00
var cursor string
message := common . NewMessage ( )
if err := db . tableUserMessagesScanAllFields ( rows , message , & cursor ) ; err != nil {
2022-09-20 09:13:44 +00:00
return nil , nil , err
}
if msg , ok := messageIdx [ message . ID ] ; ! ok {
2023-08-18 11:39:59 +00:00
messageIdx [ message . ID ] = message
2022-09-20 09:13:44 +00:00
cursors = append ( cursors , cursor )
2023-08-18 11:39:59 +00:00
messages = append ( messages , message )
2022-09-20 09:13:44 +00:00
} else if discordMessage := msg . GetDiscordMessage ( ) ; discordMessage != nil {
msg . Payload = getUpdatedChatMessagePayload ( discordMessage , message . GetDiscordMessage ( ) )
}
}
SortByClock ( messages )
return messages , cursors , nil
}
func getPinnedMessagesAndCursorsFromScanRows ( db sqlitePersistence , rows * sql . Rows ) ( [ ] * common . PinnedMessage , [ ] string , error ) {
var cursors [ ] string
2022-12-02 10:21:47 +00:00
var messages common . PinnedMessages
2022-09-20 09:13:44 +00:00
messageIdx := make ( map [ string ] * common . PinnedMessage , 0 )
for rows . Next ( ) {
var (
pinnedAt uint64
pinnedBy string
cursor string
)
2023-08-18 11:39:59 +00:00
message := common . NewMessage ( )
if err := db . tableUserMessagesScanAllFields ( rows , message , & pinnedAt , & pinnedBy , & cursor ) ; err != nil {
2022-09-20 09:13:44 +00:00
return nil , nil , err
}
if msg , ok := messageIdx [ message . ID ] ; ! ok {
pinnedMessage := & common . PinnedMessage {
2023-08-18 11:39:59 +00:00
Message : message ,
2022-09-20 09:13:44 +00:00
PinnedAt : pinnedAt ,
PinnedBy : pinnedBy ,
}
messageIdx [ message . ID ] = pinnedMessage
2022-12-02 10:21:47 +00:00
messages = append ( messages , pinnedMessage )
2022-09-20 09:13:44 +00:00
cursors = append ( cursors , cursor )
} else if discordMessage := msg . Message . GetDiscordMessage ( ) ; discordMessage != nil {
msg . Message . Payload = getUpdatedChatMessagePayload ( discordMessage , message . GetDiscordMessage ( ) )
}
}
SortByClock ( messages )
return messages , cursors , nil
}