2019-11-21 16:19:22 +00:00
|
|
|
|
package protocol
|
|
|
|
|
|
|
|
|
|
import (
|
|
|
|
|
"context"
|
|
|
|
|
"encoding/hex"
|
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-11-21 16:19:22 +00:00
|
|
|
|
"errors"
|
2023-10-03 16:29:27 +00:00
|
|
|
|
"fmt"
|
2023-12-11 08:17:01 +00:00
|
|
|
|
"io"
|
2020-01-10 18:59:01 +00:00
|
|
|
|
"math/big"
|
2023-04-14 17:17:56 +00:00
|
|
|
|
"os"
|
2020-01-10 18:59:01 +00:00
|
|
|
|
"strings"
|
2019-11-21 16:19:22 +00:00
|
|
|
|
"testing"
|
|
|
|
|
"time"
|
|
|
|
|
|
2023-06-07 05:58:01 +00:00
|
|
|
|
_ "github.com/mutecomm/go-sqlcipher/v4" // require go-sqlcipher that overrides default implementation
|
2020-01-02 09:10:19 +00:00
|
|
|
|
"github.com/stretchr/testify/suite"
|
|
|
|
|
"go.uber.org/zap"
|
|
|
|
|
|
2023-08-03 14:16:11 +00:00
|
|
|
|
"github.com/status-im/status-go/deprecation"
|
2020-01-10 18:59:01 +00:00
|
|
|
|
coretypes "github.com/status-im/status-go/eth-node/core/types"
|
2019-11-23 17:57:05 +00:00
|
|
|
|
"github.com/status-im/status-go/eth-node/crypto"
|
|
|
|
|
"github.com/status-im/status-go/eth-node/types"
|
|
|
|
|
enstypes "github.com/status-im/status-go/eth-node/types/ens"
|
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
|
|
|
|
"github.com/status-im/status-go/images"
|
2023-10-03 16:29:27 +00:00
|
|
|
|
"github.com/status-im/status-go/multiaccounts/settings"
|
2020-09-01 13:27:01 +00:00
|
|
|
|
"github.com/status-im/status-go/protocol/common"
|
2024-10-18 02:25:34 +00:00
|
|
|
|
"github.com/status-im/status-go/protocol/communities"
|
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
|
|
|
|
"github.com/status-im/status-go/protocol/protobuf"
|
2021-10-26 10:48:02 +00:00
|
|
|
|
"github.com/status-im/status-go/protocol/requests"
|
2019-11-21 16:19:22 +00:00
|
|
|
|
"github.com/status-im/status-go/protocol/tt"
|
2019-12-02 15:34:05 +00:00
|
|
|
|
v1protocol "github.com/status-im/status-go/protocol/v1"
|
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
|
|
|
|
"github.com/status-im/status-go/server"
|
2019-11-21 16:19:22 +00:00
|
|
|
|
)
|
|
|
|
|
|
2020-02-21 14:48:53 +00:00
|
|
|
|
const (
|
|
|
|
|
testPK = "0x0424a68f89ba5fcd5e0640c1e1f591d561fa4125ca4e2a43592bc4123eca10ce064e522c254bb83079ba404327f6eafc01ec90a1444331fe769d3f3a7f90b0dde1"
|
|
|
|
|
testPublicChatID = "super-chat"
|
|
|
|
|
testContract = "0x314159265dd8dbb310642f98f50c066173c1259b"
|
|
|
|
|
testValue = "2000"
|
|
|
|
|
testTransactionHash = "0x412a851ac2ae51cad34a56c8a9cfee55d577ac5e1ac71cf488a2f2093a373799"
|
2022-02-17 15:13:10 +00:00
|
|
|
|
newEnsName = "new-name"
|
2020-02-21 14:48:53 +00:00
|
|
|
|
)
|
|
|
|
|
|
2019-11-21 16:19:22 +00:00
|
|
|
|
func TestMessengerSuite(t *testing.T) {
|
|
|
|
|
suite.Run(t, new(MessengerSuite))
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
type MessengerSuite struct {
|
2023-03-08 17:47:09 +00:00
|
|
|
|
MessengerBaseTestSuite
|
2019-11-21 16:19:22 +00:00
|
|
|
|
}
|
|
|
|
|
|
2019-11-23 17:57:05 +00:00
|
|
|
|
type testNode struct {
|
2020-07-21 15:41:10 +00:00
|
|
|
|
shh types.Waku
|
2019-11-23 17:57:05 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (n *testNode) NewENSVerifier(_ *zap.Logger) enstypes.ENSVerifier {
|
|
|
|
|
panic("not implemented")
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-10 18:59:01 +00:00
|
|
|
|
func (n *testNode) AddPeer(_ string) error {
|
|
|
|
|
panic("not implemented")
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (n *testNode) RemovePeer(_ string) error {
|
|
|
|
|
panic("not implemented")
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-17 12:39:09 +00:00
|
|
|
|
func (n *testNode) GetWaku(_ interface{}) (types.Waku, error) {
|
2020-07-21 15:41:10 +00:00
|
|
|
|
return n.shh, nil
|
2020-01-17 12:39:09 +00:00
|
|
|
|
}
|
|
|
|
|
|
2021-06-16 20:19:45 +00:00
|
|
|
|
func (n *testNode) GetWakuV2(_ interface{}) (types.Waku, error) {
|
2024-06-25 09:22:42 +00:00
|
|
|
|
return nil, errors.New("No waku v2 support")
|
2021-06-16 20:19:45 +00:00
|
|
|
|
}
|
|
|
|
|
|
2019-11-23 17:57:05 +00:00
|
|
|
|
func (n *testNode) GetWhisper(_ interface{}) (types.Whisper, error) {
|
2020-07-21 15:41:10 +00:00
|
|
|
|
return nil, nil
|
2019-11-23 17:57:05 +00:00
|
|
|
|
}
|
|
|
|
|
|
2020-08-27 13:30:48 +00:00
|
|
|
|
func (n *testNode) PeersCount() int {
|
2020-08-27 12:38:59 +00:00
|
|
|
|
return 1
|
|
|
|
|
}
|
|
|
|
|
|
2024-06-10 15:02:42 +00:00
|
|
|
|
func (s *MessengerSuite) TestInitFilters() {
|
2019-11-21 16:19:22 +00:00
|
|
|
|
testCases := []struct {
|
|
|
|
|
Name string
|
|
|
|
|
Prep func()
|
|
|
|
|
AddedFilters int
|
|
|
|
|
}{
|
|
|
|
|
{
|
|
|
|
|
Name: "no chats and contacts",
|
|
|
|
|
Prep: func() {},
|
|
|
|
|
AddedFilters: 3,
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
Name: "active public chat",
|
|
|
|
|
Prep: func() {
|
|
|
|
|
publicChat := Chat{
|
|
|
|
|
ChatType: ChatTypePublic,
|
|
|
|
|
ID: "some-public-chat",
|
|
|
|
|
Active: true,
|
|
|
|
|
}
|
2019-12-02 15:34:05 +00:00
|
|
|
|
err := s.m.SaveChat(&publicChat)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
},
|
|
|
|
|
AddedFilters: 1,
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
Name: "active one-to-one chat",
|
|
|
|
|
Prep: func() {
|
|
|
|
|
key, err := crypto.GenerateKey()
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
privateChat := Chat{
|
2019-12-02 15:34:05 +00:00
|
|
|
|
ID: types.EncodeHex(crypto.FromECDSAPub(&key.PublicKey)),
|
|
|
|
|
ChatType: ChatTypeOneToOne,
|
|
|
|
|
Active: true,
|
2019-11-21 16:19:22 +00:00
|
|
|
|
}
|
2019-12-02 15:34:05 +00:00
|
|
|
|
err = s.m.SaveChat(&privateChat)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
},
|
|
|
|
|
AddedFilters: 1,
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
Name: "active group chat",
|
|
|
|
|
Prep: func() {
|
|
|
|
|
key1, err := crypto.GenerateKey()
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
key2, err := crypto.GenerateKey()
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
groupChat := Chat{
|
2020-02-07 11:56:30 +00:00
|
|
|
|
ID: "some-id",
|
2019-11-21 16:19:22 +00:00
|
|
|
|
ChatType: ChatTypePrivateGroupChat,
|
|
|
|
|
Active: true,
|
|
|
|
|
Members: []ChatMember{
|
|
|
|
|
{
|
2019-11-23 17:57:05 +00:00
|
|
|
|
ID: types.EncodeHex(crypto.FromECDSAPub(&key1.PublicKey)),
|
2019-11-21 16:19:22 +00:00
|
|
|
|
},
|
|
|
|
|
{
|
2019-11-23 17:57:05 +00:00
|
|
|
|
ID: types.EncodeHex(crypto.FromECDSAPub(&key2.PublicKey)),
|
2019-11-21 16:19:22 +00:00
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
}
|
2019-12-02 15:34:05 +00:00
|
|
|
|
err = s.m.SaveChat(&groupChat)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
},
|
|
|
|
|
AddedFilters: 2,
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
Name: "inactive chat",
|
|
|
|
|
Prep: func() {
|
|
|
|
|
publicChat := Chat{
|
|
|
|
|
ChatType: ChatTypePublic,
|
|
|
|
|
ID: "some-public-chat-2",
|
|
|
|
|
Active: false,
|
|
|
|
|
}
|
2019-12-02 15:34:05 +00:00
|
|
|
|
err := s.m.SaveChat(&publicChat)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
},
|
|
|
|
|
AddedFilters: 0,
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
Name: "added contact",
|
|
|
|
|
Prep: func() {
|
|
|
|
|
key, err := crypto.GenerateKey()
|
|
|
|
|
s.Require().NoError(err)
|
2022-10-14 08:50:36 +00:00
|
|
|
|
_, err = s.m.AddContact(context.Background(), &requests.AddContact{ID: types.EncodeHex(crypto.FromECDSAPub(&key.PublicKey))})
|
2019-11-21 16:19:22 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
},
|
2023-08-03 14:16:11 +00:00
|
|
|
|
AddedFilters: deprecation.AddProfileFiltersCount(1),
|
2019-11-21 16:19:22 +00:00
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
expectedFilters := 0
|
|
|
|
|
for _, tc := range testCases {
|
|
|
|
|
s.Run(tc.Name, func() {
|
|
|
|
|
tc.Prep()
|
2024-06-10 15:02:42 +00:00
|
|
|
|
err := s.m.InitFilters()
|
2019-11-21 16:19:22 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
filters := s.m.transport.Filters()
|
|
|
|
|
expectedFilters += tc.AddedFilters
|
2023-08-03 14:16:11 +00:00
|
|
|
|
s.Equal(deprecation.AddTimelineFiltersCount(expectedFilters), len(filters))
|
2019-11-21 16:19:22 +00:00
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-04-13 03:01:37 +00:00
|
|
|
|
func buildAudioMessage(s *MessengerSuite, chat Chat) *common.Message {
|
|
|
|
|
clock, timestamp := chat.NextClockAndTimestamp(&testTimeSource{})
|
2023-08-18 11:39:59 +00:00
|
|
|
|
message := common.NewMessage()
|
2021-04-13 03:01:37 +00:00
|
|
|
|
message.Text = "text-input-message"
|
|
|
|
|
message.ChatId = chat.ID
|
|
|
|
|
message.Clock = clock
|
|
|
|
|
message.Timestamp = timestamp
|
|
|
|
|
message.WhisperTimestamp = clock
|
|
|
|
|
message.LocalChatID = chat.ID
|
|
|
|
|
message.MessageType = protobuf.MessageType_PUBLIC_GROUP
|
|
|
|
|
message.ContentType = protobuf.ChatMessage_AUDIO
|
|
|
|
|
message.Payload = &protobuf.ChatMessage_Audio{
|
|
|
|
|
Audio: &protobuf.AudioMessage{
|
|
|
|
|
Type: 1,
|
|
|
|
|
Payload: []byte("some-payload"),
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return message
|
|
|
|
|
}
|
|
|
|
|
|
2020-09-01 13:27:01 +00:00
|
|
|
|
func buildTestMessage(chat Chat) *common.Message {
|
2020-01-20 16:44:32 +00:00
|
|
|
|
clock, timestamp := chat.NextClockAndTimestamp(&testTimeSource{})
|
2023-08-18 11:39:59 +00:00
|
|
|
|
message := common.NewMessage()
|
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 = "text-input-message"
|
|
|
|
|
message.ChatId = chat.ID
|
2020-01-20 16:44:32 +00:00
|
|
|
|
message.Clock = clock
|
|
|
|
|
message.Timestamp = timestamp
|
|
|
|
|
message.WhisperTimestamp = clock
|
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.LocalChatID = chat.ID
|
2019-12-02 15:34:05 +00:00
|
|
|
|
message.ContentType = protobuf.ChatMessage_TEXT_PLAIN
|
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 chat.ChatType {
|
2020-10-20 15:10:28 +00:00
|
|
|
|
case ChatTypePublic, ChatTypeProfile:
|
2020-07-25 11:46:43 +00:00
|
|
|
|
message.MessageType = protobuf.MessageType_PUBLIC_GROUP
|
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 ChatTypeOneToOne:
|
2020-07-25 11:46:43 +00:00
|
|
|
|
message.MessageType = protobuf.MessageType_ONE_TO_ONE
|
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 ChatTypePrivateGroupChat:
|
2021-07-26 21:06:32 +00:00
|
|
|
|
message.MessageType = protobuf.MessageType_PRIVATE_GROUP
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return message
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func buildTestGapMessage(chat Chat) *common.Message {
|
|
|
|
|
clock, timestamp := chat.NextClockAndTimestamp(&testTimeSource{})
|
2023-08-18 11:39:59 +00:00
|
|
|
|
message := common.NewMessage()
|
2021-07-26 21:06:32 +00:00
|
|
|
|
message.ChatId = chat.ID
|
|
|
|
|
message.Clock = clock
|
|
|
|
|
message.Timestamp = timestamp
|
|
|
|
|
message.WhisperTimestamp = clock
|
|
|
|
|
message.LocalChatID = chat.ID
|
|
|
|
|
message.ContentType = protobuf.ChatMessage_SYSTEM_MESSAGE_GAP
|
|
|
|
|
switch chat.ChatType {
|
|
|
|
|
case ChatTypePublic, ChatTypeProfile:
|
|
|
|
|
message.MessageType = protobuf.MessageType_PUBLIC_GROUP
|
|
|
|
|
case ChatTypeOneToOne:
|
|
|
|
|
message.MessageType = protobuf.MessageType_ONE_TO_ONE
|
|
|
|
|
case ChatTypePrivateGroupChat:
|
2020-07-25 11:46:43 +00:00
|
|
|
|
message.MessageType = protobuf.MessageType_PRIVATE_GROUP
|
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 message
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *MessengerSuite) TestMarkMessagesSeen() {
|
2020-01-20 16:44:32 +00:00
|
|
|
|
chat := CreatePublicChat("test-chat", s.m.transport)
|
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
|
|
|
|
chat.UnviewedMessagesCount = 2
|
2021-05-26 06:38:25 +00:00
|
|
|
|
chat.UnviewedMentionsCount = 3
|
2021-10-21 17:04:56 +00:00
|
|
|
|
chat.Highlight = true
|
2021-01-11 10:32:51 +00:00
|
|
|
|
err := s.m.SaveChat(chat)
|
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
|
|
|
|
s.Require().NoError(err)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
inputMessage1 := buildTestMessage(*chat)
|
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
|
|
|
|
inputMessage1.ID = "1"
|
|
|
|
|
inputMessage1.Seen = false
|
2021-05-26 06:38:25 +00:00
|
|
|
|
inputMessage1.Text = "hey @" + common.PubkeyToHex(&s.m.identity.PublicKey)
|
|
|
|
|
inputMessage1.Mentioned = true
|
2021-01-11 10:32:51 +00:00
|
|
|
|
inputMessage2 := buildTestMessage(*chat)
|
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
|
|
|
|
inputMessage2.ID = "2"
|
2021-05-26 06:38:25 +00:00
|
|
|
|
inputMessage2.Text = "hey @" + common.PubkeyToHex(&s.m.identity.PublicKey)
|
|
|
|
|
inputMessage2.Mentioned = true
|
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
|
|
|
|
inputMessage2.Seen = false
|
|
|
|
|
|
2020-09-01 13:27:01 +00:00
|
|
|
|
err = s.m.SaveMessages([]*common.Message{inputMessage1, inputMessage2})
|
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
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2023-12-25 06:25:22 +00:00
|
|
|
|
response, err := s.m.MarkMessagesRead(chat.ID, []string{inputMessage1.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
|
|
|
|
s.Require().NoError(err)
|
2023-12-25 06:25:22 +00:00
|
|
|
|
|
|
|
|
|
s.Require().Len(response.GetSeenAndUnseenMessages(), 1)
|
|
|
|
|
s.Require().Equal(chat.ID, response.GetSeenAndUnseenMessages()[0].ChatID)
|
|
|
|
|
s.Require().Equal(uint64(1), response.GetSeenAndUnseenMessages()[0].Count)
|
|
|
|
|
s.Require().Equal(uint64(1), response.GetSeenAndUnseenMessages()[0].CountWithMentions)
|
|
|
|
|
s.Require().Equal(true, response.GetSeenAndUnseenMessages()[0].Seen)
|
|
|
|
|
s.Require().Len(response.ActivityCenterNotifications(), 0)
|
Move to protobuf for Message type (#1706)
* Use a single Message type `v1/message.go` and `message.go` are the same now, and they embed `protobuf.ChatMessage`
* Use `SendChatMessage` for sending chat messages, this is basically the old `Send` but a bit more flexible so we can send different message types (stickers,commands), and not just text.
* Remove dedup from services/shhext. Because now we process in status-protocol, dedup makes less sense, as those messages are going to be processed anyway, so removing for now, we can re-evaluate if bringing it to status-go or not.
* Change the various retrieveX method to a single one:
`RetrieveAll` will be processing those messages that it can process (Currently only `Message`), and return the rest in `RawMessages` (still transit). The format for the response is:
`Chats`: -> The chats updated by receiving the message
`Messages`: -> The messages retrieved (already matched to a chat)
`Contacts`: -> The contacts updated by the messages
`RawMessages` -> Anything else that can't be parsed, eventually as we move everything to status-protocol-go this will go away.
2019-12-05 16:25:34 +00:00
|
|
|
|
|
2020-12-07 15:13:39 +00:00
|
|
|
|
// Make sure that if it's not seen, it does not return a count of 1
|
2023-12-25 06:25:22 +00:00
|
|
|
|
response, err = s.m.MarkMessagesRead(chat.ID, []string{inputMessage1.ID})
|
2020-12-07 15:13:39 +00:00
|
|
|
|
s.Require().NoError(err)
|
2023-12-25 06:25:22 +00:00
|
|
|
|
s.Require().Len(response.GetSeenAndUnseenMessages(), 1)
|
|
|
|
|
s.Require().Equal(chat.ID, response.GetSeenAndUnseenMessages()[0].ChatID)
|
|
|
|
|
s.Require().Equal(uint64(0), response.GetSeenAndUnseenMessages()[0].Count)
|
|
|
|
|
s.Require().Equal(uint64(0), response.GetSeenAndUnseenMessages()[0].CountWithMentions)
|
|
|
|
|
s.Require().Equal(true, response.GetSeenAndUnseenMessages()[0].Seen)
|
|
|
|
|
s.Require().Len(response.ActivityCenterNotifications(), 0)
|
2020-12-07 15:13:39 +00:00
|
|
|
|
|
2019-12-02 15:34:05 +00:00
|
|
|
|
chats := s.m.Chats()
|
2021-05-14 10:55:42 +00:00
|
|
|
|
for _, c := range chats {
|
|
|
|
|
if c.ID == chat.ID {
|
|
|
|
|
s.Require().Equal(uint(1), c.UnviewedMessagesCount)
|
2021-05-26 06:38:25 +00:00
|
|
|
|
s.Require().Equal(uint(1), c.UnviewedMentionsCount)
|
2021-10-21 17:04:56 +00:00
|
|
|
|
s.Require().Equal(false, c.Highlight)
|
2021-05-14 10:55:42 +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
|
|
|
|
}
|
|
|
|
|
|
2020-02-26 12:31:48 +00:00
|
|
|
|
func (s *MessengerSuite) TestMarkAllRead() {
|
|
|
|
|
chat := CreatePublicChat("test-chat", s.m.transport)
|
|
|
|
|
chat.UnviewedMessagesCount = 2
|
2021-10-21 17:04:56 +00:00
|
|
|
|
chat.Highlight = true
|
2021-01-11 10:32:51 +00:00
|
|
|
|
err := s.m.SaveChat(chat)
|
2020-02-26 12:31:48 +00:00
|
|
|
|
s.Require().NoError(err)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
inputMessage1 := buildTestMessage(*chat)
|
2020-02-26 12:31:48 +00:00
|
|
|
|
inputMessage1.ID = "1"
|
|
|
|
|
inputMessage1.Seen = false
|
2021-01-11 10:32:51 +00:00
|
|
|
|
inputMessage2 := buildTestMessage(*chat)
|
2020-02-26 12:31:48 +00:00
|
|
|
|
inputMessage2.ID = "2"
|
|
|
|
|
inputMessage2.Seen = false
|
|
|
|
|
|
2020-09-01 13:27:01 +00:00
|
|
|
|
err = s.m.SaveMessages([]*common.Message{inputMessage1, inputMessage2})
|
2020-02-26 12:31:48 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2023-11-27 11:22:24 +00:00
|
|
|
|
_, err = s.m.MarkAllRead(context.Background(), chat.ID)
|
2020-02-26 12:31:48 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
chats := s.m.Chats()
|
2023-08-03 14:16:11 +00:00
|
|
|
|
s.Require().Len(chats, deprecation.AddChatsCount(1))
|
2021-05-14 10:55:42 +00:00
|
|
|
|
for idx := range chats {
|
|
|
|
|
if chats[idx].ID == chat.ID {
|
|
|
|
|
s.Require().Equal(uint(0), chats[idx].UnviewedMessagesCount)
|
2021-10-21 17:04:56 +00:00
|
|
|
|
s.Require().Equal(false, chats[idx].Highlight)
|
2021-05-14 10:55:42 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
2020-02-26 12:31:48 +00:00
|
|
|
|
}
|
|
|
|
|
|
2019-11-21 16:19:22 +00:00
|
|
|
|
func (s *MessengerSuite) TestSendPublic() {
|
2020-01-20 16:44:32 +00:00
|
|
|
|
chat := CreatePublicChat("test-chat", s.m.transport)
|
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
|
|
|
|
chat.LastClockValue = uint64(100000000000000)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
err := s.m.SaveChat(chat)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
s.NoError(err)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
inputMessage := buildTestMessage(*chat)
|
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
|
|
|
|
response, err := s.m.SendChatMessage(context.Background(), inputMessage)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
s.NoError(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
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Equal(1, len(response.Messages()), "it returns the message")
|
|
|
|
|
outputMessage := response.Messages()[0]
|
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
|
|
|
|
|
2019-12-02 15:34:05 +00:00
|
|
|
|
s.Require().Equal(uint64(100000000000001), outputMessage.Clock, "it correctly sets the clock")
|
|
|
|
|
s.Require().Equal(uint64(100000000000001), chat.LastClockValue, "it correctly sets the last-clock-value")
|
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
|
|
|
|
s.Require().NotEqual(uint64(0), chat.Timestamp, "it sets the timestamp")
|
|
|
|
|
s.Require().Equal("0x"+hex.EncodeToString(crypto.FromECDSAPub(&s.privateKey.PublicKey)), outputMessage.From, "it sets the From field")
|
|
|
|
|
s.Require().True(outputMessage.Seen, "it marks the message as seen")
|
2020-09-01 13:27:01 +00:00
|
|
|
|
s.Require().Equal(outputMessage.OutgoingStatus, common.OutgoingStatusSending, "it marks the message as sending")
|
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
|
|
|
|
s.Require().NotEmpty(outputMessage.ID, "it sets the ID field")
|
2020-07-25 11:46:43 +00:00
|
|
|
|
s.Require().Equal(protobuf.MessageType_PUBLIC_GROUP, outputMessage.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
|
|
|
|
|
|
|
|
|
savedMessages, _, err := s.m.MessageByChatID(chat.ID, "", 10)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
s.Require().Equal(1, len(savedMessages), "it saves the message")
|
2019-11-21 16:19:22 +00:00
|
|
|
|
}
|
|
|
|
|
|
2020-10-20 15:10:28 +00:00
|
|
|
|
func (s *MessengerSuite) TestSendProfile() {
|
2023-08-03 14:16:11 +00:00
|
|
|
|
// Early exit to skip testing deprecated code
|
|
|
|
|
if deprecation.ChatProfileDeprecated {
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-25 15:15:22 +00:00
|
|
|
|
chat := CreateProfileChat("0x"+hex.EncodeToString(crypto.FromECDSAPub(&s.privateKey.PublicKey)), s.m.transport)
|
2020-10-20 15:10:28 +00:00
|
|
|
|
chat.LastClockValue = uint64(100000000000000)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
err := s.m.SaveChat(chat)
|
2020-10-20 15:10:28 +00:00
|
|
|
|
s.NoError(err)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
inputMessage := buildTestMessage(*chat)
|
2020-10-20 15:10:28 +00:00
|
|
|
|
response, err := s.m.SendChatMessage(context.Background(), inputMessage)
|
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Equal(1, len(response.Messages()), "it returns the message")
|
|
|
|
|
outputMessage := response.Messages()[0]
|
2020-10-20 15:10:28 +00:00
|
|
|
|
|
|
|
|
|
s.Require().Equal(uint64(100000000000001), outputMessage.Clock, "it correctly sets the clock")
|
|
|
|
|
s.Require().Equal(uint64(100000000000001), chat.LastClockValue, "it correctly sets the last-clock-value")
|
|
|
|
|
s.Require().NotEqual(uint64(0), chat.Timestamp, "it sets the timestamp")
|
|
|
|
|
s.Require().Equal("0x"+hex.EncodeToString(crypto.FromECDSAPub(&s.privateKey.PublicKey)), outputMessage.From, "it sets the From field")
|
|
|
|
|
s.Require().Equal(chat.Profile, outputMessage.From, "From equal to chat Profile")
|
|
|
|
|
s.Require().True(outputMessage.Seen, "it marks the message as seen")
|
|
|
|
|
s.Require().Equal(outputMessage.OutgoingStatus, common.OutgoingStatusSending, "it marks the message as sending")
|
|
|
|
|
s.Require().NotEmpty(outputMessage.ID, "it sets the ID field")
|
|
|
|
|
s.Require().Equal(protobuf.MessageType_PUBLIC_GROUP, outputMessage.MessageType)
|
|
|
|
|
|
|
|
|
|
savedMessages, _, err := s.m.MessageByChatID(chat.ID, "", 10)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
s.Require().Equal(1, len(savedMessages), "it saves the 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
|
|
|
|
func (s *MessengerSuite) TestSendPrivateOneToOne() {
|
2019-11-21 16:19:22 +00:00
|
|
|
|
recipientKey, err := crypto.GenerateKey()
|
|
|
|
|
s.NoError(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
|
|
|
|
pkString := hex.EncodeToString(crypto.FromECDSAPub(&recipientKey.PublicKey))
|
2020-01-20 16:44:32 +00:00
|
|
|
|
chat := CreateOneToOneChat(pkString, &recipientKey.PublicKey, s.m.transport)
|
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-08-18 11:39:59 +00:00
|
|
|
|
inputMessage := common.NewMessage()
|
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
|
|
|
|
inputMessage.ChatId = chat.ID
|
|
|
|
|
chat.LastClockValue = uint64(100000000000000)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
err = s.m.SaveChat(chat)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
s.NoError(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
|
|
|
|
response, err := s.m.SendChatMessage(context.Background(), inputMessage)
|
|
|
|
|
s.NoError(err)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Equal(1, len(response.Messages()), "it returns the message")
|
|
|
|
|
outputMessage := response.Messages()[0]
|
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
|
|
|
|
|
2019-12-02 15:34:05 +00:00
|
|
|
|
s.Require().Equal(uint64(100000000000001), outputMessage.Clock, "it correctly sets the clock")
|
|
|
|
|
s.Require().Equal(uint64(100000000000001), chat.LastClockValue, "it correctly sets the last-clock-value")
|
|
|
|
|
|
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
|
|
|
|
s.Require().NotEqual(uint64(0), chat.Timestamp, "it sets the timestamp")
|
|
|
|
|
s.Require().Equal("0x"+hex.EncodeToString(crypto.FromECDSAPub(&s.privateKey.PublicKey)), outputMessage.From, "it sets the From field")
|
|
|
|
|
s.Require().True(outputMessage.Seen, "it marks the message as seen")
|
2020-09-01 13:27:01 +00:00
|
|
|
|
s.Require().Equal(outputMessage.OutgoingStatus, common.OutgoingStatusSending, "it marks the message as sending")
|
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
|
|
|
|
s.Require().NotEmpty(outputMessage.ID, "it sets the ID field")
|
2020-07-25 11:46:43 +00:00
|
|
|
|
s.Require().Equal(protobuf.MessageType_ONE_TO_ONE, outputMessage.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
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *MessengerSuite) TestSendPrivateGroup() {
|
2019-12-02 15:34:05 +00:00
|
|
|
|
response, err := s.m.CreateGroupChatWithMembers(context.Background(), "test", []string{})
|
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
|
|
|
|
s.NoError(err)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2019-12-02 15:34:05 +00:00
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
chat := response.Chats()[0]
|
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
|
|
|
|
key, err := crypto.GenerateKey()
|
|
|
|
|
s.NoError(err)
|
2022-08-26 09:25:54 +00:00
|
|
|
|
|
|
|
|
|
s.Require().NoError(makeMutualContact(s.m, &key.PublicKey))
|
|
|
|
|
|
2019-12-02 15:34:05 +00:00
|
|
|
|
members := []string{"0x" + hex.EncodeToString(crypto.FromECDSAPub(&key.PublicKey))}
|
|
|
|
|
_, err = s.m.AddMembersToGroupChat(context.Background(), chat.ID, members)
|
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
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
2023-08-18 11:39:59 +00:00
|
|
|
|
inputMessage := common.NewMessage()
|
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
|
|
|
|
inputMessage.ChatId = chat.ID
|
|
|
|
|
chat.LastClockValue = uint64(100000000000000)
|
2019-12-02 15:34:05 +00:00
|
|
|
|
err = s.m.SaveChat(chat)
|
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
|
|
|
|
s.NoError(err)
|
2019-12-02 15:34:05 +00:00
|
|
|
|
response, err = s.m.SendChatMessage(context.Background(), inputMessage)
|
2020-09-01 13:27:01 +00:00
|
|
|
|
s.Require().NoError(err)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Equal(1, len(response.Messages()), "it returns the message")
|
|
|
|
|
outputMessage := response.Messages()[0]
|
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
|
|
|
|
|
2019-12-02 15:34:05 +00:00
|
|
|
|
s.Require().Equal(uint64(100000000000001), outputMessage.Clock, "it correctly sets the clock")
|
|
|
|
|
s.Require().Equal(uint64(100000000000001), chat.LastClockValue, "it correctly sets the last-clock-value")
|
|
|
|
|
|
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
|
|
|
|
s.Require().NotEqual(uint64(0), chat.Timestamp, "it sets the timestamp")
|
|
|
|
|
s.Require().Equal("0x"+hex.EncodeToString(crypto.FromECDSAPub(&s.privateKey.PublicKey)), outputMessage.From, "it sets the From field")
|
|
|
|
|
s.Require().True(outputMessage.Seen, "it marks the message as seen")
|
2022-05-30 15:34:48 +00:00
|
|
|
|
s.Require().Equal(outputMessage.OutgoingStatus, common.OutgoingStatusSending, "it marks the message as sending")
|
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
|
|
|
|
s.Require().NotEmpty(outputMessage.ID, "it sets the ID field")
|
2020-07-25 11:46:43 +00:00
|
|
|
|
s.Require().Equal(protobuf.MessageType_PRIVATE_GROUP, outputMessage.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
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *MessengerSuite) TestSendPrivateEmptyGroup() {
|
2019-12-02 15:34:05 +00:00
|
|
|
|
response, err := s.m.CreateGroupChatWithMembers(context.Background(), "test", []string{})
|
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
|
|
|
|
s.NoError(err)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2019-12-02 15:34:05 +00:00
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
chat := response.Chats()[0]
|
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-08-18 11:39:59 +00:00
|
|
|
|
inputMessage := common.NewMessage()
|
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
|
|
|
|
inputMessage.ChatId = chat.ID
|
|
|
|
|
chat.LastClockValue = uint64(100000000000000)
|
2019-12-02 15:34:05 +00:00
|
|
|
|
err = s.m.SaveChat(chat)
|
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
|
|
|
|
s.NoError(err)
|
2019-12-02 15:34:05 +00:00
|
|
|
|
response, err = s.m.SendChatMessage(context.Background(), inputMessage)
|
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
|
|
|
|
s.NoError(err)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Equal(1, len(response.Messages()), "it returns the message")
|
|
|
|
|
outputMessage := response.Messages()[0]
|
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
|
|
|
|
|
2019-12-02 15:34:05 +00:00
|
|
|
|
s.Require().Equal(uint64(100000000000001), outputMessage.Clock, "it correctly sets the clock")
|
|
|
|
|
s.Require().Equal(uint64(100000000000001), chat.LastClockValue, "it correctly sets the last-clock-value")
|
|
|
|
|
|
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
|
|
|
|
s.Require().NotEqual(uint64(0), chat.Timestamp, "it sets the timestamp")
|
|
|
|
|
s.Require().Equal("0x"+hex.EncodeToString(crypto.FromECDSAPub(&s.privateKey.PublicKey)), outputMessage.From, "it sets the From field")
|
|
|
|
|
s.Require().True(outputMessage.Seen, "it marks the message as seen")
|
2021-01-22 13:59:45 +00:00
|
|
|
|
s.Require().Equal(outputMessage.OutgoingStatus, common.OutgoingStatusSent, "it marks the message as sent")
|
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
|
|
|
|
s.Require().NotEmpty(outputMessage.ID, "it sets the ID field")
|
2020-07-25 11:46:43 +00:00
|
|
|
|
s.Require().Equal(protobuf.MessageType_PRIVATE_GROUP, outputMessage.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
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Make sure public messages sent by us are not
|
2019-11-21 16:19:22 +00:00
|
|
|
|
func (s *MessengerSuite) TestRetrieveOwnPublic() {
|
2020-01-20 16:44:32 +00:00
|
|
|
|
chat := CreatePublicChat("status", s.m.transport)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
err := s.m.SaveChat(chat)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
s.NoError(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
|
|
|
|
// Right-to-left text
|
|
|
|
|
text := "پيل اندر خانه يي تاريک بود عرضه را آورده بودندش هنود i\nاز براي ديدنش مردم بسي اندر آن ظلمت همي شد هر کسي"
|
2019-11-21 16:19:22 +00:00
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
inputMessage := buildTestMessage(*chat)
|
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
|
|
|
|
inputMessage.ChatId = chat.ID
|
|
|
|
|
inputMessage.Text = text
|
|
|
|
|
|
|
|
|
|
response, err := s.m.SendChatMessage(context.Background(), inputMessage)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(response.Messages(), 1)
|
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
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
textMessage := response.Messages()[0]
|
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
|
|
|
|
|
|
|
|
|
s.Equal(textMessage.Text, text)
|
|
|
|
|
s.NotNil(textMessage.ParsedText)
|
|
|
|
|
s.True(textMessage.RTL)
|
|
|
|
|
s.Equal(1, textMessage.LineCount)
|
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
|
|
|
|
actualChat := response.Chats()[0]
|
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
|
|
|
|
// It does not set the unviewed messages count
|
|
|
|
|
s.Require().Equal(uint(0), actualChat.UnviewedMessagesCount)
|
|
|
|
|
// It updates the last message clock value
|
|
|
|
|
s.Require().Equal(textMessage.Clock, actualChat.LastClockValue)
|
|
|
|
|
// It sets the last message
|
|
|
|
|
s.Require().NotNil(actualChat.LastMessage)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Retrieve their public message
|
|
|
|
|
func (s *MessengerSuite) TestRetrieveTheirPublic() {
|
2023-03-08 17:47:09 +00:00
|
|
|
|
theirMessenger := s.newMessenger()
|
2023-11-27 17:01:13 +00:00
|
|
|
|
defer TearDownMessenger(&s.Suite, theirMessenger)
|
2020-01-20 16:44:32 +00:00
|
|
|
|
theirChat := CreatePublicChat("status", s.m.transport)
|
2024-02-26 09:12:37 +00:00
|
|
|
|
err := theirMessenger.SaveChat(theirChat)
|
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
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2020-01-20 16:44:32 +00:00
|
|
|
|
chat := CreatePublicChat("status", s.m.transport)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
err = s.m.SaveChat(chat)
|
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
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
_, err = s.m.Join(chat)
|
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
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
inputMessage := buildTestMessage(*chat)
|
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
|
|
|
|
|
|
|
|
|
sendResponse, err := theirMessenger.SendChatMessage(context.Background(), inputMessage)
|
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
sentMessage := sendResponse.Messages()[0]
|
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
|
|
|
|
|
|
|
|
|
// Wait for the message to reach its destination
|
2020-04-22 12:58:28 +00:00
|
|
|
|
response, err := WaitOnMessengerResponse(
|
|
|
|
|
s.m,
|
2021-06-03 13:11:55 +00:00
|
|
|
|
func(r *MessengerResponse) bool { return len(r.Messages()) > 0 },
|
2020-04-22 12:58:28 +00:00
|
|
|
|
"no 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
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(response.Messages(), 1)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
|
|
|
|
actualChat := response.Chats()[0]
|
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
|
|
|
|
// It sets the unviewed messages count
|
|
|
|
|
s.Require().Equal(uint(1), actualChat.UnviewedMessagesCount)
|
|
|
|
|
// It updates the last message clock value
|
|
|
|
|
s.Require().Equal(sentMessage.Clock, actualChat.LastClockValue)
|
|
|
|
|
// It sets the last message
|
|
|
|
|
s.Require().NotNil(actualChat.LastMessage)
|
|
|
|
|
}
|
|
|
|
|
|
2021-04-13 03:01:37 +00:00
|
|
|
|
// Drop audio message in public group
|
|
|
|
|
func (s *MessengerSuite) TestDropAudioMessageInPublicGroup() {
|
2023-03-08 17:47:09 +00:00
|
|
|
|
theirMessenger := s.newMessenger()
|
2023-11-27 17:01:13 +00:00
|
|
|
|
defer TearDownMessenger(&s.Suite, theirMessenger)
|
2021-04-13 03:01:37 +00:00
|
|
|
|
theirChat := CreatePublicChat("status", s.m.transport)
|
2024-02-26 09:12:37 +00:00
|
|
|
|
err := theirMessenger.SaveChat(theirChat)
|
2021-04-13 03:01:37 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
chat := CreatePublicChat("status", s.m.transport)
|
|
|
|
|
err = s.m.SaveChat(chat)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
_, err = s.m.Join(chat)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
inputMessage := buildAudioMessage(s, *chat)
|
|
|
|
|
|
|
|
|
|
_, err = theirMessenger.SendChatMessage(context.Background(), inputMessage)
|
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
|
|
|
|
time.Sleep(100 * time.Millisecond)
|
|
|
|
|
response, err := s.m.RetrieveAll()
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
s.Require().Len(response.Messages(), 0)
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
func (s *MessengerSuite) TestDeletedAtClockValue() {
|
2023-03-08 17:47:09 +00:00
|
|
|
|
theirMessenger := s.newMessenger()
|
2023-11-27 17:01:13 +00:00
|
|
|
|
defer TearDownMessenger(&s.Suite, theirMessenger)
|
2020-01-20 16:44:32 +00:00
|
|
|
|
theirChat := CreatePublicChat("status", s.m.transport)
|
2024-02-26 09:12:37 +00:00
|
|
|
|
err := theirMessenger.SaveChat(theirChat)
|
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
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2020-01-20 16:44:32 +00:00
|
|
|
|
chat := CreatePublicChat("status", s.m.transport)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
err = s.m.SaveChat(chat)
|
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
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
_, err = s.m.Join(chat)
|
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
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
inputMessage := buildTestMessage(*chat)
|
2019-11-21 16:19:22 +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
|
|
|
|
sentResponse, err := theirMessenger.SendChatMessage(context.Background(), inputMessage)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
chat.DeletedAtClockValue = sentResponse.Messages()[0].Clock
|
2021-01-11 10:32:51 +00:00
|
|
|
|
err = s.m.SaveChat(chat)
|
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
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
// Wait for the message to reach its destination
|
|
|
|
|
time.Sleep(100 * time.Millisecond)
|
|
|
|
|
response, err := s.m.RetrieveAll()
|
|
|
|
|
s.Require().NoError(err)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(response.Messages(), 0)
|
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
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *MessengerSuite) TestRetrieveBlockedContact() {
|
2023-03-08 17:47:09 +00:00
|
|
|
|
theirMessenger := s.newMessenger()
|
2023-11-27 17:01:13 +00:00
|
|
|
|
defer TearDownMessenger(&s.Suite, theirMessenger)
|
2022-10-26 09:53:49 +00:00
|
|
|
|
|
2020-01-20 16:44:32 +00:00
|
|
|
|
theirChat := CreatePublicChat("status", s.m.transport)
|
2024-02-26 09:12:37 +00:00
|
|
|
|
err := theirMessenger.SaveChat(theirChat)
|
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
|
|
|
|
s.Require().NoError(err)
|
2022-10-26 09:53:49 +00:00
|
|
|
|
_, err = theirMessenger.Join(theirChat)
|
|
|
|
|
s.Require().NoError(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
|
|
|
|
|
2020-01-20 16:44:32 +00:00
|
|
|
|
chat := CreatePublicChat("status", s.m.transport)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
err = s.m.SaveChat(chat)
|
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
|
|
|
|
s.Require().NoError(err)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
_, err = s.m.Join(chat)
|
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
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
publicKeyHex := "0x" + hex.EncodeToString(crypto.FromECDSAPub(&theirMessenger.identity.PublicKey))
|
|
|
|
|
blockedContact := Contact{
|
2021-01-11 10:32:51 +00:00
|
|
|
|
ID: publicKeyHex,
|
2022-02-17 15:13:10 +00:00
|
|
|
|
EnsName: "contact-name",
|
2021-01-11 10:32:51 +00:00
|
|
|
|
LastUpdated: 20,
|
2022-10-26 09:53:49 +00:00
|
|
|
|
Blocked: false,
|
Move to protobuf for Message type (#1706)
* Use a single Message type `v1/message.go` and `message.go` are the same now, and they embed `protobuf.ChatMessage`
* Use `SendChatMessage` for sending chat messages, this is basically the old `Send` but a bit more flexible so we can send different message types (stickers,commands), and not just text.
* Remove dedup from services/shhext. Because now we process in status-protocol, dedup makes less sense, as those messages are going to be processed anyway, so removing for now, we can re-evaluate if bringing it to status-go or not.
* Change the various retrieveX method to a single one:
`RetrieveAll` will be processing those messages that it can process (Currently only `Message`), and return the rest in `RawMessages` (still transit). The format for the response is:
`Chats`: -> The chats updated by receiving the message
`Messages`: -> The messages retrieved (already matched to a chat)
`Contacts`: -> The contacts updated by the messages
`RawMessages` -> Anything else that can't be parsed, eventually as we move everything to status-protocol-go this will go away.
2019-12-05 16:25:34 +00:00
|
|
|
|
}
|
|
|
|
|
|
2022-10-26 09:53:49 +00:00
|
|
|
|
requireMessageArrival := func(receiver *Messenger, require bool) {
|
|
|
|
|
// Wait for the message to reach its destination
|
|
|
|
|
time.Sleep(100 * time.Millisecond)
|
|
|
|
|
response, err := receiver.RetrieveAll()
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
if require {
|
2023-06-10 02:00:17 +00:00
|
|
|
|
containTextMsg := false
|
|
|
|
|
for _, msg := range response.Messages() {
|
|
|
|
|
if msg.ContentType == protobuf.ChatMessage_TEXT_PLAIN && msg.Text == "text-input-message" {
|
|
|
|
|
containTextMsg = true
|
|
|
|
|
break
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
s.Require().True(containTextMsg)
|
2022-10-26 09:53:49 +00:00
|
|
|
|
} else {
|
|
|
|
|
s.Require().Len(response.Messages(), 0)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Block contact
|
2023-10-22 09:41:20 +00:00
|
|
|
|
_, err = s.m.BlockContact(context.Background(), blockedContact.ID, false)
|
2021-10-22 14:20:42 +00:00
|
|
|
|
s.Require().NoError(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
|
|
|
|
|
2022-10-26 09:53:49 +00:00
|
|
|
|
// Blocked contact sends message, we should not receive it
|
|
|
|
|
theirMessage := buildTestMessage(*theirChat)
|
|
|
|
|
_, err = theirMessenger.SendChatMessage(context.Background(), theirMessage)
|
|
|
|
|
s.NoError(err)
|
|
|
|
|
requireMessageArrival(s.m, false)
|
Move to protobuf for Message type (#1706)
* Use a single Message type `v1/message.go` and `message.go` are the same now, and they embed `protobuf.ChatMessage`
* Use `SendChatMessage` for sending chat messages, this is basically the old `Send` but a bit more flexible so we can send different message types (stickers,commands), and not just text.
* Remove dedup from services/shhext. Because now we process in status-protocol, dedup makes less sense, as those messages are going to be processed anyway, so removing for now, we can re-evaluate if bringing it to status-go or not.
* Change the various retrieveX method to a single one:
`RetrieveAll` will be processing those messages that it can process (Currently only `Message`), and return the rest in `RawMessages` (still transit). The format for the response is:
`Chats`: -> The chats updated by receiving the message
`Messages`: -> The messages retrieved (already matched to a chat)
`Contacts`: -> The contacts updated by the messages
`RawMessages` -> Anything else that can't be parsed, eventually as we move everything to status-protocol-go this will go away.
2019-12-05 16:25:34 +00:00
|
|
|
|
|
2022-10-26 09:53:49 +00:00
|
|
|
|
// We send a message, blocked contact should still receive it
|
|
|
|
|
ourMessage := buildTestMessage(*chat)
|
|
|
|
|
_, err = s.m.SendChatMessage(context.Background(), ourMessage)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
s.NoError(err)
|
2022-10-26 09:53:49 +00:00
|
|
|
|
requireMessageArrival(theirMessenger, true)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
|
2022-10-26 09:53:49 +00:00
|
|
|
|
// Unblock contact
|
2023-06-01 17:26:12 +00:00
|
|
|
|
response, err := s.m.UnblockContact(blockedContact.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
|
|
|
|
s.Require().NoError(err)
|
2023-06-01 17:26:12 +00:00
|
|
|
|
s.Require().NotNil(response)
|
|
|
|
|
s.Require().Equal(false, response.Contacts[0].Blocked)
|
|
|
|
|
s.Require().Equal(true, response.Contacts[0].Removed)
|
2022-10-26 09:53:49 +00:00
|
|
|
|
|
|
|
|
|
// Unblocked contact sends message, we should receive it
|
|
|
|
|
_, err = theirMessenger.SendChatMessage(context.Background(), theirMessage)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
requireMessageArrival(s.m, true)
|
|
|
|
|
|
|
|
|
|
// We send a message, unblocked contact should receive it
|
|
|
|
|
_, err = s.m.SendChatMessage(context.Background(), ourMessage)
|
|
|
|
|
s.NoError(err)
|
|
|
|
|
requireMessageArrival(theirMessenger, true)
|
2019-11-21 16:19:22 +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
|
|
|
|
// Resend their public message, receive only once
|
|
|
|
|
func (s *MessengerSuite) TestResendPublicMessage() {
|
2023-03-08 17:47:09 +00:00
|
|
|
|
theirMessenger := s.newMessenger()
|
2023-11-27 17:01:13 +00:00
|
|
|
|
defer TearDownMessenger(&s.Suite, theirMessenger)
|
2020-01-20 16:44:32 +00:00
|
|
|
|
theirChat := CreatePublicChat("status", s.m.transport)
|
2024-02-26 09:12:37 +00:00
|
|
|
|
err := theirMessenger.SaveChat(theirChat)
|
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
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2020-01-20 16:44:32 +00:00
|
|
|
|
chat := CreatePublicChat("status", s.m.transport)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
err = s.m.SaveChat(chat)
|
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
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
_, err = s.m.Join(chat)
|
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
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
inputMessage := buildTestMessage(*chat)
|
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
|
|
|
|
|
|
|
|
|
sendResponse1, err := theirMessenger.SendChatMessage(context.Background(), inputMessage)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
sentMessage := sendResponse1.Messages()[0]
|
Move to protobuf for Message type (#1706)
* Use a single Message type `v1/message.go` and `message.go` are the same now, and they embed `protobuf.ChatMessage`
* Use `SendChatMessage` for sending chat messages, this is basically the old `Send` but a bit more flexible so we can send different message types (stickers,commands), and not just text.
* Remove dedup from services/shhext. Because now we process in status-protocol, dedup makes less sense, as those messages are going to be processed anyway, so removing for now, we can re-evaluate if bringing it to status-go or not.
* Change the various retrieveX method to a single one:
`RetrieveAll` will be processing those messages that it can process (Currently only `Message`), and return the rest in `RawMessages` (still transit). The format for the response is:
`Chats`: -> The chats updated by receiving the message
`Messages`: -> The messages retrieved (already matched to a chat)
`Contacts`: -> The contacts updated by the messages
`RawMessages` -> Anything else that can't be parsed, eventually as we move everything to status-protocol-go this will go away.
2019-12-05 16:25:34 +00:00
|
|
|
|
|
2020-01-10 18:59:01 +00:00
|
|
|
|
err = theirMessenger.ReSendChatMessage(context.Background(), sentMessage.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
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
// Wait for the message to reach its destination
|
2020-04-22 12:58:28 +00:00
|
|
|
|
response, err := WaitOnMessengerResponse(
|
|
|
|
|
s.m,
|
2021-06-03 13:11:55 +00:00
|
|
|
|
func(r *MessengerResponse) bool { return len(r.Messages()) > 0 },
|
2020-04-22 12:58:28 +00:00
|
|
|
|
"no 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
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(response.Messages(), 1)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
|
|
|
|
actualChat := response.Chats()[0]
|
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
|
|
|
|
// It sets the unviewed messages count
|
|
|
|
|
s.Require().Equal(uint(1), actualChat.UnviewedMessagesCount)
|
|
|
|
|
// It updates the last message clock value
|
|
|
|
|
s.Require().Equal(sentMessage.Clock, actualChat.LastClockValue)
|
|
|
|
|
// It sets the last message
|
|
|
|
|
s.Require().NotNil(actualChat.LastMessage)
|
|
|
|
|
|
|
|
|
|
// We send the messag again
|
2020-01-10 18:59:01 +00:00
|
|
|
|
err = theirMessenger.ReSendChatMessage(context.Background(), sentMessage.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
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
// It should not be retrieved anymore
|
|
|
|
|
time.Sleep(100 * time.Millisecond)
|
|
|
|
|
response, err = s.m.RetrieveAll()
|
|
|
|
|
s.Require().NoError(err)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(response.Messages(), 0)
|
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
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Test receiving a message on an existing private chat
|
|
|
|
|
func (s *MessengerSuite) TestRetrieveTheirPrivateChatExisting() {
|
2023-03-08 17:47:09 +00:00
|
|
|
|
theirMessenger := s.newMessenger()
|
2023-11-27 17:01:13 +00:00
|
|
|
|
defer TearDownMessenger(&s.Suite, theirMessenger)
|
2020-01-20 16:44:32 +00:00
|
|
|
|
theirChat := CreateOneToOneChat("XXX", &s.privateKey.PublicKey, s.m.transport)
|
2024-02-26 09:12:37 +00:00
|
|
|
|
err := theirMessenger.SaveChat(theirChat)
|
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
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2020-01-20 16:44:32 +00:00
|
|
|
|
ourChat := CreateOneToOneChat("our-chat", &theirMessenger.identity.PublicKey, s.m.transport)
|
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
|
|
|
|
ourChat.UnviewedMessagesCount = 1
|
|
|
|
|
// Make chat inactive
|
|
|
|
|
ourChat.Active = false
|
2021-01-11 10:32:51 +00:00
|
|
|
|
err = s.m.SaveChat(ourChat)
|
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
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
inputMessage := buildTestMessage(*theirChat)
|
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
|
|
|
|
|
|
|
|
|
sendResponse, err := theirMessenger.SendChatMessage(context.Background(), inputMessage)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
s.NoError(err)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(sendResponse.Messages(), 1)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
sentMessage := sendResponse.Messages()[0]
|
Move to protobuf for Message type (#1706)
* Use a single Message type `v1/message.go` and `message.go` are the same now, and they embed `protobuf.ChatMessage`
* Use `SendChatMessage` for sending chat messages, this is basically the old `Send` but a bit more flexible so we can send different message types (stickers,commands), and not just text.
* Remove dedup from services/shhext. Because now we process in status-protocol, dedup makes less sense, as those messages are going to be processed anyway, so removing for now, we can re-evaluate if bringing it to status-go or not.
* Change the various retrieveX method to a single one:
`RetrieveAll` will be processing those messages that it can process (Currently only `Message`), and return the rest in `RawMessages` (still transit). The format for the response is:
`Chats`: -> The chats updated by receiving the message
`Messages`: -> The messages retrieved (already matched to a chat)
`Contacts`: -> The contacts updated by the messages
`RawMessages` -> Anything else that can't be parsed, eventually as we move everything to status-protocol-go this will go away.
2019-12-05 16:25:34 +00:00
|
|
|
|
|
2020-04-22 12:58:28 +00:00
|
|
|
|
response, err := WaitOnMessengerResponse(
|
|
|
|
|
s.m,
|
2021-06-03 13:11:55 +00:00
|
|
|
|
func(r *MessengerResponse) bool { return len(r.Messages()) > 0 },
|
2020-04-22 12:58:28 +00:00
|
|
|
|
"no 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
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2021-04-07 12:57:14 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
actualChat := response.Chats()[0]
|
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
|
|
|
|
// It updates the unviewed messages count
|
|
|
|
|
s.Require().Equal(uint(2), actualChat.UnviewedMessagesCount)
|
|
|
|
|
// It updates the last message clock value
|
|
|
|
|
s.Require().Equal(sentMessage.Clock, actualChat.LastClockValue)
|
|
|
|
|
// It sets the last message
|
|
|
|
|
s.Require().NotNil(actualChat.LastMessage)
|
2021-04-07 12:57:14 +00:00
|
|
|
|
s.Require().False(actualChat.Active)
|
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
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Test receiving a message on an non-existing private chat
|
|
|
|
|
func (s *MessengerSuite) TestRetrieveTheirPrivateChatNonExisting() {
|
2023-03-08 17:47:09 +00:00
|
|
|
|
theirMessenger := s.newMessenger()
|
2023-11-27 17:01:13 +00:00
|
|
|
|
defer TearDownMessenger(&s.Suite, theirMessenger)
|
2020-01-20 16:44:32 +00:00
|
|
|
|
chat := CreateOneToOneChat("XXX", &s.privateKey.PublicKey, s.m.transport)
|
2024-02-26 09:12:37 +00:00
|
|
|
|
err := theirMessenger.SaveChat(chat)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
inputMessage := buildTestMessage(*chat)
|
2019-11-21 16:19:22 +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
|
|
|
|
sendResponse, err := theirMessenger.SendChatMessage(context.Background(), inputMessage)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
s.NoError(err)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(sendResponse.Messages(), 1)
|
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
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
sentMessage := sendResponse.Messages()[0]
|
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
|
|
|
|
|
|
|
|
|
// Wait for the message to reach its destination
|
2020-04-22 12:58:28 +00:00
|
|
|
|
response, err := WaitOnMessengerResponse(
|
|
|
|
|
s.m,
|
2021-06-03 13:11:55 +00:00
|
|
|
|
func(r *MessengerResponse) bool { return len(r.Messages()) > 0 },
|
2020-04-22 12:58:28 +00:00
|
|
|
|
"no 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
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
|
|
|
|
actualChat := response.Chats()[0]
|
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
|
|
|
|
// It updates the unviewed messages count
|
|
|
|
|
s.Require().Equal(uint(1), actualChat.UnviewedMessagesCount)
|
|
|
|
|
// It updates the last message clock value
|
|
|
|
|
s.Require().Equal(sentMessage.Clock, actualChat.LastClockValue)
|
|
|
|
|
// It sets the last message
|
|
|
|
|
s.Require().NotNil(actualChat.LastMessage)
|
2021-04-07 12:57:14 +00:00
|
|
|
|
// It does not set the chat as active
|
|
|
|
|
s.Require().False(actualChat.Active)
|
2019-11-21 16:19:22 +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
|
|
|
|
// Test receiving a message on an non-existing public chat
|
|
|
|
|
func (s *MessengerSuite) TestRetrieveTheirPublicChatNonExisting() {
|
2023-03-08 17:47:09 +00:00
|
|
|
|
theirMessenger := s.newMessenger()
|
2023-11-27 17:01:13 +00:00
|
|
|
|
defer TearDownMessenger(&s.Suite, theirMessenger)
|
2020-01-20 16:44:32 +00:00
|
|
|
|
chat := CreatePublicChat("test-chat", s.m.transport)
|
2024-02-26 09:12:37 +00:00
|
|
|
|
err := theirMessenger.SaveChat(chat)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
inputMessage := buildTestMessage(*chat)
|
2019-11-21 16:19:22 +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
|
|
|
|
sendResponse, err := theirMessenger.SendChatMessage(context.Background(), inputMessage)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
s.NoError(err)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(sendResponse.Messages(), 1)
|
2019-11-21 16:19:22 +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
|
|
|
|
// Wait for the message to reach its destination
|
|
|
|
|
time.Sleep(100 * time.Millisecond)
|
|
|
|
|
response, err := s.m.RetrieveAll()
|
2019-11-21 16:19:22 +00:00
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Equal(len(response.Messages()), 0)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Equal(len(response.Chats()), 0)
|
2019-11-21 16:19:22 +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
|
|
|
|
// Test receiving a message on an existing private group chat
|
2019-12-02 15:34:05 +00:00
|
|
|
|
func (s *MessengerSuite) TestRetrieveTheirPrivateGroupChat() {
|
|
|
|
|
var response *MessengerResponse
|
2023-03-08 17:47:09 +00:00
|
|
|
|
theirMessenger := s.newMessenger()
|
2023-11-27 17:01:13 +00:00
|
|
|
|
defer TearDownMessenger(&s.Suite, theirMessenger)
|
2024-02-26 09:12:37 +00:00
|
|
|
|
response, err := s.m.CreateGroupChatWithMembers(context.Background(), "id", []string{})
|
2019-11-21 16:19:22 +00:00
|
|
|
|
s.NoError(err)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2019-12-02 15:34:05 +00:00
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
ourChat := response.Chats()[0]
|
2019-11-21 16:19:22 +00:00
|
|
|
|
|
2019-12-02 15:34:05 +00:00
|
|
|
|
err = s.m.SaveChat(ourChat)
|
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
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
2022-08-26 09:25:54 +00:00
|
|
|
|
s.Require().NoError(makeMutualContact(s.m, &theirMessenger.identity.PublicKey))
|
|
|
|
|
|
2019-12-02 15:34:05 +00:00
|
|
|
|
members := []string{"0x" + hex.EncodeToString(crypto.FromECDSAPub(&theirMessenger.identity.PublicKey))}
|
|
|
|
|
_, err = s.m.AddMembersToGroupChat(context.Background(), ourChat.ID, members)
|
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
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
2019-12-02 15:34:05 +00:00
|
|
|
|
// Retrieve their messages so that the chat is created
|
2021-04-07 12:57:14 +00:00
|
|
|
|
response, err = WaitOnMessengerResponse(
|
2020-04-22 12:58:28 +00:00
|
|
|
|
theirMessenger,
|
2021-01-11 10:32:51 +00:00
|
|
|
|
func(r *MessengerResponse) bool { return len(r.Chats()) > 0 },
|
2020-04-22 12:58:28 +00:00
|
|
|
|
"chat invitation not received",
|
|
|
|
|
)
|
2019-12-02 15:34:05 +00:00
|
|
|
|
s.Require().NoError(err)
|
2021-04-07 12:57:14 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
|
|
|
|
s.Require().Len(response.ActivityCenterNotifications(), 1)
|
|
|
|
|
s.Require().False(response.Chats()[0].Active)
|
2019-12-02 15:34:05 +00:00
|
|
|
|
|
|
|
|
|
_, err = theirMessenger.ConfirmJoiningGroup(context.Background(), ourChat.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
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
2020-04-22 12:58:28 +00:00
|
|
|
|
// Wait for the message to reach its destination
|
|
|
|
|
_, err = WaitOnMessengerResponse(
|
|
|
|
|
s.m,
|
2021-01-11 10:32:51 +00:00
|
|
|
|
func(r *MessengerResponse) bool { return len(r.Chats()) > 0 },
|
2020-04-22 12:58:28 +00:00
|
|
|
|
"no joining group event received",
|
|
|
|
|
)
|
2019-12-02 15:34:05 +00:00
|
|
|
|
s.Require().NoError(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
|
|
|
|
inputMessage := buildTestMessage(*ourChat)
|
2019-11-21 16:19:22 +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
|
|
|
|
sendResponse, err := theirMessenger.SendChatMessage(context.Background(), inputMessage)
|
|
|
|
|
s.NoError(err)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(sendResponse.Messages(), 1)
|
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
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
sentMessage := sendResponse.Messages()[0]
|
Move to protobuf for Message type (#1706)
* Use a single Message type `v1/message.go` and `message.go` are the same now, and they embed `protobuf.ChatMessage`
* Use `SendChatMessage` for sending chat messages, this is basically the old `Send` but a bit more flexible so we can send different message types (stickers,commands), and not just text.
* Remove dedup from services/shhext. Because now we process in status-protocol, dedup makes less sense, as those messages are going to be processed anyway, so removing for now, we can re-evaluate if bringing it to status-go or not.
* Change the various retrieveX method to a single one:
`RetrieveAll` will be processing those messages that it can process (Currently only `Message`), and return the rest in `RawMessages` (still transit). The format for the response is:
`Chats`: -> The chats updated by receiving the message
`Messages`: -> The messages retrieved (already matched to a chat)
`Contacts`: -> The contacts updated by the messages
`RawMessages` -> Anything else that can't be parsed, eventually as we move everything to status-protocol-go this will go away.
2019-12-05 16:25:34 +00:00
|
|
|
|
|
2020-04-22 12:58:28 +00:00
|
|
|
|
response, err = WaitOnMessengerResponse(
|
|
|
|
|
s.m,
|
2021-06-03 13:11:55 +00:00
|
|
|
|
func(r *MessengerResponse) bool { return len(r.Messages()) > 0 },
|
2020-04-22 12:58:28 +00:00
|
|
|
|
"no 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
|
|
|
|
s.Require().NoError(err)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
|
|
|
|
actualChat := response.Chats()[0]
|
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
|
|
|
|
// It updates the unviewed messages count
|
|
|
|
|
s.Require().Equal(uint(1), actualChat.UnviewedMessagesCount)
|
|
|
|
|
// It updates the last message clock value
|
|
|
|
|
s.Require().Equal(sentMessage.Clock, actualChat.LastClockValue)
|
|
|
|
|
// It sets the last message
|
|
|
|
|
s.Require().NotNil(actualChat.LastMessage)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
}
|
|
|
|
|
|
2020-04-14 11:48:32 +00:00
|
|
|
|
// Test receiving a message on an existing private group chat
|
|
|
|
|
func (s *MessengerSuite) TestChangeNameGroupChat() {
|
|
|
|
|
var response *MessengerResponse
|
2023-03-08 17:47:09 +00:00
|
|
|
|
theirMessenger := s.newMessenger()
|
2023-11-27 17:01:13 +00:00
|
|
|
|
defer TearDownMessenger(&s.Suite, theirMessenger)
|
2024-02-26 09:12:37 +00:00
|
|
|
|
response, err := s.m.CreateGroupChatWithMembers(context.Background(), "old-name", []string{})
|
2020-04-14 11:48:32 +00:00
|
|
|
|
s.NoError(err)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2020-04-14 11:48:32 +00:00
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
ourChat := response.Chats()[0]
|
2020-04-14 11:48:32 +00:00
|
|
|
|
|
|
|
|
|
err = s.m.SaveChat(ourChat)
|
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
2022-08-26 09:25:54 +00:00
|
|
|
|
s.Require().NoError(makeMutualContact(s.m, &theirMessenger.identity.PublicKey))
|
|
|
|
|
|
2020-04-14 11:48:32 +00:00
|
|
|
|
members := []string{"0x" + hex.EncodeToString(crypto.FromECDSAPub(&theirMessenger.identity.PublicKey))}
|
|
|
|
|
_, err = s.m.AddMembersToGroupChat(context.Background(), ourChat.ID, members)
|
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
|
|
|
|
// Retrieve their messages so that the chat is created
|
2020-04-22 12:58:28 +00:00
|
|
|
|
_, err = WaitOnMessengerResponse(
|
|
|
|
|
theirMessenger,
|
2021-01-11 10:32:51 +00:00
|
|
|
|
func(r *MessengerResponse) bool { return len(r.Chats()) > 0 },
|
2020-04-22 12:58:28 +00:00
|
|
|
|
"chat invitation not received",
|
|
|
|
|
)
|
2020-04-14 11:48:32 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
_, err = theirMessenger.ConfirmJoiningGroup(context.Background(), ourChat.ID)
|
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
|
|
|
|
// Wait for join group event
|
2020-04-22 12:58:28 +00:00
|
|
|
|
_, err = WaitOnMessengerResponse(
|
|
|
|
|
s.m,
|
2021-01-11 10:32:51 +00:00
|
|
|
|
func(r *MessengerResponse) bool { return len(r.Chats()) > 0 },
|
2020-04-22 12:58:28 +00:00
|
|
|
|
"no joining group event received",
|
|
|
|
|
)
|
2020-04-14 11:48:32 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2022-02-17 15:13:10 +00:00
|
|
|
|
_, err = s.m.ChangeGroupChatName(context.Background(), ourChat.ID, newEnsName)
|
2020-04-14 11:48:32 +00:00
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
|
|
|
|
// Retrieve their messages so that the chat is created
|
2020-04-22 12:58:28 +00:00
|
|
|
|
response, err = WaitOnMessengerResponse(
|
|
|
|
|
theirMessenger,
|
2021-01-11 10:32:51 +00:00
|
|
|
|
func(r *MessengerResponse) bool { return len(r.Chats()) > 0 },
|
2020-04-22 12:58:28 +00:00
|
|
|
|
"chat invitation not received",
|
|
|
|
|
)
|
2020-04-14 11:48:32 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
|
|
|
|
actualChat := response.Chats()[0]
|
2022-02-17 15:13:10 +00:00
|
|
|
|
s.Require().Equal(newEnsName, actualChat.Name)
|
2020-04-14 11:48:32 +00:00
|
|
|
|
}
|
|
|
|
|
|
2020-04-22 12:58:28 +00:00
|
|
|
|
// Test being re-invited to a group chat
|
|
|
|
|
func (s *MessengerSuite) TestReInvitedToGroupChat() {
|
2019-12-02 15:34:05 +00:00
|
|
|
|
var response *MessengerResponse
|
2023-03-08 17:47:09 +00:00
|
|
|
|
theirMessenger := s.newMessenger()
|
2023-11-27 17:01:13 +00:00
|
|
|
|
defer TearDownMessenger(&s.Suite, theirMessenger)
|
2024-02-26 09:12:37 +00:00
|
|
|
|
response, err := s.m.CreateGroupChatWithMembers(context.Background(), "old-name", []string{})
|
2019-12-02 15:34:05 +00:00
|
|
|
|
s.NoError(err)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2019-12-02 15:34:05 +00:00
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
ourChat := response.Chats()[0]
|
2019-12-02 15:34:05 +00:00
|
|
|
|
|
|
|
|
|
err = s.m.SaveChat(ourChat)
|
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
2022-08-26 09:25:54 +00:00
|
|
|
|
s.Require().NoError(makeMutualContact(s.m, &theirMessenger.identity.PublicKey))
|
|
|
|
|
|
2019-12-02 15:34:05 +00:00
|
|
|
|
members := []string{"0x" + hex.EncodeToString(crypto.FromECDSAPub(&theirMessenger.identity.PublicKey))}
|
|
|
|
|
_, err = s.m.AddMembersToGroupChat(context.Background(), ourChat.ID, members)
|
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
|
|
|
|
// Retrieve their messages so that the chat is created
|
2021-04-07 12:57:14 +00:00
|
|
|
|
response, err = WaitOnMessengerResponse(
|
2020-04-22 12:58:28 +00:00
|
|
|
|
theirMessenger,
|
2021-01-11 10:32:51 +00:00
|
|
|
|
func(r *MessengerResponse) bool { return len(r.Chats()) > 0 },
|
2020-04-22 12:58:28 +00:00
|
|
|
|
"chat invitation not received",
|
|
|
|
|
)
|
2019-12-02 15:34:05 +00:00
|
|
|
|
s.Require().NoError(err)
|
2021-04-07 12:57:14 +00:00
|
|
|
|
s.Require().Len(response.ActivityCenterNotifications(), 1)
|
|
|
|
|
s.Require().False(response.Chats()[0].Active)
|
2019-12-02 15:34:05 +00:00
|
|
|
|
|
|
|
|
|
_, err = theirMessenger.ConfirmJoiningGroup(context.Background(), ourChat.ID)
|
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
2020-04-22 12:58:28 +00:00
|
|
|
|
// Wait for join group event
|
|
|
|
|
_, err = WaitOnMessengerResponse(
|
|
|
|
|
s.m,
|
2021-01-11 10:32:51 +00:00
|
|
|
|
func(r *MessengerResponse) bool { return len(r.Chats()) > 0 },
|
2020-04-22 12:58:28 +00:00
|
|
|
|
"no joining group event received",
|
|
|
|
|
)
|
|
|
|
|
s.Require().NoError(err)
|
2019-12-02 15:34:05 +00:00
|
|
|
|
|
2020-04-22 12:58:28 +00:00
|
|
|
|
response, err = theirMessenger.LeaveGroupChat(context.Background(), ourChat.ID, true)
|
2019-12-02 15:34:05 +00:00
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
|
|
|
|
s.Require().False(response.Chats()[0].Active)
|
2020-04-22 12:58:28 +00:00
|
|
|
|
|
2020-11-24 12:36:52 +00:00
|
|
|
|
// Retrieve messages so user is removed
|
|
|
|
|
_, err = WaitOnMessengerResponse(
|
|
|
|
|
s.m,
|
2021-01-11 10:32:51 +00:00
|
|
|
|
func(r *MessengerResponse) bool { return len(r.Chats()) > 0 && len(r.Chats()[0].Members) == 1 },
|
2020-11-24 12:36:52 +00:00
|
|
|
|
"leave group chat not received",
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2020-04-22 12:58:28 +00:00
|
|
|
|
// And we get re-invited
|
|
|
|
|
_, err = s.m.AddMembersToGroupChat(context.Background(), ourChat.ID, members)
|
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
|
|
|
|
// Retrieve their messages so that the chat is created
|
|
|
|
|
response, err = WaitOnMessengerResponse(
|
|
|
|
|
theirMessenger,
|
2021-01-11 10:32:51 +00:00
|
|
|
|
func(r *MessengerResponse) bool { return len(r.Chats()) > 0 },
|
2020-04-22 12:58:28 +00:00
|
|
|
|
"chat invitation not received",
|
|
|
|
|
)
|
2019-12-02 15:34:05 +00:00
|
|
|
|
|
|
|
|
|
s.Require().NoError(err)
|
2020-04-22 12:58:28 +00:00
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2021-04-07 12:57:14 +00:00
|
|
|
|
s.Require().False(response.Chats()[0].Active)
|
2019-12-02 15:34:05 +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
|
|
|
|
|
2019-11-21 16:19:22 +00:00
|
|
|
|
func (s *MessengerSuite) TestChatPersistencePublic() {
|
2021-01-11 10:32:51 +00:00
|
|
|
|
chat := &Chat{
|
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
|
|
|
|
ID: "chat-name",
|
|
|
|
|
Name: "chat-name",
|
|
|
|
|
Color: "#fffff",
|
|
|
|
|
Active: true,
|
|
|
|
|
ChatType: ChatTypePublic,
|
|
|
|
|
Timestamp: 10,
|
|
|
|
|
LastClockValue: 20,
|
|
|
|
|
DeletedAtClockValue: 30,
|
|
|
|
|
UnviewedMessagesCount: 40,
|
2023-08-18 11:39:59 +00:00
|
|
|
|
LastMessage: common.NewMessage(),
|
2021-10-21 17:04:56 +00:00
|
|
|
|
Highlight: false,
|
2019-11-21 16:19:22 +00:00
|
|
|
|
}
|
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().NoError(s.m.SaveChat(chat))
|
2019-12-02 15:34:05 +00:00
|
|
|
|
savedChats := s.m.Chats()
|
2023-08-03 14:16:11 +00:00
|
|
|
|
s.Require().Equal(deprecation.AddChatsCount(1), len(savedChats))
|
2019-11-21 16:19:22 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *MessengerSuite) TestDeleteChat() {
|
|
|
|
|
chatID := "chatid"
|
2021-01-11 10:32:51 +00:00
|
|
|
|
chat := &Chat{
|
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
|
|
|
|
ID: chatID,
|
|
|
|
|
Name: "chat-name",
|
|
|
|
|
Color: "#fffff",
|
|
|
|
|
Active: true,
|
|
|
|
|
ChatType: ChatTypePublic,
|
|
|
|
|
Timestamp: 10,
|
|
|
|
|
LastClockValue: 20,
|
|
|
|
|
DeletedAtClockValue: 30,
|
|
|
|
|
UnviewedMessagesCount: 40,
|
2023-08-18 11:39:59 +00:00
|
|
|
|
LastMessage: common.NewMessage(),
|
2021-10-21 17:04:56 +00:00
|
|
|
|
Highlight: false,
|
2019-11-21 16:19:22 +00:00
|
|
|
|
}
|
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().NoError(s.m.SaveChat(chat))
|
2019-12-02 15:34:05 +00:00
|
|
|
|
savedChats := s.m.Chats()
|
2023-08-03 14:16:11 +00:00
|
|
|
|
s.Require().Equal(deprecation.AddChatsCount(1), len(savedChats))
|
2019-11-21 16:19:22 +00:00
|
|
|
|
|
|
|
|
|
s.Require().NoError(s.m.DeleteChat(chatID))
|
2019-12-02 15:34:05 +00:00
|
|
|
|
savedChats = s.m.Chats()
|
2023-08-03 14:16:11 +00:00
|
|
|
|
s.Require().Equal(deprecation.AddChatsCount(0), len(savedChats))
|
2019-11-21 16:19:22 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *MessengerSuite) TestChatPersistenceUpdate() {
|
2021-01-11 10:32:51 +00:00
|
|
|
|
chat := &Chat{
|
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
|
|
|
|
ID: "chat-name",
|
|
|
|
|
Name: "chat-name",
|
|
|
|
|
Color: "#fffff",
|
|
|
|
|
Active: true,
|
|
|
|
|
ChatType: ChatTypePublic,
|
|
|
|
|
Timestamp: 10,
|
|
|
|
|
LastClockValue: 20,
|
|
|
|
|
DeletedAtClockValue: 30,
|
|
|
|
|
UnviewedMessagesCount: 40,
|
2023-08-18 11:39:59 +00:00
|
|
|
|
LastMessage: common.NewMessage(),
|
2021-10-21 17:04:56 +00:00
|
|
|
|
Highlight: false,
|
2019-11-21 16:19:22 +00:00
|
|
|
|
}
|
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().NoError(s.m.SaveChat(chat))
|
2019-12-02 15:34:05 +00:00
|
|
|
|
savedChats := s.m.Chats()
|
2023-08-03 14:16:11 +00:00
|
|
|
|
s.Require().Equal(deprecation.AddChatsCount(1), len(savedChats))
|
2019-11-21 16:19:22 +00:00
|
|
|
|
|
2021-05-14 10:55:42 +00:00
|
|
|
|
var actualChat *Chat
|
|
|
|
|
for idx := range savedChats {
|
|
|
|
|
if savedChats[idx].ID == chat.ID {
|
|
|
|
|
actualChat = chat
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-11-21 16:19:22 +00:00
|
|
|
|
|
2021-05-14 10:55:42 +00:00
|
|
|
|
s.Require().NotNil(actualChat)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Equal(chat, actualChat)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
|
2020-02-21 14:48:53 +00:00
|
|
|
|
chat.Name = "updated-name-1"
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().NoError(s.m.SaveChat(chat))
|
2021-05-14 10:55:42 +00:00
|
|
|
|
|
|
|
|
|
var actualUpdatedChat *Chat
|
2019-12-02 15:34:05 +00:00
|
|
|
|
updatedChats := s.m.Chats()
|
2019-11-21 16:19:22 +00:00
|
|
|
|
|
2021-05-14 10:55:42 +00:00
|
|
|
|
for idx := range updatedChats {
|
|
|
|
|
if updatedChats[idx].ID == chat.ID {
|
|
|
|
|
actualUpdatedChat = chat
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-11-21 16:19:22 +00:00
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Equal(chat, actualUpdatedChat)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *MessengerSuite) TestChatPersistenceOneToOne() {
|
2021-01-11 10:32:51 +00:00
|
|
|
|
chat := &Chat{
|
2020-02-21 14:48:53 +00:00
|
|
|
|
ID: testPK,
|
|
|
|
|
Name: testPK,
|
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
|
|
|
|
Color: "#fffff",
|
|
|
|
|
Active: true,
|
|
|
|
|
ChatType: ChatTypeOneToOne,
|
|
|
|
|
Timestamp: 10,
|
|
|
|
|
LastClockValue: 20,
|
|
|
|
|
DeletedAtClockValue: 30,
|
|
|
|
|
UnviewedMessagesCount: 40,
|
2023-08-18 11:39:59 +00:00
|
|
|
|
LastMessage: common.NewMessage(),
|
2021-10-21 17:04:56 +00:00
|
|
|
|
Highlight: false,
|
2019-11-21 16:19:22 +00:00
|
|
|
|
}
|
2020-05-20 12:16:12 +00:00
|
|
|
|
|
2020-02-21 14:48:53 +00:00
|
|
|
|
publicKeyBytes, err := hex.DecodeString(testPK[2:])
|
2019-11-21 16:19:22 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
pk, err := crypto.UnmarshalPubkey(publicKeyBytes)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().NoError(s.m.SaveChat(chat))
|
2019-12-02 15:34:05 +00:00
|
|
|
|
savedChats := s.m.Chats()
|
2023-08-03 14:16:11 +00:00
|
|
|
|
s.Require().Equal(deprecation.AddChatsCount(1), len(savedChats))
|
2021-05-14 10:55:42 +00:00
|
|
|
|
|
|
|
|
|
var actualChat *Chat
|
|
|
|
|
for idx := range savedChats {
|
|
|
|
|
if chat.ID == savedChats[idx].ID {
|
|
|
|
|
actualChat = savedChats[idx]
|
|
|
|
|
}
|
2019-11-21 16:19:22 +00:00
|
|
|
|
|
2021-05-14 10:55:42 +00:00
|
|
|
|
}
|
2019-12-02 15:34:05 +00:00
|
|
|
|
|
|
|
|
|
actualPk, err := actualChat.PublicKey()
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
s.Require().Equal(pk, actualPk)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Equal(chat, actualChat)
|
2020-05-20 12:16:12 +00:00
|
|
|
|
s.Require().NotEmpty(actualChat.Identicon)
|
|
|
|
|
s.Require().NotEmpty(actualChat.Alias)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *MessengerSuite) TestChatPersistencePrivateGroupChat() {
|
2020-01-15 07:25:09 +00:00
|
|
|
|
|
|
|
|
|
member1Key, err := crypto.GenerateKey()
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
member1ID := types.EncodeHex(crypto.FromECDSAPub(&member1Key.PublicKey))
|
|
|
|
|
|
|
|
|
|
member2Key, err := crypto.GenerateKey()
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
member2ID := types.EncodeHex(crypto.FromECDSAPub(&member2Key.PublicKey))
|
|
|
|
|
|
|
|
|
|
member3Key, err := crypto.GenerateKey()
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
member3ID := types.EncodeHex(crypto.FromECDSAPub(&member3Key.PublicKey))
|
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
chat := &Chat{
|
2019-11-21 16:19:22 +00:00
|
|
|
|
ID: "chat-id",
|
|
|
|
|
Name: "chat-id",
|
|
|
|
|
Color: "#fffff",
|
|
|
|
|
Active: true,
|
|
|
|
|
ChatType: ChatTypePrivateGroupChat,
|
|
|
|
|
Timestamp: 10,
|
|
|
|
|
Members: []ChatMember{
|
2019-12-19 15:40:44 +00:00
|
|
|
|
{
|
2022-05-20 10:53:28 +00:00
|
|
|
|
ID: member1ID,
|
|
|
|
|
Admin: false,
|
2019-11-21 16:19:22 +00:00
|
|
|
|
},
|
2019-12-19 15:40:44 +00:00
|
|
|
|
{
|
2022-05-20 10:53:28 +00:00
|
|
|
|
ID: member2ID,
|
|
|
|
|
Admin: true,
|
2019-11-21 16:19:22 +00:00
|
|
|
|
},
|
2019-12-19 15:40:44 +00:00
|
|
|
|
{
|
2022-05-20 10:53:28 +00:00
|
|
|
|
ID: member3ID,
|
|
|
|
|
Admin: true,
|
2019-11-21 16:19:22 +00:00
|
|
|
|
},
|
|
|
|
|
},
|
2019-12-02 15:34:05 +00:00
|
|
|
|
MembershipUpdates: []v1protocol.MembershipUpdateEvent{
|
|
|
|
|
{
|
|
|
|
|
Type: protobuf.MembershipUpdateEvent_CHAT_CREATED,
|
2019-11-21 16:19:22 +00:00
|
|
|
|
Name: "name-1",
|
|
|
|
|
ClockValue: 1,
|
2019-12-02 15:34:05 +00:00
|
|
|
|
Signature: []byte("signature-1"),
|
2019-11-21 16:19:22 +00:00
|
|
|
|
From: "from-1",
|
|
|
|
|
Members: []string{"member-1", "member-2"},
|
|
|
|
|
},
|
2019-12-02 15:34:05 +00:00
|
|
|
|
{
|
|
|
|
|
Type: protobuf.MembershipUpdateEvent_MEMBERS_ADDED,
|
2019-11-21 16:19:22 +00:00
|
|
|
|
Name: "name-2",
|
|
|
|
|
ClockValue: 2,
|
2019-12-02 15:34:05 +00:00
|
|
|
|
Signature: []byte("signature-2"),
|
2019-11-21 16:19:22 +00:00
|
|
|
|
From: "from-2",
|
|
|
|
|
Members: []string{"member-2", "member-3"},
|
|
|
|
|
},
|
|
|
|
|
},
|
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
|
|
|
|
LastClockValue: 20,
|
|
|
|
|
DeletedAtClockValue: 30,
|
|
|
|
|
UnviewedMessagesCount: 40,
|
2023-08-18 11:39:59 +00:00
|
|
|
|
LastMessage: common.NewMessage(),
|
2021-10-21 17:04:56 +00:00
|
|
|
|
Highlight: false,
|
2019-11-21 16:19:22 +00:00
|
|
|
|
}
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().NoError(s.m.SaveChat(chat))
|
2019-12-02 15:34:05 +00:00
|
|
|
|
savedChats := s.m.Chats()
|
2023-08-03 14:16:11 +00:00
|
|
|
|
s.Require().Equal(deprecation.AddChatsCount(1), len(savedChats))
|
2021-05-14 10:55:42 +00:00
|
|
|
|
|
|
|
|
|
var actualChat *Chat
|
|
|
|
|
for idx := range savedChats {
|
|
|
|
|
if savedChats[idx].ID == chat.ID {
|
|
|
|
|
actualChat = savedChats[idx]
|
|
|
|
|
}
|
2019-11-21 16:19:22 +00:00
|
|
|
|
|
2021-05-14 10:55:42 +00:00
|
|
|
|
}
|
2019-11-21 16:19:22 +00:00
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Equal(chat, actualChat)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *MessengerSuite) TestBlockContact() {
|
|
|
|
|
contact := Contact{
|
2023-01-20 14:28:30 +00:00
|
|
|
|
ID: testPK,
|
|
|
|
|
EnsName: "contact-name",
|
|
|
|
|
LastUpdated: 20,
|
|
|
|
|
ContactRequestLocalState: ContactRequestStateSent,
|
2019-11-21 16:19:22 +00:00
|
|
|
|
}
|
|
|
|
|
|
2023-01-20 18:51:36 +00:00
|
|
|
|
key2, err := crypto.GenerateKey()
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
contact2 := Contact{
|
2023-01-20 14:28:30 +00:00
|
|
|
|
ID: common.PubkeyToHex(&key2.PublicKey),
|
|
|
|
|
EnsName: "contact-name",
|
|
|
|
|
LastUpdated: 20,
|
|
|
|
|
ContactRequestLocalState: ContactRequestStateSent,
|
2023-01-20 18:51:36 +00:00
|
|
|
|
}
|
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
chat1 := &Chat{
|
2019-11-21 16:19:22 +00:00
|
|
|
|
ID: contact.ID,
|
|
|
|
|
Name: "chat-name",
|
|
|
|
|
Color: "#fffff",
|
|
|
|
|
Active: true,
|
|
|
|
|
ChatType: ChatTypeOneToOne,
|
|
|
|
|
Timestamp: 1,
|
|
|
|
|
LastClockValue: 20,
|
|
|
|
|
DeletedAtClockValue: 30,
|
|
|
|
|
UnviewedMessagesCount: 40,
|
2021-10-21 17:04:56 +00:00
|
|
|
|
Highlight: false,
|
2019-11-21 16:19:22 +00:00
|
|
|
|
}
|
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
chat2 := &Chat{
|
2019-11-21 16:19:22 +00:00
|
|
|
|
ID: "chat-2",
|
|
|
|
|
Name: "chat-name",
|
|
|
|
|
Color: "#fffff",
|
|
|
|
|
Active: true,
|
|
|
|
|
ChatType: ChatTypePublic,
|
|
|
|
|
Timestamp: 2,
|
|
|
|
|
LastClockValue: 20,
|
|
|
|
|
DeletedAtClockValue: 30,
|
|
|
|
|
UnviewedMessagesCount: 40,
|
2021-10-21 17:04:56 +00:00
|
|
|
|
Highlight: false,
|
2019-11-21 16:19:22 +00:00
|
|
|
|
}
|
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
chat3 := &Chat{
|
2019-11-21 16:19:22 +00:00
|
|
|
|
ID: "chat-3",
|
|
|
|
|
Name: "chat-name",
|
|
|
|
|
Color: "#fffff",
|
|
|
|
|
Active: true,
|
|
|
|
|
ChatType: ChatTypePublic,
|
|
|
|
|
Timestamp: 3,
|
|
|
|
|
LastClockValue: 20,
|
|
|
|
|
DeletedAtClockValue: 30,
|
|
|
|
|
UnviewedMessagesCount: 40,
|
2021-10-21 17:04:56 +00:00
|
|
|
|
Highlight: false,
|
2019-11-21 16:19:22 +00:00
|
|
|
|
}
|
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().NoError(s.m.SaveChat(chat1))
|
|
|
|
|
s.Require().NoError(s.m.SaveChat(chat2))
|
|
|
|
|
s.Require().NoError(s.m.SaveChat(chat3))
|
2019-11-21 16:19:22 +00:00
|
|
|
|
|
2022-10-14 08:50:36 +00:00
|
|
|
|
_, err = s.m.AddContact(context.Background(), &requests.AddContact{ID: contact.ID})
|
2021-10-22 14:20:42 +00:00
|
|
|
|
s.Require().NoError(err)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
|
2020-09-01 13:27:01 +00:00
|
|
|
|
messages := []*common.Message{
|
2019-12-19 15:40:44 +00:00
|
|
|
|
{
|
2019-11-21 16:19:22 +00:00
|
|
|
|
ID: "test-1",
|
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
|
|
|
|
LocalChatID: chat2.ID,
|
2023-08-18 11:39:59 +00:00
|
|
|
|
ChatMessage: &protobuf.ChatMessage{
|
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
|
|
|
|
ContentType: 1,
|
|
|
|
|
Text: "test-1",
|
|
|
|
|
Clock: 1,
|
|
|
|
|
},
|
|
|
|
|
From: contact.ID,
|
2019-11-21 16:19:22 +00:00
|
|
|
|
},
|
2019-12-19 15:40:44 +00:00
|
|
|
|
{
|
2019-11-21 16:19:22 +00:00
|
|
|
|
ID: "test-2",
|
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
|
|
|
|
LocalChatID: chat2.ID,
|
2023-08-18 11:39:59 +00:00
|
|
|
|
ChatMessage: &protobuf.ChatMessage{
|
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
|
|
|
|
ContentType: 2,
|
|
|
|
|
Text: "test-2",
|
|
|
|
|
Clock: 2,
|
|
|
|
|
},
|
|
|
|
|
From: contact.ID,
|
2019-11-21 16:19:22 +00:00
|
|
|
|
},
|
2019-12-19 15:40:44 +00:00
|
|
|
|
{
|
2019-11-21 16:19:22 +00:00
|
|
|
|
ID: "test-3",
|
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
|
|
|
|
LocalChatID: chat2.ID,
|
2023-08-18 11:39:59 +00:00
|
|
|
|
ChatMessage: &protobuf.ChatMessage{
|
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
|
|
|
|
ContentType: 3,
|
|
|
|
|
Text: "test-3",
|
|
|
|
|
Clock: 3,
|
|
|
|
|
},
|
|
|
|
|
Seen: false,
|
2023-01-20 18:51:36 +00:00
|
|
|
|
From: contact2.ID,
|
2019-11-21 16:19:22 +00:00
|
|
|
|
},
|
2019-12-19 15:40:44 +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
|
|
|
|
ID: "test-4",
|
|
|
|
|
LocalChatID: chat2.ID,
|
2023-08-18 11:39:59 +00:00
|
|
|
|
ChatMessage: &protobuf.ChatMessage{
|
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
|
|
|
|
ContentType: 4,
|
|
|
|
|
Text: "test-4",
|
|
|
|
|
Clock: 4,
|
|
|
|
|
},
|
|
|
|
|
Seen: false,
|
2023-01-20 18:51:36 +00:00
|
|
|
|
From: contact2.ID,
|
2019-11-21 16:19:22 +00:00
|
|
|
|
},
|
2019-12-19 15:40:44 +00:00
|
|
|
|
{
|
2019-11-21 16:19:22 +00:00
|
|
|
|
ID: "test-5",
|
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
|
|
|
|
LocalChatID: chat2.ID,
|
2023-08-18 11:39:59 +00:00
|
|
|
|
ChatMessage: &protobuf.ChatMessage{
|
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
|
|
|
|
ContentType: 5,
|
|
|
|
|
Text: "test-5",
|
|
|
|
|
Clock: 5,
|
|
|
|
|
},
|
|
|
|
|
Seen: true,
|
2023-01-20 18:51:36 +00:00
|
|
|
|
From: contact2.ID,
|
2019-11-21 16:19:22 +00:00
|
|
|
|
},
|
2019-12-19 15:40:44 +00:00
|
|
|
|
{
|
2019-11-21 16:19:22 +00:00
|
|
|
|
ID: "test-6",
|
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
|
|
|
|
LocalChatID: chat3.ID,
|
2023-08-18 11:39:59 +00:00
|
|
|
|
ChatMessage: &protobuf.ChatMessage{
|
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
|
|
|
|
ContentType: 6,
|
|
|
|
|
Text: "test-6",
|
|
|
|
|
Clock: 6,
|
|
|
|
|
},
|
|
|
|
|
Seen: false,
|
|
|
|
|
From: contact.ID,
|
2019-11-21 16:19:22 +00:00
|
|
|
|
},
|
2019-12-19 15:40:44 +00:00
|
|
|
|
{
|
2019-11-21 16:19:22 +00:00
|
|
|
|
ID: "test-7",
|
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
|
|
|
|
LocalChatID: chat3.ID,
|
2023-08-18 11:39:59 +00:00
|
|
|
|
ChatMessage: &protobuf.ChatMessage{
|
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
|
|
|
|
ContentType: 7,
|
|
|
|
|
Text: "test-7",
|
|
|
|
|
Clock: 7,
|
|
|
|
|
},
|
|
|
|
|
Seen: false,
|
2023-01-20 18:51:36 +00:00
|
|
|
|
From: contact2.ID,
|
2019-11-21 16:19:22 +00:00
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
|
2021-10-22 14:20:42 +00:00
|
|
|
|
err = s.m.SaveMessages(messages)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2023-10-22 09:41:20 +00:00
|
|
|
|
response, err := s.m.BlockContact(context.Background(), contact.ID, false)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2023-04-20 10:52:08 +00:00
|
|
|
|
blockedContacts := s.m.BlockedContacts()
|
|
|
|
|
s.Require().True(blockedContacts[0].Removed)
|
|
|
|
|
|
2023-01-20 18:51:36 +00:00
|
|
|
|
chats := response.Chats()
|
|
|
|
|
|
2021-05-14 10:55:42 +00:00
|
|
|
|
var actualChat2, actualChat3 *Chat
|
2021-12-06 12:44:40 +00:00
|
|
|
|
for idx := range chats {
|
|
|
|
|
if chats[idx].ID == chat2.ID {
|
|
|
|
|
actualChat2 = chats[idx]
|
|
|
|
|
} else if chats[idx].ID == chat3.ID {
|
|
|
|
|
actualChat3 = chats[idx]
|
2021-05-14 10:55:42 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
2019-11-21 16:19:22 +00:00
|
|
|
|
// The new unviewed count is updated
|
2021-05-14 10:55:42 +00:00
|
|
|
|
s.Require().Equal(uint(1), actualChat3.UnviewedMessagesCount)
|
|
|
|
|
s.Require().Equal(uint(2), actualChat2.UnviewedMessagesCount)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
|
|
|
|
|
// The new message content is updated
|
2021-05-14 10:55:42 +00:00
|
|
|
|
s.Require().NotNil(actualChat3.LastMessage)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
|
2021-05-14 10:55:42 +00:00
|
|
|
|
s.Require().Equal("test-7", actualChat3.LastMessage.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
|
|
|
|
|
2021-05-14 10:55:42 +00:00
|
|
|
|
s.Require().NotNil(actualChat2.LastMessage)
|
|
|
|
|
s.Require().Equal("test-5", actualChat2.LastMessage.ID)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
|
|
|
|
|
// The contact is updated
|
2019-12-02 15:34:05 +00:00
|
|
|
|
savedContacts := s.m.Contacts()
|
2019-11-21 16:19:22 +00:00
|
|
|
|
s.Require().Equal(1, len(savedContacts))
|
|
|
|
|
|
|
|
|
|
// The chat is deleted
|
2019-12-02 15:34:05 +00:00
|
|
|
|
actualChats := s.m.Chats()
|
2023-08-04 10:41:24 +00:00
|
|
|
|
s.Require().Equal(deprecation.AddChatsCount(3), len(actualChats))
|
2019-11-21 16:19:22 +00:00
|
|
|
|
|
|
|
|
|
// The messages have been deleted
|
|
|
|
|
chat2Messages, _, err := s.m.MessageByChatID(chat2.ID, "", 20)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
s.Require().Equal(3, len(chat2Messages))
|
|
|
|
|
|
|
|
|
|
chat3Messages, _, err := s.m.MessageByChatID(chat3.ID, "", 20)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
s.Require().Equal(1, len(chat3Messages))
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *MessengerSuite) TestContactPersistence() {
|
2022-10-14 08:50:36 +00:00
|
|
|
|
_, err := s.m.AddContact(context.Background(), &requests.AddContact{ID: testPK})
|
2021-10-22 14:20:42 +00:00
|
|
|
|
s.Require().NoError(err)
|
2019-12-02 15:34:05 +00:00
|
|
|
|
savedContacts := s.m.Contacts()
|
2019-11-21 16:19:22 +00:00
|
|
|
|
|
|
|
|
|
s.Require().Equal(1, len(savedContacts))
|
|
|
|
|
|
2023-01-20 14:28:30 +00:00
|
|
|
|
s.Require().True(savedContacts[0].added())
|
2019-11-21 16:19:22 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *MessengerSuite) TestSharedSecretHandler() {
|
2020-07-31 12:22:05 +00:00
|
|
|
|
err := s.m.handleSharedSecrets(nil)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
s.NoError(err)
|
|
|
|
|
}
|
|
|
|
|
|
2019-12-02 15:34:05 +00:00
|
|
|
|
func (s *MessengerSuite) TestCreateGroupChatWithMembers() {
|
2020-02-21 14:48:53 +00:00
|
|
|
|
members := []string{testPK}
|
2022-08-26 09:25:54 +00:00
|
|
|
|
|
|
|
|
|
pubKey, err := common.HexToPubkey(testPK)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
s.Require().NoError(makeMutualContact(s.m, pubKey))
|
|
|
|
|
|
2019-12-02 15:34:05 +00:00
|
|
|
|
response, err := s.m.CreateGroupChatWithMembers(context.Background(), "test", members)
|
|
|
|
|
s.NoError(err)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2019-12-02 15:34:05 +00:00
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
chat := response.Chats()[0]
|
2019-12-02 15:34:05 +00:00
|
|
|
|
|
2019-11-23 17:57:05 +00:00
|
|
|
|
s.Require().Equal("test", chat.Name)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
publicKeyHex := "0x" + hex.EncodeToString(crypto.FromECDSAPub(&s.m.identity.PublicKey))
|
2019-11-23 17:57:05 +00:00
|
|
|
|
s.Require().Contains(chat.ID, publicKeyHex)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
s.EqualValues([]string{publicKeyHex}, []string{chat.Members[0].ID})
|
2019-12-02 15:34:05 +00:00
|
|
|
|
s.Equal(members[0], chat.Members[1].ID)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *MessengerSuite) TestAddMembersToChat() {
|
2019-12-02 15:34:05 +00:00
|
|
|
|
response, err := s.m.CreateGroupChatWithMembers(context.Background(), "test", []string{})
|
2019-11-23 17:57:05 +00:00
|
|
|
|
s.Require().NoError(err)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2019-12-02 15:34:05 +00:00
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
chat := response.Chats()[0]
|
2019-12-02 15:34:05 +00:00
|
|
|
|
|
2019-11-21 16:19:22 +00:00
|
|
|
|
key, err := crypto.GenerateKey()
|
2019-11-23 17:57:05 +00:00
|
|
|
|
s.Require().NoError(err)
|
2019-12-02 15:34:05 +00:00
|
|
|
|
members := []string{"0x" + hex.EncodeToString(crypto.FromECDSAPub(&key.PublicKey))}
|
|
|
|
|
|
2022-08-26 09:25:54 +00:00
|
|
|
|
s.Require().NoError(makeMutualContact(s.m, &key.PublicKey))
|
|
|
|
|
|
2019-12-02 15:34:05 +00:00
|
|
|
|
response, err = s.m.AddMembersToGroupChat(context.Background(), chat.ID, members)
|
2019-11-23 17:57:05 +00:00
|
|
|
|
s.Require().NoError(err)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(response.Messages(), 1)
|
2019-12-02 15:34:05 +00:00
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
chat = response.Chats()[0]
|
2019-12-02 15:34:05 +00:00
|
|
|
|
|
2019-11-21 16:19:22 +00:00
|
|
|
|
publicKeyHex := "0x" + hex.EncodeToString(crypto.FromECDSAPub(&s.m.identity.PublicKey))
|
|
|
|
|
keyHex := "0x" + hex.EncodeToString(crypto.FromECDSAPub(&key.PublicKey))
|
|
|
|
|
s.EqualValues([]string{publicKeyHex, keyHex}, []string{chat.Members[0].ID, chat.Members[1].ID})
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-10 18:59:01 +00:00
|
|
|
|
func (s *MessengerSuite) TestDeclineRequestAddressForTransaction() {
|
2020-02-21 14:48:53 +00:00
|
|
|
|
value := testValue
|
|
|
|
|
contract := testContract
|
2023-03-08 17:47:09 +00:00
|
|
|
|
theirMessenger := s.newMessenger()
|
2023-11-27 17:01:13 +00:00
|
|
|
|
defer TearDownMessenger(&s.Suite, theirMessenger)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
theirPkString := types.EncodeHex(crypto.FromECDSAPub(&theirMessenger.identity.PublicKey))
|
2021-07-07 11:18:18 +00:00
|
|
|
|
myPkString := types.EncodeHex(crypto.FromECDSAPub(&s.m.identity.PublicKey))
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
2020-01-20 16:44:32 +00:00
|
|
|
|
chat := CreateOneToOneChat(theirPkString, &theirMessenger.identity.PublicKey, s.m.transport)
|
2024-02-26 09:12:37 +00:00
|
|
|
|
err := s.m.SaveChat(chat)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
myAddress := crypto.PubkeyToAddress(s.m.identity.PublicKey)
|
|
|
|
|
|
|
|
|
|
response, err := s.m.RequestAddressForTransaction(context.Background(), theirPkString, myAddress.Hex(), value, contract)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
s.Require().NotNil(response)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(response.Messages(), 1)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
senderMessage := response.Messages()[0]
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(protobuf.ChatMessage_TRANSACTION_COMMAND, senderMessage.ContentType)
|
|
|
|
|
initialCommandID := senderMessage.ID
|
|
|
|
|
|
|
|
|
|
s.Require().Equal("Request address for transaction", senderMessage.Text)
|
|
|
|
|
s.Require().NotNil(senderMessage.CommandParameters)
|
|
|
|
|
s.Require().Equal(value, senderMessage.CommandParameters.Value)
|
|
|
|
|
s.Require().Equal(contract, senderMessage.CommandParameters.Contract)
|
|
|
|
|
s.Require().Equal(initialCommandID, senderMessage.CommandParameters.ID)
|
2020-09-01 13:27:01 +00:00
|
|
|
|
s.Require().Equal(common.CommandStateRequestAddressForTransaction, senderMessage.CommandParameters.CommandState)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
|
|
|
|
// Wait for the message to reach its destination
|
2020-04-22 12:58:28 +00:00
|
|
|
|
response, err = WaitOnMessengerResponse(
|
|
|
|
|
theirMessenger,
|
2021-06-03 13:11:55 +00:00
|
|
|
|
func(r *MessengerResponse) bool { return len(r.Messages()) > 0 },
|
2020-04-22 12:58:28 +00:00
|
|
|
|
"no messages",
|
|
|
|
|
)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
s.Require().NotNil(response)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(response.Messages(), 1)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
receiverMessage := response.Messages()[0]
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(protobuf.ChatMessage_TRANSACTION_COMMAND, receiverMessage.ContentType)
|
|
|
|
|
s.Require().Equal("Request address for transaction", receiverMessage.Text)
|
|
|
|
|
s.Require().NotNil(receiverMessage.CommandParameters)
|
|
|
|
|
s.Require().Equal(value, receiverMessage.CommandParameters.Value)
|
|
|
|
|
s.Require().Equal(contract, receiverMessage.CommandParameters.Contract)
|
|
|
|
|
s.Require().Equal(initialCommandID, receiverMessage.CommandParameters.ID)
|
2021-07-07 11:18:18 +00:00
|
|
|
|
s.Require().Equal(theirPkString, receiverMessage.ChatId)
|
2020-09-01 13:27:01 +00:00
|
|
|
|
s.Require().Equal(common.CommandStateRequestAddressForTransaction, receiverMessage.CommandParameters.CommandState)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
|
|
|
|
// We decline the request
|
|
|
|
|
response, err = theirMessenger.DeclineRequestAddressForTransaction(context.Background(), receiverMessage.ID)
|
2020-02-10 11:22:37 +00:00
|
|
|
|
s.Require().NoError(err)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(response.Messages(), 1)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
senderMessage = response.Messages()[0]
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(protobuf.ChatMessage_TRANSACTION_COMMAND, senderMessage.ContentType)
|
|
|
|
|
s.Require().Equal("Request address for transaction declined", senderMessage.Text)
|
|
|
|
|
s.Require().NotNil(senderMessage.CommandParameters)
|
|
|
|
|
s.Require().Equal(value, senderMessage.CommandParameters.Value)
|
|
|
|
|
s.Require().Equal(contract, senderMessage.CommandParameters.Contract)
|
2020-09-01 13:27:01 +00:00
|
|
|
|
s.Require().Equal(common.CommandStateRequestAddressForTransactionDeclined, senderMessage.CommandParameters.CommandState)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(initialCommandID, senderMessage.CommandParameters.ID)
|
|
|
|
|
s.Require().Equal(receiverMessage.ID, senderMessage.Replace)
|
|
|
|
|
|
|
|
|
|
// Wait for the message to reach its destination
|
2020-04-22 12:58:28 +00:00
|
|
|
|
response, err = WaitOnMessengerResponse(
|
|
|
|
|
s.m,
|
2021-06-03 13:11:55 +00:00
|
|
|
|
func(r *MessengerResponse) bool { return len(r.Messages()) > 0 },
|
2020-04-22 12:58:28 +00:00
|
|
|
|
"no messages",
|
|
|
|
|
)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(response.Messages(), 1)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
receiverMessage = response.Messages()[0]
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(protobuf.ChatMessage_TRANSACTION_COMMAND, receiverMessage.ContentType)
|
|
|
|
|
s.Require().Equal("Request address for transaction declined", receiverMessage.Text)
|
|
|
|
|
s.Require().NotNil(receiverMessage.CommandParameters)
|
|
|
|
|
s.Require().Equal(value, receiverMessage.CommandParameters.Value)
|
|
|
|
|
s.Require().Equal(contract, receiverMessage.CommandParameters.Contract)
|
2020-09-01 13:27:01 +00:00
|
|
|
|
s.Require().Equal(common.CommandStateRequestAddressForTransactionDeclined, receiverMessage.CommandParameters.CommandState)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(initialCommandID, receiverMessage.CommandParameters.ID)
|
2021-07-07 11:18:18 +00:00
|
|
|
|
s.Require().Equal(myPkString, receiverMessage.ChatId)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(initialCommandID, receiverMessage.Replace)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *MessengerSuite) TestSendEthTransaction() {
|
2020-02-21 14:48:53 +00:00
|
|
|
|
value := testValue
|
|
|
|
|
contract := testContract
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
2023-03-08 17:47:09 +00:00
|
|
|
|
theirMessenger := s.newMessenger()
|
2023-11-27 17:01:13 +00:00
|
|
|
|
defer TearDownMessenger(&s.Suite, theirMessenger)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
theirPkString := types.EncodeHex(crypto.FromECDSAPub(&theirMessenger.identity.PublicKey))
|
|
|
|
|
|
|
|
|
|
receiverAddress := crypto.PubkeyToAddress(theirMessenger.identity.PublicKey)
|
|
|
|
|
receiverAddressString := strings.ToLower(receiverAddress.Hex())
|
|
|
|
|
|
2020-01-20 16:44:32 +00:00
|
|
|
|
chat := CreateOneToOneChat(theirPkString, &theirMessenger.identity.PublicKey, s.m.transport)
|
2024-02-26 09:12:37 +00:00
|
|
|
|
err := s.m.SaveChat(chat)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2020-02-21 14:48:53 +00:00
|
|
|
|
transactionHash := testTransactionHash
|
2020-01-10 18:59:01 +00:00
|
|
|
|
signature, err := buildSignature(s.m.identity, &s.m.identity.PublicKey, transactionHash)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2020-01-15 07:25:09 +00:00
|
|
|
|
response, err := s.m.SendTransaction(context.Background(), theirPkString, value, contract, transactionHash, signature)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
s.Require().NotNil(response)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(response.Messages(), 1)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
senderMessage := response.Messages()[0]
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(protobuf.ChatMessage_TRANSACTION_COMMAND, senderMessage.ContentType)
|
|
|
|
|
s.Require().Equal("Transaction sent", senderMessage.Text)
|
|
|
|
|
s.Require().NotNil(senderMessage.CommandParameters)
|
|
|
|
|
s.Require().Equal(transactionHash, senderMessage.CommandParameters.TransactionHash)
|
2020-01-15 07:25:09 +00:00
|
|
|
|
s.Require().Equal(contract, senderMessage.CommandParameters.Contract)
|
|
|
|
|
s.Require().Equal(value, senderMessage.CommandParameters.Value)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(signature, senderMessage.CommandParameters.Signature)
|
2020-09-01 13:27:01 +00:00
|
|
|
|
s.Require().Equal(common.CommandStateTransactionSent, senderMessage.CommandParameters.CommandState)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().NotEmpty(senderMessage.ID)
|
|
|
|
|
s.Require().Equal("", senderMessage.Replace)
|
|
|
|
|
|
|
|
|
|
var transactions []*TransactionToValidate
|
|
|
|
|
// Wait for the message to reach its destination
|
|
|
|
|
err = tt.RetryWithBackOff(func() error {
|
|
|
|
|
var err error
|
|
|
|
|
|
|
|
|
|
_, err = theirMessenger.RetrieveAll()
|
|
|
|
|
if err != nil {
|
|
|
|
|
return err
|
|
|
|
|
}
|
|
|
|
|
transactions, err = theirMessenger.persistence.TransactionsToValidate()
|
|
|
|
|
if err == nil && len(transactions) == 0 {
|
|
|
|
|
err = errors.New("no transactions")
|
|
|
|
|
}
|
|
|
|
|
return err
|
|
|
|
|
})
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
actualTransaction := transactions[0]
|
|
|
|
|
|
|
|
|
|
s.Require().Equal(&s.m.identity.PublicKey, actualTransaction.From)
|
|
|
|
|
s.Require().Equal(transactionHash, actualTransaction.TransactionHash)
|
|
|
|
|
s.Require().True(actualTransaction.Validate)
|
|
|
|
|
|
|
|
|
|
senderAddress := crypto.PubkeyToAddress(s.m.identity.PublicKey)
|
|
|
|
|
|
|
|
|
|
client := MockEthClient{}
|
|
|
|
|
valueBig, ok := big.NewInt(0).SetString(value, 10)
|
|
|
|
|
s.Require().True(ok)
|
|
|
|
|
client.messages = make(map[string]MockTransaction)
|
|
|
|
|
client.messages[transactionHash] = MockTransaction{
|
2020-01-17 12:39:09 +00:00
|
|
|
|
Status: coretypes.TransactionStatusSuccess,
|
2020-01-10 18:59:01 +00:00
|
|
|
|
Message: coretypes.NewMessage(
|
|
|
|
|
senderAddress,
|
|
|
|
|
&receiverAddress,
|
|
|
|
|
1,
|
|
|
|
|
valueBig,
|
|
|
|
|
0,
|
|
|
|
|
nil,
|
|
|
|
|
nil,
|
|
|
|
|
false,
|
|
|
|
|
),
|
|
|
|
|
}
|
|
|
|
|
theirMessenger.verifyTransactionClient = client
|
|
|
|
|
response, err = theirMessenger.ValidateTransactions(context.Background(), []types.Address{receiverAddress})
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
s.Require().NotNil(response)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(response.Messages(), 1)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
receiverMessage := response.Messages()[0]
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(protobuf.ChatMessage_TRANSACTION_COMMAND, receiverMessage.ContentType)
|
|
|
|
|
|
|
|
|
|
s.Require().Equal("Transaction received", receiverMessage.Text)
|
|
|
|
|
s.Require().NotNil(receiverMessage.CommandParameters)
|
|
|
|
|
s.Require().Equal(value, receiverMessage.CommandParameters.Value)
|
|
|
|
|
s.Require().Equal(strings.ToLower(receiverAddress.Hex()), receiverMessage.CommandParameters.Address)
|
|
|
|
|
s.Require().Equal(transactionHash, receiverMessage.CommandParameters.TransactionHash)
|
|
|
|
|
s.Require().Equal(receiverAddressString, receiverMessage.CommandParameters.Address)
|
|
|
|
|
s.Require().Equal("", receiverMessage.CommandParameters.ID)
|
2020-09-01 13:27:01 +00:00
|
|
|
|
s.Require().Equal(common.CommandStateTransactionSent, receiverMessage.CommandParameters.CommandState)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(senderMessage.ID, receiverMessage.ID)
|
|
|
|
|
s.Require().Equal("", receiverMessage.Replace)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *MessengerSuite) TestSendTokenTransaction() {
|
2020-02-21 14:48:53 +00:00
|
|
|
|
value := testValue
|
|
|
|
|
contract := testContract
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
2023-03-08 17:47:09 +00:00
|
|
|
|
theirMessenger := s.newMessenger()
|
2023-11-27 17:01:13 +00:00
|
|
|
|
defer TearDownMessenger(&s.Suite, theirMessenger)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
theirPkString := types.EncodeHex(crypto.FromECDSAPub(&theirMessenger.identity.PublicKey))
|
|
|
|
|
|
|
|
|
|
receiverAddress := crypto.PubkeyToAddress(theirMessenger.identity.PublicKey)
|
|
|
|
|
receiverAddressString := strings.ToLower(receiverAddress.Hex())
|
|
|
|
|
|
2020-01-20 16:44:32 +00:00
|
|
|
|
chat := CreateOneToOneChat(theirPkString, &theirMessenger.identity.PublicKey, s.m.transport)
|
2024-02-26 09:12:37 +00:00
|
|
|
|
err := s.m.SaveChat(chat)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2020-02-21 14:48:53 +00:00
|
|
|
|
transactionHash := testTransactionHash
|
2020-01-10 18:59:01 +00:00
|
|
|
|
signature, err := buildSignature(s.m.identity, &s.m.identity.PublicKey, transactionHash)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2020-01-15 07:25:09 +00:00
|
|
|
|
response, err := s.m.SendTransaction(context.Background(), theirPkString, value, contract, transactionHash, signature)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
s.Require().NotNil(response)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(response.Messages(), 1)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
senderMessage := response.Messages()[0]
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(protobuf.ChatMessage_TRANSACTION_COMMAND, senderMessage.ContentType)
|
|
|
|
|
s.Require().Equal("Transaction sent", senderMessage.Text)
|
|
|
|
|
s.Require().NotNil(senderMessage.CommandParameters)
|
|
|
|
|
s.Require().Equal(transactionHash, senderMessage.CommandParameters.TransactionHash)
|
2020-01-15 07:25:09 +00:00
|
|
|
|
s.Require().Equal(value, senderMessage.CommandParameters.Value)
|
|
|
|
|
s.Require().Equal(contract, senderMessage.CommandParameters.Contract)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(signature, senderMessage.CommandParameters.Signature)
|
2020-09-01 13:27:01 +00:00
|
|
|
|
s.Require().Equal(common.CommandStateTransactionSent, senderMessage.CommandParameters.CommandState)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().NotEmpty(senderMessage.ID)
|
|
|
|
|
|
|
|
|
|
var transactions []*TransactionToValidate
|
|
|
|
|
// Wait for the message to reach its destination
|
|
|
|
|
err = tt.RetryWithBackOff(func() error {
|
|
|
|
|
var err error
|
|
|
|
|
|
|
|
|
|
_, err = theirMessenger.RetrieveAll()
|
|
|
|
|
if err != nil {
|
|
|
|
|
return err
|
|
|
|
|
}
|
|
|
|
|
transactions, err = theirMessenger.persistence.TransactionsToValidate()
|
|
|
|
|
if err == nil && len(transactions) == 0 {
|
|
|
|
|
err = errors.New("no transactions")
|
|
|
|
|
}
|
|
|
|
|
return err
|
|
|
|
|
})
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
actualTransaction := transactions[0]
|
|
|
|
|
|
|
|
|
|
s.Require().Equal(&s.m.identity.PublicKey, actualTransaction.From)
|
|
|
|
|
s.Require().Equal(transactionHash, actualTransaction.TransactionHash)
|
|
|
|
|
s.Require().True(actualTransaction.Validate)
|
|
|
|
|
|
|
|
|
|
senderAddress := crypto.PubkeyToAddress(s.m.identity.PublicKey)
|
|
|
|
|
|
|
|
|
|
contractAddress := types.HexToAddress(contract)
|
|
|
|
|
client := MockEthClient{}
|
|
|
|
|
valueBig, ok := big.NewInt(0).SetString(value, 10)
|
|
|
|
|
s.Require().True(ok)
|
|
|
|
|
client.messages = make(map[string]MockTransaction)
|
|
|
|
|
client.messages[transactionHash] = MockTransaction{
|
2020-01-17 12:39:09 +00:00
|
|
|
|
Status: coretypes.TransactionStatusSuccess,
|
2020-01-10 18:59:01 +00:00
|
|
|
|
Message: coretypes.NewMessage(
|
|
|
|
|
senderAddress,
|
|
|
|
|
&contractAddress,
|
|
|
|
|
1,
|
|
|
|
|
nil,
|
|
|
|
|
0,
|
|
|
|
|
nil,
|
|
|
|
|
buildData(transferFunction, receiverAddress, valueBig),
|
|
|
|
|
false,
|
|
|
|
|
),
|
|
|
|
|
}
|
|
|
|
|
theirMessenger.verifyTransactionClient = client
|
|
|
|
|
response, err = theirMessenger.ValidateTransactions(context.Background(), []types.Address{receiverAddress})
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
s.Require().NotNil(response)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(response.Messages(), 1)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
receiverMessage := response.Messages()[0]
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(protobuf.ChatMessage_TRANSACTION_COMMAND, receiverMessage.ContentType)
|
|
|
|
|
|
|
|
|
|
s.Require().Equal("Transaction received", receiverMessage.Text)
|
|
|
|
|
s.Require().NotNil(receiverMessage.CommandParameters)
|
|
|
|
|
s.Require().Equal(value, receiverMessage.CommandParameters.Value)
|
|
|
|
|
s.Require().Equal(contract, receiverMessage.CommandParameters.Contract)
|
|
|
|
|
s.Require().Equal(transactionHash, receiverMessage.CommandParameters.TransactionHash)
|
|
|
|
|
s.Require().Equal(receiverAddressString, receiverMessage.CommandParameters.Address)
|
|
|
|
|
s.Require().Equal("", receiverMessage.CommandParameters.ID)
|
2020-09-01 13:27:01 +00:00
|
|
|
|
s.Require().Equal(common.CommandStateTransactionSent, receiverMessage.CommandParameters.CommandState)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(senderMessage.ID, receiverMessage.ID)
|
|
|
|
|
s.Require().Equal(senderMessage.Replace, senderMessage.Replace)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *MessengerSuite) TestAcceptRequestAddressForTransaction() {
|
2020-02-21 14:48:53 +00:00
|
|
|
|
value := testValue
|
|
|
|
|
contract := testContract
|
2023-03-08 17:47:09 +00:00
|
|
|
|
theirMessenger := s.newMessenger()
|
2023-11-27 17:01:13 +00:00
|
|
|
|
defer TearDownMessenger(&s.Suite, theirMessenger)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
theirPkString := types.EncodeHex(crypto.FromECDSAPub(&theirMessenger.identity.PublicKey))
|
2021-07-07 11:18:18 +00:00
|
|
|
|
myPkString := types.EncodeHex(crypto.FromECDSAPub(&s.m.identity.PublicKey))
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
|
|
|
|
myAddress := crypto.PubkeyToAddress(s.m.identity.PublicKey)
|
|
|
|
|
|
2020-01-20 16:44:32 +00:00
|
|
|
|
chat := CreateOneToOneChat(theirPkString, &theirMessenger.identity.PublicKey, s.m.transport)
|
2024-02-26 09:12:37 +00:00
|
|
|
|
err := s.m.SaveChat(chat)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
response, err := s.m.RequestAddressForTransaction(context.Background(), theirPkString, myAddress.Hex(), value, contract)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
s.Require().NotNil(response)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(response.Messages(), 1)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
senderMessage := response.Messages()[0]
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(protobuf.ChatMessage_TRANSACTION_COMMAND, senderMessage.ContentType)
|
|
|
|
|
initialCommandID := senderMessage.ID
|
|
|
|
|
|
|
|
|
|
s.Require().Equal("Request address for transaction", senderMessage.Text)
|
|
|
|
|
s.Require().NotNil(senderMessage.CommandParameters)
|
|
|
|
|
s.Require().Equal(value, senderMessage.CommandParameters.Value)
|
|
|
|
|
s.Require().Equal(contract, senderMessage.CommandParameters.Contract)
|
|
|
|
|
s.Require().Equal(initialCommandID, senderMessage.CommandParameters.ID)
|
2020-09-01 13:27:01 +00:00
|
|
|
|
s.Require().Equal(common.CommandStateRequestAddressForTransaction, senderMessage.CommandParameters.CommandState)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
|
|
|
|
// Wait for the message to reach its destination
|
2020-04-22 12:58:28 +00:00
|
|
|
|
response, err = WaitOnMessengerResponse(
|
|
|
|
|
theirMessenger,
|
2021-06-03 13:11:55 +00:00
|
|
|
|
func(r *MessengerResponse) bool { return len(r.Messages()) > 0 },
|
2020-04-22 12:58:28 +00:00
|
|
|
|
"no messages",
|
|
|
|
|
)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
s.Require().NotNil(response)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(response.Messages(), 1)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
receiverMessage := response.Messages()[0]
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(protobuf.ChatMessage_TRANSACTION_COMMAND, receiverMessage.ContentType)
|
|
|
|
|
s.Require().Equal("Request address for transaction", receiverMessage.Text)
|
|
|
|
|
s.Require().NotNil(receiverMessage.CommandParameters)
|
|
|
|
|
s.Require().Equal(value, receiverMessage.CommandParameters.Value)
|
|
|
|
|
s.Require().Equal(contract, receiverMessage.CommandParameters.Contract)
|
|
|
|
|
s.Require().Equal(initialCommandID, receiverMessage.CommandParameters.ID)
|
2020-09-01 13:27:01 +00:00
|
|
|
|
s.Require().Equal(common.CommandStateRequestAddressForTransaction, receiverMessage.CommandParameters.CommandState)
|
2021-07-07 11:18:18 +00:00
|
|
|
|
s.Require().Equal(theirPkString, receiverMessage.ChatId)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
|
|
|
|
// We accept the request
|
|
|
|
|
response, err = theirMessenger.AcceptRequestAddressForTransaction(context.Background(), receiverMessage.ID, "some-address")
|
2020-02-10 11:22:37 +00:00
|
|
|
|
s.Require().NoError(err)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(response.Messages(), 1)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
senderMessage = response.Messages()[0]
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(protobuf.ChatMessage_TRANSACTION_COMMAND, senderMessage.ContentType)
|
|
|
|
|
s.Require().Equal("Request address for transaction accepted", senderMessage.Text)
|
|
|
|
|
s.Require().NotNil(senderMessage.CommandParameters)
|
|
|
|
|
s.Require().Equal(value, senderMessage.CommandParameters.Value)
|
|
|
|
|
s.Require().Equal(contract, senderMessage.CommandParameters.Contract)
|
2020-09-01 13:27:01 +00:00
|
|
|
|
s.Require().Equal(common.CommandStateRequestAddressForTransactionAccepted, senderMessage.CommandParameters.CommandState)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(initialCommandID, senderMessage.CommandParameters.ID)
|
|
|
|
|
s.Require().Equal("some-address", senderMessage.CommandParameters.Address)
|
|
|
|
|
s.Require().Equal(receiverMessage.ID, senderMessage.Replace)
|
|
|
|
|
|
|
|
|
|
// Wait for the message to reach its destination
|
2020-04-22 12:58:28 +00:00
|
|
|
|
response, err = WaitOnMessengerResponse(
|
|
|
|
|
s.m,
|
2021-06-03 13:11:55 +00:00
|
|
|
|
func(r *MessengerResponse) bool { return len(r.Messages()) > 0 },
|
2020-04-22 12:58:28 +00:00
|
|
|
|
"no messages",
|
|
|
|
|
)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(response.Messages(), 1)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
receiverMessage = response.Messages()[0]
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(protobuf.ChatMessage_TRANSACTION_COMMAND, receiverMessage.ContentType)
|
|
|
|
|
s.Require().Equal("Request address for transaction accepted", receiverMessage.Text)
|
|
|
|
|
s.Require().NotNil(receiverMessage.CommandParameters)
|
|
|
|
|
s.Require().Equal(value, receiverMessage.CommandParameters.Value)
|
|
|
|
|
s.Require().Equal(contract, receiverMessage.CommandParameters.Contract)
|
2020-09-01 13:27:01 +00:00
|
|
|
|
s.Require().Equal(common.CommandStateRequestAddressForTransactionAccepted, receiverMessage.CommandParameters.CommandState)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(initialCommandID, receiverMessage.CommandParameters.ID)
|
|
|
|
|
s.Require().Equal("some-address", receiverMessage.CommandParameters.Address)
|
|
|
|
|
s.Require().Equal(initialCommandID, receiverMessage.Replace)
|
2021-07-07 11:18:18 +00:00
|
|
|
|
s.Require().Equal(myPkString, receiverMessage.ChatId)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *MessengerSuite) TestDeclineRequestTransaction() {
|
2020-02-21 14:48:53 +00:00
|
|
|
|
value := testValue
|
|
|
|
|
contract := testContract
|
2020-01-10 18:59:01 +00:00
|
|
|
|
receiverAddress := crypto.PubkeyToAddress(s.m.identity.PublicKey)
|
|
|
|
|
receiverAddressString := strings.ToLower(receiverAddress.Hex())
|
2023-03-08 17:47:09 +00:00
|
|
|
|
theirMessenger := s.newMessenger()
|
2023-11-27 17:01:13 +00:00
|
|
|
|
defer TearDownMessenger(&s.Suite, theirMessenger)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
theirPkString := types.EncodeHex(crypto.FromECDSAPub(&theirMessenger.identity.PublicKey))
|
|
|
|
|
|
2020-01-20 16:44:32 +00:00
|
|
|
|
chat := CreateOneToOneChat(theirPkString, &theirMessenger.identity.PublicKey, s.m.transport)
|
2024-02-26 09:12:37 +00:00
|
|
|
|
err := s.m.SaveChat(chat)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
response, err := s.m.RequestTransaction(context.Background(), theirPkString, value, contract, receiverAddressString)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
s.Require().NotNil(response)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(response.Messages(), 1)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
senderMessage := response.Messages()[0]
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(protobuf.ChatMessage_TRANSACTION_COMMAND, senderMessage.ContentType)
|
|
|
|
|
initialCommandID := senderMessage.ID
|
|
|
|
|
|
|
|
|
|
s.Require().Equal("Request transaction", senderMessage.Text)
|
|
|
|
|
s.Require().NotNil(senderMessage.CommandParameters)
|
|
|
|
|
s.Require().Equal(value, senderMessage.CommandParameters.Value)
|
|
|
|
|
s.Require().Equal(contract, senderMessage.CommandParameters.Contract)
|
|
|
|
|
s.Require().Equal(receiverAddressString, senderMessage.CommandParameters.Address)
|
|
|
|
|
s.Require().Equal(initialCommandID, senderMessage.CommandParameters.ID)
|
2020-09-01 13:27:01 +00:00
|
|
|
|
s.Require().Equal(common.CommandStateRequestTransaction, senderMessage.CommandParameters.CommandState)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
|
|
|
|
// Wait for the message to reach its destination
|
2020-04-22 12:58:28 +00:00
|
|
|
|
response, err = WaitOnMessengerResponse(
|
|
|
|
|
theirMessenger,
|
2021-06-03 13:11:55 +00:00
|
|
|
|
func(r *MessengerResponse) bool { return len(r.Messages()) > 0 },
|
2020-04-22 12:58:28 +00:00
|
|
|
|
"no messages",
|
|
|
|
|
)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
s.Require().NotNil(response)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(response.Messages(), 1)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
receiverMessage := response.Messages()[0]
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(protobuf.ChatMessage_TRANSACTION_COMMAND, receiverMessage.ContentType)
|
|
|
|
|
s.Require().Equal("Request transaction", receiverMessage.Text)
|
|
|
|
|
s.Require().NotNil(receiverMessage.CommandParameters)
|
|
|
|
|
s.Require().Equal(value, receiverMessage.CommandParameters.Value)
|
|
|
|
|
s.Require().Equal(contract, receiverMessage.CommandParameters.Contract)
|
|
|
|
|
s.Require().Equal(receiverAddressString, receiverMessage.CommandParameters.Address)
|
|
|
|
|
s.Require().Equal(initialCommandID, receiverMessage.CommandParameters.ID)
|
2020-09-01 13:27:01 +00:00
|
|
|
|
s.Require().Equal(common.CommandStateRequestTransaction, receiverMessage.CommandParameters.CommandState)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
|
|
|
|
response, err = theirMessenger.DeclineRequestTransaction(context.Background(), initialCommandID)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
s.Require().NotNil(response)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(response.Messages(), 1)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
senderMessage = response.Messages()[0]
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(protobuf.ChatMessage_TRANSACTION_COMMAND, senderMessage.ContentType)
|
|
|
|
|
|
|
|
|
|
s.Require().Equal("Transaction request declined", senderMessage.Text)
|
|
|
|
|
s.Require().Equal(initialCommandID, senderMessage.CommandParameters.ID)
|
|
|
|
|
s.Require().Equal(receiverMessage.ID, senderMessage.Replace)
|
2020-09-01 13:27:01 +00:00
|
|
|
|
s.Require().Equal(common.CommandStateRequestTransactionDeclined, senderMessage.CommandParameters.CommandState)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
|
|
|
|
// Wait for the message to reach its destination
|
2020-04-22 12:58:28 +00:00
|
|
|
|
response, err = WaitOnMessengerResponse(
|
|
|
|
|
s.m,
|
2021-06-03 13:11:55 +00:00
|
|
|
|
func(r *MessengerResponse) bool { return len(r.Messages()) > 0 },
|
2020-04-22 12:58:28 +00:00
|
|
|
|
"no messages",
|
|
|
|
|
)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
s.Require().NotNil(response)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(response.Messages(), 1)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
receiverMessage = response.Messages()[0]
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(protobuf.ChatMessage_TRANSACTION_COMMAND, receiverMessage.ContentType)
|
|
|
|
|
|
|
|
|
|
s.Require().Equal("Transaction request declined", receiverMessage.Text)
|
|
|
|
|
s.Require().Equal(initialCommandID, receiverMessage.CommandParameters.ID)
|
|
|
|
|
s.Require().Equal(initialCommandID, receiverMessage.Replace)
|
2020-09-01 13:27:01 +00:00
|
|
|
|
s.Require().Equal(common.CommandStateRequestTransactionDeclined, receiverMessage.CommandParameters.CommandState)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *MessengerSuite) TestRequestTransaction() {
|
2020-02-21 14:48:53 +00:00
|
|
|
|
value := testValue
|
|
|
|
|
contract := testContract
|
2020-01-10 18:59:01 +00:00
|
|
|
|
receiverAddress := crypto.PubkeyToAddress(s.m.identity.PublicKey)
|
|
|
|
|
receiverAddressString := strings.ToLower(receiverAddress.Hex())
|
2023-03-08 17:47:09 +00:00
|
|
|
|
theirMessenger := s.newMessenger()
|
2023-11-27 17:01:13 +00:00
|
|
|
|
defer TearDownMessenger(&s.Suite, theirMessenger)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
theirPkString := types.EncodeHex(crypto.FromECDSAPub(&theirMessenger.identity.PublicKey))
|
|
|
|
|
|
2020-01-20 16:44:32 +00:00
|
|
|
|
chat := CreateOneToOneChat(theirPkString, &theirMessenger.identity.PublicKey, s.m.transport)
|
2024-02-26 09:12:37 +00:00
|
|
|
|
err := s.m.SaveChat(chat)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
response, err := s.m.RequestTransaction(context.Background(), theirPkString, value, contract, receiverAddressString)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
s.Require().NotNil(response)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(response.Messages(), 1)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
senderMessage := response.Messages()[0]
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(protobuf.ChatMessage_TRANSACTION_COMMAND, senderMessage.ContentType)
|
|
|
|
|
initialCommandID := senderMessage.ID
|
|
|
|
|
|
|
|
|
|
s.Require().Equal("Request transaction", senderMessage.Text)
|
|
|
|
|
s.Require().NotNil(senderMessage.CommandParameters)
|
|
|
|
|
s.Require().Equal(value, senderMessage.CommandParameters.Value)
|
|
|
|
|
s.Require().Equal(contract, senderMessage.CommandParameters.Contract)
|
|
|
|
|
s.Require().Equal(receiverAddressString, senderMessage.CommandParameters.Address)
|
|
|
|
|
s.Require().Equal(initialCommandID, senderMessage.CommandParameters.ID)
|
2020-09-01 13:27:01 +00:00
|
|
|
|
s.Require().Equal(common.CommandStateRequestTransaction, senderMessage.CommandParameters.CommandState)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
|
|
|
|
// Wait for the message to reach its destination
|
2020-04-22 12:58:28 +00:00
|
|
|
|
response, err = WaitOnMessengerResponse(
|
|
|
|
|
theirMessenger,
|
2021-06-03 13:11:55 +00:00
|
|
|
|
func(r *MessengerResponse) bool { return len(r.Messages()) > 0 },
|
2020-04-22 12:58:28 +00:00
|
|
|
|
"no messages",
|
|
|
|
|
)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
s.Require().NotNil(response)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(response.Messages(), 1)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
receiverMessage := response.Messages()[0]
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(protobuf.ChatMessage_TRANSACTION_COMMAND, receiverMessage.ContentType)
|
|
|
|
|
s.Require().Equal("Request transaction", receiverMessage.Text)
|
|
|
|
|
s.Require().NotNil(receiverMessage.CommandParameters)
|
|
|
|
|
s.Require().Equal(value, receiverMessage.CommandParameters.Value)
|
|
|
|
|
s.Require().Equal(contract, receiverMessage.CommandParameters.Contract)
|
|
|
|
|
s.Require().Equal(receiverAddressString, receiverMessage.CommandParameters.Address)
|
|
|
|
|
s.Require().Equal(initialCommandID, receiverMessage.CommandParameters.ID)
|
2020-09-01 13:27:01 +00:00
|
|
|
|
s.Require().Equal(common.CommandStateRequestTransaction, receiverMessage.CommandParameters.CommandState)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
|
|
|
|
transactionHash := "0x412a851ac2ae51cad34a56c8a9cfee55d577ac5e1ac71cf488a2f2093a373799"
|
|
|
|
|
signature, err := buildSignature(theirMessenger.identity, &theirMessenger.identity.PublicKey, transactionHash)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
response, err = theirMessenger.AcceptRequestTransaction(context.Background(), transactionHash, initialCommandID, signature)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
s.Require().NotNil(response)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(response.Messages(), 1)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
senderMessage = response.Messages()[0]
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(protobuf.ChatMessage_TRANSACTION_COMMAND, senderMessage.ContentType)
|
|
|
|
|
|
|
|
|
|
s.Require().Equal("Transaction sent", senderMessage.Text)
|
|
|
|
|
s.Require().NotNil(senderMessage.CommandParameters)
|
|
|
|
|
s.Require().Equal(value, senderMessage.CommandParameters.Value)
|
|
|
|
|
s.Require().Equal(contract, senderMessage.CommandParameters.Contract)
|
|
|
|
|
s.Require().Equal(transactionHash, senderMessage.CommandParameters.TransactionHash)
|
|
|
|
|
s.Require().Equal(receiverAddressString, senderMessage.CommandParameters.Address)
|
|
|
|
|
s.Require().Equal(initialCommandID, senderMessage.CommandParameters.ID)
|
|
|
|
|
s.Require().Equal(signature, senderMessage.CommandParameters.Signature)
|
|
|
|
|
s.Require().NotEmpty(senderMessage.ID)
|
|
|
|
|
s.Require().Equal(receiverMessage.ID, senderMessage.Replace)
|
2020-09-01 13:27:01 +00:00
|
|
|
|
s.Require().Equal(common.CommandStateTransactionSent, senderMessage.CommandParameters.CommandState)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
|
|
|
|
var transactions []*TransactionToValidate
|
|
|
|
|
// Wait for the message to reach its destination
|
|
|
|
|
err = tt.RetryWithBackOff(func() error {
|
|
|
|
|
var err error
|
|
|
|
|
|
|
|
|
|
_, err = s.m.RetrieveAll()
|
|
|
|
|
if err != nil {
|
|
|
|
|
return err
|
|
|
|
|
}
|
|
|
|
|
transactions, err = s.m.persistence.TransactionsToValidate()
|
|
|
|
|
if err == nil && len(transactions) == 0 {
|
|
|
|
|
err = errors.New("no transactions")
|
|
|
|
|
}
|
|
|
|
|
return err
|
|
|
|
|
})
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
actualTransaction := transactions[0]
|
|
|
|
|
|
|
|
|
|
s.Require().Equal(&theirMessenger.identity.PublicKey, actualTransaction.From)
|
|
|
|
|
s.Require().Equal(transactionHash, actualTransaction.TransactionHash)
|
|
|
|
|
s.Require().True(actualTransaction.Validate)
|
|
|
|
|
s.Require().Equal(initialCommandID, actualTransaction.CommandID)
|
|
|
|
|
|
|
|
|
|
senderAddress := crypto.PubkeyToAddress(theirMessenger.identity.PublicKey)
|
|
|
|
|
|
|
|
|
|
contractAddress := types.HexToAddress(contract)
|
|
|
|
|
client := MockEthClient{}
|
|
|
|
|
valueBig, ok := big.NewInt(0).SetString(value, 10)
|
|
|
|
|
s.Require().True(ok)
|
|
|
|
|
client.messages = make(map[string]MockTransaction)
|
|
|
|
|
client.messages[transactionHash] = MockTransaction{
|
2020-01-17 12:39:09 +00:00
|
|
|
|
Status: coretypes.TransactionStatusSuccess,
|
2020-01-10 18:59:01 +00:00
|
|
|
|
Message: coretypes.NewMessage(
|
|
|
|
|
senderAddress,
|
|
|
|
|
&contractAddress,
|
|
|
|
|
1,
|
|
|
|
|
nil,
|
|
|
|
|
0,
|
|
|
|
|
nil,
|
|
|
|
|
buildData(transferFunction, receiverAddress, valueBig),
|
|
|
|
|
false,
|
|
|
|
|
),
|
|
|
|
|
}
|
|
|
|
|
s.m.verifyTransactionClient = client
|
|
|
|
|
response, err = s.m.ValidateTransactions(context.Background(), []types.Address{receiverAddress})
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
s.Require().NotNil(response)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
s.Require().Len(response.Chats(), 1)
|
2021-06-03 13:11:55 +00:00
|
|
|
|
s.Require().Len(response.Messages(), 1)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
|
2021-06-03 13:11:55 +00:00
|
|
|
|
receiverMessage = response.Messages()[0]
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(protobuf.ChatMessage_TRANSACTION_COMMAND, receiverMessage.ContentType)
|
|
|
|
|
|
|
|
|
|
s.Require().Equal("Transaction received", receiverMessage.Text)
|
|
|
|
|
s.Require().NotNil(receiverMessage.CommandParameters)
|
|
|
|
|
s.Require().Equal(value, receiverMessage.CommandParameters.Value)
|
|
|
|
|
s.Require().Equal(contract, receiverMessage.CommandParameters.Contract)
|
|
|
|
|
s.Require().Equal(transactionHash, receiverMessage.CommandParameters.TransactionHash)
|
|
|
|
|
s.Require().Equal(receiverAddressString, receiverMessage.CommandParameters.Address)
|
|
|
|
|
s.Require().Equal(initialCommandID, receiverMessage.CommandParameters.ID)
|
|
|
|
|
s.Require().Equal(signature, receiverMessage.CommandParameters.Signature)
|
2020-09-01 13:27:01 +00:00
|
|
|
|
s.Require().Equal(common.CommandStateTransactionSent, receiverMessage.CommandParameters.CommandState)
|
2020-01-10 18:59:01 +00:00
|
|
|
|
s.Require().Equal(senderMessage.ID, receiverMessage.ID)
|
|
|
|
|
s.Require().Equal(senderMessage.Replace, senderMessage.Replace)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
type MockTransaction struct {
|
2020-01-17 12:39:09 +00:00
|
|
|
|
Status coretypes.TransactionStatus
|
2020-01-10 18:59:01 +00:00
|
|
|
|
Message coretypes.Message
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
type MockEthClient struct {
|
|
|
|
|
messages map[string]MockTransaction
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-17 12:39:09 +00:00
|
|
|
|
func (m MockEthClient) TransactionByHash(ctx context.Context, hash types.Hash) (coretypes.Message, coretypes.TransactionStatus, error) {
|
2020-01-10 18:59:01 +00:00
|
|
|
|
mockTransaction, ok := m.messages[hash.Hex()]
|
|
|
|
|
if !ok {
|
2020-01-17 12:39:09 +00:00
|
|
|
|
return coretypes.Message{}, coretypes.TransactionStatusFailed, nil
|
2020-01-10 18:59:01 +00:00
|
|
|
|
}
|
2020-02-10 11:22:37 +00:00
|
|
|
|
return mockTransaction.Message, mockTransaction.Status, nil
|
2020-01-10 18:59:01 +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
|
|
|
|
func (s *MessengerSuite) TestMessageJSON() {
|
2020-09-01 13:27:01 +00:00
|
|
|
|
message := &common.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
|
|
|
|
ID: "test-1",
|
|
|
|
|
LocalChatID: "local-chat-id",
|
|
|
|
|
Alias: "alias",
|
2023-08-18 11:39:59 +00:00
|
|
|
|
ChatMessage: &protobuf.ChatMessage{
|
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
|
|
|
|
ChatId: "remote-chat-id",
|
|
|
|
|
ContentType: 0,
|
|
|
|
|
Text: "test-1",
|
|
|
|
|
Clock: 1,
|
|
|
|
|
},
|
2023-01-20 18:51:36 +00:00
|
|
|
|
From: testPK,
|
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
|
|
|
|
}
|
|
|
|
|
|
2021-05-14 10:55:42 +00:00
|
|
|
|
_, err := json.Marshal(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
|
|
|
|
s.Require().NoError(err)
|
2019-11-21 16:19:22 +00:00
|
|
|
|
}
|
|
|
|
|
|
2020-12-15 14:43:41 +00:00
|
|
|
|
func (s *MessengerSuite) TestSentEventTracking() {
|
|
|
|
|
|
|
|
|
|
//when message sent, its sent field should be "false" until we got confirmation
|
|
|
|
|
chat := CreatePublicChat("test-chat", s.m.transport)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
err := s.m.SaveChat(chat)
|
2020-12-15 14:43:41 +00:00
|
|
|
|
s.NoError(err)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
inputMessage := buildTestMessage(*chat)
|
2020-12-15 14:43:41 +00:00
|
|
|
|
|
|
|
|
|
_, err = s.m.SendChatMessage(context.Background(), inputMessage)
|
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
|
|
|
|
rawMessage, err := s.m.persistence.RawMessageByID(inputMessage.ID)
|
|
|
|
|
s.NoError(err)
|
|
|
|
|
s.False(rawMessage.Sent)
|
|
|
|
|
|
|
|
|
|
//when message sent, its sent field should be true after we got confirmation
|
2024-07-11 11:41:49 +00:00
|
|
|
|
err = s.m.processSentMessage(inputMessage.ID)
|
2020-12-15 14:43:41 +00:00
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
|
|
|
|
rawMessage, err = s.m.persistence.RawMessageByID(inputMessage.ID)
|
|
|
|
|
s.NoError(err)
|
|
|
|
|
s.True(rawMessage.Sent)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *MessengerSuite) TestLastSentField() {
|
|
|
|
|
//send message
|
|
|
|
|
chat := CreatePublicChat("test-chat", s.m.transport)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
err := s.m.SaveChat(chat)
|
2020-12-15 14:43:41 +00:00
|
|
|
|
s.NoError(err)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
inputMessage := buildTestMessage(*chat)
|
2020-12-15 14:43:41 +00:00
|
|
|
|
|
|
|
|
|
_, err = s.m.SendChatMessage(context.Background(), inputMessage)
|
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
|
|
|
|
rawMessage, err := s.m.persistence.RawMessageByID(inputMessage.ID)
|
|
|
|
|
s.NoError(err)
|
|
|
|
|
s.Equal(1, rawMessage.SendCount)
|
|
|
|
|
|
|
|
|
|
//make sure LastSent is set
|
|
|
|
|
s.NotEqual(uint64(0), rawMessage.LastSent, "rawMessage.LastSent should be non-zero after sending")
|
|
|
|
|
}
|
|
|
|
|
|
2023-11-22 22:43:22 +00:00
|
|
|
|
// TODO rewrite test to use persistence calls, as shouldResendMessage does not contain
|
|
|
|
|
// relevant logic now
|
|
|
|
|
// func (s *MessengerSuite) TestShouldResendEmoji() {
|
|
|
|
|
// // shouldn't try to resend non-emoji messages.
|
|
|
|
|
// ok, err := s.m.shouldResendMessage(&common.RawMessage{
|
|
|
|
|
// MessageType: protobuf.ApplicationMetadataMessage_CONTACT_UPDATE,
|
|
|
|
|
// Sent: false,
|
|
|
|
|
// SendCount: 2,
|
|
|
|
|
// }, s.m.getTimesource())
|
|
|
|
|
// s.Error(err)
|
|
|
|
|
// s.False(ok)
|
|
|
|
|
|
|
|
|
|
// // shouldn't try to resend already sent message
|
|
|
|
|
// ok, err = s.m.shouldResendMessage(&common.RawMessage{
|
|
|
|
|
// MessageType: protobuf.ApplicationMetadataMessage_EMOJI_REACTION,
|
|
|
|
|
// Sent: true,
|
|
|
|
|
// SendCount: 1,
|
|
|
|
|
// }, s.m.getTimesource())
|
|
|
|
|
// s.Error(err)
|
|
|
|
|
// s.False(ok)
|
|
|
|
|
|
|
|
|
|
// // messages that already sent to many times shouldn't be resend
|
|
|
|
|
// ok, err = s.m.shouldResendMessage(&common.RawMessage{
|
|
|
|
|
// MessageType: protobuf.ApplicationMetadataMessage_EMOJI_REACTION,
|
|
|
|
|
// Sent: false,
|
|
|
|
|
// SendCount: s.m.config.messageResendMaxCount + 1,
|
|
|
|
|
// }, s.m.getTimesource())
|
|
|
|
|
// s.NoError(err)
|
|
|
|
|
// s.False(ok)
|
|
|
|
|
|
|
|
|
|
// // message sent one time CAN'T be resend in 15 seconds (only after 30)
|
|
|
|
|
// ok, err = s.m.shouldResendMessage(&common.RawMessage{
|
|
|
|
|
// MessageType: protobuf.ApplicationMetadataMessage_EMOJI_REACTION,
|
|
|
|
|
// Sent: false,
|
|
|
|
|
// SendCount: 1,
|
|
|
|
|
// LastSent: s.m.getTimesource().GetCurrentTime() - 15*uint64(time.Second.Milliseconds()),
|
|
|
|
|
// }, s.m.getTimesource())
|
|
|
|
|
// s.NoError(err)
|
|
|
|
|
// s.False(ok)
|
|
|
|
|
|
|
|
|
|
// // message sent one time CAN be resend in 35 seconds
|
|
|
|
|
// ok, err = s.m.shouldResendMessage(&common.RawMessage{
|
|
|
|
|
// MessageType: protobuf.ApplicationMetadataMessage_EMOJI_REACTION,
|
|
|
|
|
// Sent: false,
|
|
|
|
|
// SendCount: 1,
|
|
|
|
|
// LastSent: s.m.getTimesource().GetCurrentTime() - 35*uint64(time.Second.Milliseconds()),
|
|
|
|
|
// }, s.m.getTimesource())
|
|
|
|
|
// s.NoError(err)
|
|
|
|
|
// s.True(ok)
|
|
|
|
|
|
|
|
|
|
// // message sent three times CAN'T be resend in 100 seconds (only after 120)
|
|
|
|
|
// ok, err = s.m.shouldResendMessage(&common.RawMessage{
|
|
|
|
|
// MessageType: protobuf.ApplicationMetadataMessage_EMOJI_REACTION,
|
|
|
|
|
// Sent: false,
|
|
|
|
|
// SendCount: 3,
|
|
|
|
|
// LastSent: s.m.getTimesource().GetCurrentTime() - 100*uint64(time.Second.Milliseconds()),
|
|
|
|
|
// }, s.m.getTimesource())
|
|
|
|
|
// s.NoError(err)
|
|
|
|
|
// s.False(ok)
|
|
|
|
|
|
|
|
|
|
// // message sent tow times CAN be resend in 65 seconds
|
|
|
|
|
// ok, err = s.m.shouldResendMessage(&common.RawMessage{
|
|
|
|
|
// MessageType: protobuf.ApplicationMetadataMessage_EMOJI_REACTION,
|
|
|
|
|
// Sent: false,
|
|
|
|
|
// SendCount: 3,
|
|
|
|
|
// LastSent: s.m.getTimesource().GetCurrentTime() - 125*uint64(time.Second.Milliseconds()),
|
|
|
|
|
// }, s.m.getTimesource())
|
|
|
|
|
// s.NoError(err)
|
|
|
|
|
// s.True(ok)
|
|
|
|
|
// }
|
2020-12-15 14:43:41 +00:00
|
|
|
|
|
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
|
|
|
|
func (s *MessengerSuite) TestSendMessageWithPreviews() {
|
2023-12-15 20:29:39 +00:00
|
|
|
|
httpServer, err := server.NewMediaServer(s.m.database, nil, nil, nil)
|
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
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
err = httpServer.SetPort(9876)
|
|
|
|
|
s.NoError(err)
|
2024-07-01 18:52:57 +00:00
|
|
|
|
s.m.SetMediaServer(httpServer)
|
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
|
|
|
|
|
|
|
|
|
chat := CreatePublicChat("test-chat", s.m.transport)
|
|
|
|
|
err = s.m.SaveChat(chat)
|
|
|
|
|
s.NoError(err)
|
|
|
|
|
inputMsg := buildTestMessage(*chat)
|
|
|
|
|
|
2023-11-09 16:24:35 +00:00
|
|
|
|
contactPublicKey, err := crypto.GenerateKey()
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
compressedContactPublicKey := crypto.CompressPubkey(&contactPublicKey.PublicKey)
|
|
|
|
|
contactID := types.EncodeHex(crypto.FromECDSAPub(&contactPublicKey.PublicKey))
|
|
|
|
|
|
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
|
|
|
|
preview := common.LinkPreview{
|
2023-08-21 16:48:07 +00:00
|
|
|
|
Type: protobuf.UnfurledLink_LINK,
|
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
|
|
|
|
URL: "https://github.com",
|
|
|
|
|
Title: "Build software better, together",
|
|
|
|
|
Description: "GitHub is where people build software.",
|
|
|
|
|
Thumbnail: common.LinkPreviewThumbnail{
|
|
|
|
|
DataURI: "data:image/png;base64,iVBORw0KGgoAAAANSUg=",
|
|
|
|
|
Width: 100,
|
|
|
|
|
Height: 200,
|
|
|
|
|
},
|
2024-03-12 20:47:51 +00:00
|
|
|
|
Favicon: common.LinkPreviewThumbnail{
|
|
|
|
|
DataURI: "data:image/png;base64,iVBORw0KGgoAAAANSUg=",
|
|
|
|
|
},
|
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
|
|
|
|
}
|
|
|
|
|
inputMsg.LinkPreviews = []common.LinkPreview{preview}
|
|
|
|
|
|
2023-10-13 12:25:34 +00:00
|
|
|
|
sentContactPreview := common.StatusLinkPreview{
|
|
|
|
|
URL: "https://status.app/u/TestUrl",
|
|
|
|
|
Contact: &common.StatusContactLinkPreview{
|
2023-11-09 16:24:35 +00:00
|
|
|
|
PublicKey: contactID,
|
2023-10-13 12:25:34 +00:00
|
|
|
|
DisplayName: "TestDisplayName",
|
|
|
|
|
Description: "Test description",
|
|
|
|
|
Icon: common.LinkPreviewThumbnail{
|
|
|
|
|
Width: 100,
|
|
|
|
|
Height: 200,
|
|
|
|
|
DataURI: "data:image/png;base64,iVBORw0KGgoAAAANSUg=",
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
inputMsg.StatusLinkPreviews = []common.StatusLinkPreview{sentContactPreview}
|
|
|
|
|
|
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
|
|
|
|
_, err = s.m.SendChatMessage(context.Background(), inputMsg)
|
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
|
|
|
|
savedMsgs, _, err := s.m.MessageByChatID(chat.ID, "", 10)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
s.Require().Len(savedMsgs, 1)
|
|
|
|
|
savedMsg := savedMsgs[0]
|
|
|
|
|
|
|
|
|
|
// Test unfurled links have been saved.
|
|
|
|
|
s.Require().Len(savedMsg.UnfurledLinks, 1)
|
2023-10-13 12:25:34 +00:00
|
|
|
|
savedLinkProto := savedMsg.UnfurledLinks[0]
|
|
|
|
|
s.Require().Equal(preview.Type, savedLinkProto.Type)
|
|
|
|
|
s.Require().Equal(preview.URL, savedLinkProto.Url)
|
|
|
|
|
s.Require().Equal(preview.Title, savedLinkProto.Title)
|
|
|
|
|
s.Require().Equal(preview.Description, savedLinkProto.Description)
|
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
|
|
|
|
|
|
|
|
|
// Test the saved link thumbnail can be encoded as a data URI.
|
2023-10-13 12:25:34 +00:00
|
|
|
|
expectedDataURI, err := images.GetPayloadDataURI(savedLinkProto.ThumbnailPayload)
|
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
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
s.Require().Equal(preview.Thumbnail.DataURI, expectedDataURI)
|
|
|
|
|
|
|
|
|
|
s.Require().Equal(
|
|
|
|
|
httpServer.MakeLinkPreviewThumbnailURL(inputMsg.ID, preview.URL),
|
|
|
|
|
savedMsg.LinkPreviews[0].Thumbnail.URL,
|
|
|
|
|
)
|
2023-10-13 12:25:34 +00:00
|
|
|
|
|
|
|
|
|
// Check saved message protobuf fields
|
|
|
|
|
s.Require().NotNil(savedMsg.UnfurledStatusLinks)
|
|
|
|
|
s.Require().Len(savedMsg.UnfurledStatusLinks.UnfurledStatusLinks, 1)
|
|
|
|
|
savedStatusLinkProto := savedMsg.UnfurledStatusLinks.UnfurledStatusLinks[0]
|
|
|
|
|
s.Require().Equal(sentContactPreview.URL, savedStatusLinkProto.Url)
|
|
|
|
|
s.Require().NotNil(savedStatusLinkProto.GetContact())
|
|
|
|
|
s.Require().Nil(savedStatusLinkProto.GetCommunity())
|
|
|
|
|
s.Require().Nil(savedStatusLinkProto.GetChannel())
|
|
|
|
|
|
|
|
|
|
savedContactProto := savedStatusLinkProto.GetContact()
|
2023-11-09 16:24:35 +00:00
|
|
|
|
s.Require().Equal(compressedContactPublicKey, savedContactProto.PublicKey)
|
2023-10-13 12:25:34 +00:00
|
|
|
|
s.Require().Equal(sentContactPreview.Contact.DisplayName, savedContactProto.DisplayName)
|
|
|
|
|
s.Require().Equal(sentContactPreview.Contact.Description, savedContactProto.Description)
|
|
|
|
|
s.Require().NotNil(savedContactProto.Icon)
|
|
|
|
|
s.Require().Equal(sentContactPreview.Contact.Icon.Width, int(savedContactProto.Icon.Width))
|
|
|
|
|
s.Require().Equal(sentContactPreview.Contact.Icon.Height, int(savedContactProto.Icon.Height))
|
|
|
|
|
|
|
|
|
|
iconDataURI, err := images.GetPayloadDataURI(savedContactProto.Icon.Payload)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
s.Require().Equal(sentContactPreview.Contact.Icon.DataURI, iconDataURI)
|
|
|
|
|
|
|
|
|
|
// Check message `StatusLinkPreviews` properties
|
|
|
|
|
s.Require().Len(savedMsg.StatusLinkPreviews, 1)
|
|
|
|
|
savedStatusLinkPreview := savedMsg.StatusLinkPreviews[0]
|
|
|
|
|
s.Require().Equal(sentContactPreview.URL, savedStatusLinkPreview.URL)
|
|
|
|
|
s.Require().NotNil(savedStatusLinkPreview.Contact)
|
|
|
|
|
|
|
|
|
|
savedContact := savedStatusLinkPreview.Contact
|
|
|
|
|
s.Require().Equal(sentContactPreview.Contact.PublicKey, savedContact.PublicKey)
|
|
|
|
|
s.Require().Equal(sentContactPreview.Contact.DisplayName, savedContact.DisplayName)
|
|
|
|
|
s.Require().Equal(sentContactPreview.Contact.Description, savedContact.Description)
|
|
|
|
|
s.Require().NotNil(savedContact.Icon)
|
|
|
|
|
s.Require().Equal(sentContactPreview.Contact.Icon.Width, savedContact.Icon.Width)
|
|
|
|
|
s.Require().Equal(sentContactPreview.Contact.Icon.Height, savedContact.Icon.Height)
|
|
|
|
|
expectedIconURL := httpServer.MakeStatusLinkPreviewThumbnailURL(inputMsg.ID, sentContactPreview.URL, "contact-icon")
|
|
|
|
|
s.Require().Equal(expectedIconURL, savedContact.Icon.URL)
|
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
|
|
|
|
}
|
|
|
|
|
|
2020-12-15 14:43:41 +00:00
|
|
|
|
func (s *MessengerSuite) TestMessageSent() {
|
|
|
|
|
//send message
|
|
|
|
|
chat := CreatePublicChat("test-chat", s.m.transport)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
err := s.m.SaveChat(chat)
|
2020-12-15 14:43:41 +00:00
|
|
|
|
s.NoError(err)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
inputMessage := buildTestMessage(*chat)
|
2020-12-15 14:43:41 +00:00
|
|
|
|
|
|
|
|
|
_, err = s.m.SendChatMessage(context.Background(), inputMessage)
|
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
|
|
|
|
rawMessage, err := s.m.persistence.RawMessageByID(inputMessage.ID)
|
|
|
|
|
s.NoError(err)
|
|
|
|
|
s.Equal(1, rawMessage.SendCount)
|
|
|
|
|
s.False(rawMessage.Sent)
|
|
|
|
|
|
|
|
|
|
//imitate chat message sent
|
2024-07-11 11:41:49 +00:00
|
|
|
|
err = s.m.processSentMessage(inputMessage.ID)
|
2020-12-15 14:43:41 +00:00
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
|
|
|
|
rawMessage, err = s.m.persistence.RawMessageByID(inputMessage.ID)
|
|
|
|
|
s.NoError(err)
|
|
|
|
|
s.Equal(1, rawMessage.SendCount)
|
|
|
|
|
s.True(rawMessage.Sent)
|
|
|
|
|
}
|
|
|
|
|
|
2023-06-20 16:12:59 +00:00
|
|
|
|
func (s *MessengerSuite) TestProcessSentMessages() {
|
2024-07-11 11:41:49 +00:00
|
|
|
|
err := s.m.processSentMessage("a")
|
2023-06-20 16:12:59 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
}
|
|
|
|
|
|
2020-12-15 14:43:41 +00:00
|
|
|
|
func (s *MessengerSuite) TestResendExpiredEmojis() {
|
|
|
|
|
//send message
|
|
|
|
|
chat := CreatePublicChat("test-chat", s.m.transport)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
err := s.m.SaveChat(chat)
|
2020-12-15 14:43:41 +00:00
|
|
|
|
s.NoError(err)
|
2021-01-11 10:32:51 +00:00
|
|
|
|
inputMessage := buildTestMessage(*chat)
|
2020-12-15 14:43:41 +00:00
|
|
|
|
|
|
|
|
|
_, err = s.m.SendChatMessage(context.Background(), inputMessage)
|
|
|
|
|
s.NoError(err)
|
|
|
|
|
|
|
|
|
|
//create emoji
|
|
|
|
|
_, err = s.m.SendEmojiReaction(context.Background(), chat.ID, inputMessage.ID, protobuf.EmojiReaction_SAD)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
ids, err := s.m.persistence.RawMessagesIDsByType(protobuf.ApplicationMetadataMessage_EMOJI_REACTION)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
emojiID := ids[0]
|
|
|
|
|
|
|
|
|
|
//check that emoji was sent one time
|
|
|
|
|
rawMessage, err := s.m.persistence.RawMessageByID(emojiID)
|
|
|
|
|
s.NoError(err)
|
|
|
|
|
s.False(rawMessage.Sent)
|
|
|
|
|
s.Equal(1, rawMessage.SendCount)
|
|
|
|
|
|
|
|
|
|
//imitate that more than 30 seconds passed since message was sent
|
2021-11-17 09:11:51 +00:00
|
|
|
|
rawMessage.LastSent = rawMessage.LastSent - 35*uint64(time.Second.Milliseconds())
|
2020-12-15 14:43:41 +00:00
|
|
|
|
err = s.m.persistence.SaveRawMessage(rawMessage)
|
|
|
|
|
s.NoError(err)
|
|
|
|
|
time.Sleep(2 * time.Second)
|
|
|
|
|
|
|
|
|
|
//make sure it was resent and SendCount incremented
|
|
|
|
|
rawMessage, err = s.m.persistence.RawMessageByID(emojiID)
|
|
|
|
|
s.NoError(err)
|
2021-10-27 10:59:43 +00:00
|
|
|
|
s.True(rawMessage.SendCount >= 2)
|
2020-12-15 14:43:41 +00:00
|
|
|
|
}
|
|
|
|
|
|
2023-05-16 15:00:49 +00:00
|
|
|
|
func buildImageWithAlbumIDMessage(chat Chat, albumID string) (*common.Message, error) {
|
2023-04-14 17:17:56 +00:00
|
|
|
|
file, err := os.Open("../_assets/tests/test.jpg")
|
|
|
|
|
if err != err {
|
|
|
|
|
return nil, err
|
|
|
|
|
}
|
|
|
|
|
defer file.Close()
|
|
|
|
|
|
2023-12-11 08:17:01 +00:00
|
|
|
|
payload, err := io.ReadAll(file)
|
2023-04-14 17:17:56 +00:00
|
|
|
|
if err != err {
|
|
|
|
|
return nil, err
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
clock, timestamp := chat.NextClockAndTimestamp(&testTimeSource{})
|
2023-08-18 11:39:59 +00:00
|
|
|
|
message := common.NewMessage()
|
2023-04-14 17:17:56 +00:00
|
|
|
|
message.ChatId = chat.ID
|
|
|
|
|
message.Clock = clock
|
|
|
|
|
message.Timestamp = timestamp
|
|
|
|
|
message.WhisperTimestamp = clock
|
|
|
|
|
message.LocalChatID = chat.ID
|
|
|
|
|
message.MessageType = protobuf.MessageType_ONE_TO_ONE
|
|
|
|
|
message.ContentType = protobuf.ChatMessage_IMAGE
|
|
|
|
|
|
|
|
|
|
image := protobuf.ImageMessage{
|
|
|
|
|
Payload: payload,
|
2024-01-24 20:09:28 +00:00
|
|
|
|
Format: protobuf.ImageFormat_JPEG,
|
2023-04-14 17:17:56 +00:00
|
|
|
|
Width: 1200,
|
|
|
|
|
Height: 1000,
|
2023-05-16 15:00:49 +00:00
|
|
|
|
AlbumId: albumID,
|
2023-04-14 17:17:56 +00:00
|
|
|
|
}
|
|
|
|
|
message.Payload = &protobuf.ChatMessage_Image{Image: &image}
|
|
|
|
|
|
|
|
|
|
return message, nil
|
|
|
|
|
}
|
|
|
|
|
|
2023-05-16 15:00:49 +00:00
|
|
|
|
func buildImageWithoutAlbumIDMessage(chat Chat) (*common.Message, error) {
|
|
|
|
|
return buildImageWithAlbumIDMessage(chat, "")
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-20 16:44:32 +00:00
|
|
|
|
type testTimeSource struct{}
|
|
|
|
|
|
|
|
|
|
func (t *testTimeSource) GetCurrentTime() uint64 {
|
|
|
|
|
return uint64(time.Now().Unix())
|
|
|
|
|
}
|
2023-10-03 16:29:27 +00:00
|
|
|
|
|
|
|
|
|
func (s *MessengerSuite) TestSendMessageMention() {
|
|
|
|
|
// Initialize Alice and Bob's messengers
|
|
|
|
|
alice, bob := s.m, s.newMessenger()
|
2023-11-27 17:01:13 +00:00
|
|
|
|
defer TearDownMessenger(&s.Suite, bob)
|
2023-10-03 16:29:27 +00:00
|
|
|
|
|
|
|
|
|
// Set display names for Bob and Alice
|
|
|
|
|
s.Require().NoError(bob.settings.SaveSettingField(settings.DisplayName, "bobby"))
|
|
|
|
|
s.Require().NoError(alice.settings.SaveSettingField(settings.DisplayName, "Alice"))
|
|
|
|
|
s.Require().NoError(alice.settings.SaveSettingField(settings.NotificationsEnabled, true))
|
|
|
|
|
|
|
|
|
|
// Create one-to-one chats
|
|
|
|
|
chat, chat2 := CreateOneToOneChat(common.PubkeyToHex(&alice.identity.PublicKey), &alice.identity.PublicKey, bob.transport),
|
|
|
|
|
CreateOneToOneChat(common.PubkeyToHex(&bob.identity.PublicKey), &bob.identity.PublicKey, alice.transport)
|
|
|
|
|
s.Require().NoError(bob.SaveChat(chat))
|
|
|
|
|
s.Require().NoError(alice.SaveChat(chat2))
|
|
|
|
|
|
|
|
|
|
// Prepare the message and Send the message from Bob to Alice
|
|
|
|
|
inputMessage := common.NewMessage()
|
|
|
|
|
inputMessage.ChatId = chat.ID
|
|
|
|
|
inputMessage.Text = fmt.Sprintf("@%s talk to @%s", alice.myHexIdentity(), bob.myHexIdentity())
|
|
|
|
|
inputMessage.ContentType = protobuf.ChatMessage_TEXT_PLAIN
|
2024-02-26 09:12:37 +00:00
|
|
|
|
_, err := bob.SendChatMessage(context.Background(), inputMessage)
|
2023-10-03 16:29:27 +00:00
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
// Wait for Alice to receive the message and make sure it's properly formatted
|
|
|
|
|
response, err := WaitOnMessengerResponse(alice, func(r *MessengerResponse) bool { return len(r.Notifications()) >= 1 }, "no messages")
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
s.Require().Equal("Alice talk to bobby", response.Notifications()[0].Message)
|
|
|
|
|
}
|
2024-10-18 02:25:34 +00:00
|
|
|
|
|
|
|
|
|
func (s *MessengerSuite) TestInitChatsFirstMessageTimestamp() {
|
|
|
|
|
createRequest := &requests.CreateCommunity{
|
|
|
|
|
Name: "status",
|
|
|
|
|
Description: "status community description",
|
|
|
|
|
Membership: protobuf.CommunityPermissions_AUTO_ACCEPT,
|
|
|
|
|
}
|
|
|
|
|
communityManager := s.m.communitiesManager
|
|
|
|
|
c, err := communityManager.CreateCommunity(createRequest, true)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
s.Require().NotNil(c)
|
|
|
|
|
|
|
|
|
|
chat := &protobuf.CommunityChat{
|
|
|
|
|
Identity: &protobuf.ChatIdentity{
|
|
|
|
|
DisplayName: "chat1",
|
|
|
|
|
Description: "description",
|
|
|
|
|
},
|
|
|
|
|
Permissions: &protobuf.CommunityPermissions{
|
|
|
|
|
Access: protobuf.CommunityPermissions_AUTO_ACCEPT,
|
|
|
|
|
},
|
|
|
|
|
Members: make(map[string]*protobuf.CommunityMember),
|
|
|
|
|
}
|
|
|
|
|
_, err = s.m.CreateCommunityChat(c.ID(), chat)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
|
|
|
|
|
community, err := communityManager.GetByID(c.ID())
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
s.Require().Len(community.Chats(), 1)
|
|
|
|
|
|
|
|
|
|
communityDefaultChat, ok := s.m.allChats.Load(community.ChatIDs()[0])
|
|
|
|
|
s.Require().True(ok)
|
|
|
|
|
s.Require().Equal(FirstMessageTimestampNoMessage, int(communityDefaultChat.FirstMessageTimestamp))
|
|
|
|
|
|
|
|
|
|
// prepared community and chat, now start test each case
|
|
|
|
|
// case 1: FirstMessageTimestamp is FirstMessageTimestampNoMessage, so no changes in communityCache
|
|
|
|
|
communityCache := make(map[string]*communities.Community)
|
|
|
|
|
s.m.initChatsFirstMessageTimestamp(communityCache, []*Chat{communityDefaultChat})
|
|
|
|
|
// chat FirstMessageTimestamp is FirstMessageTimestampNoMessage, so no changes in communityCache
|
|
|
|
|
s.Require().Len(communityCache, 0)
|
|
|
|
|
|
|
|
|
|
// case 2: FirstMessageTimestamp is FirstMessageTimestampUndefined,
|
|
|
|
|
// for oldestMessageTimestamp, ok := oldestMessageTimestamps[chat.ID] within initChatsFirstMessageTimestamp
|
|
|
|
|
// now `ok` will be false but 1 change expected in communityCache
|
|
|
|
|
forceFirstMessageTimestampUndefined := func() {
|
|
|
|
|
// force FirstMessageTimestamp to FirstMessageTimestampUndefined so we can still get chats after filterCommunityChats
|
|
|
|
|
communityDefaultChat.FirstMessageTimestamp = FirstMessageTimestampUndefined
|
|
|
|
|
err = s.m.SaveChat(communityDefaultChat)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
}
|
|
|
|
|
forceFirstMessageTimestampUndefined()
|
|
|
|
|
communityCache = make(map[string]*communities.Community)
|
|
|
|
|
s.m.initChatsFirstMessageTimestamp(communityCache, []*Chat{communityDefaultChat})
|
|
|
|
|
s.Require().Len(communityCache, 1)
|
|
|
|
|
|
|
|
|
|
// case 3: FirstMessageTimestamp is FirstMessageTimestampUndefined and send a message,
|
|
|
|
|
// for oldestMessageTimestamp, ok := oldestMessageTimestamps[chat.ID] within initChatsFirstMessageTimestamp
|
|
|
|
|
// now `ok` will be true, `oldestMessageTimestamp`(e.g. 1728886305475) will be greater than 1
|
|
|
|
|
msg := &common.Message{CommunityID: community.IDString(), ChatMessage: &protobuf.ChatMessage{
|
|
|
|
|
Text: "text",
|
|
|
|
|
ChatId: communityDefaultChat.ID,
|
|
|
|
|
MessageType: protobuf.MessageType_COMMUNITY_CHAT,
|
|
|
|
|
ContentType: protobuf.ChatMessage_TEXT_PLAIN,
|
|
|
|
|
}}
|
|
|
|
|
_, err = s.m.sendChatMessage(context.Background(), msg)
|
|
|
|
|
s.Require().NoError(err)
|
|
|
|
|
forceFirstMessageTimestampUndefined()
|
|
|
|
|
communityCache = make(map[string]*communities.Community)
|
|
|
|
|
s.m.initChatsFirstMessageTimestamp(communityCache, []*Chat{communityDefaultChat})
|
|
|
|
|
s.Require().Len(communityCache, 1)
|
|
|
|
|
s.Require().Greater(communityDefaultChat.FirstMessageTimestamp, uint32(1))
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *MessengerSuite) TestFilterCommunityChats() {
|
|
|
|
|
communityChat1 := &Chat{
|
|
|
|
|
ID: "community-chat-1",
|
|
|
|
|
ChatType: ChatTypeCommunityChat,
|
|
|
|
|
FirstMessageTimestamp: FirstMessageTimestampUndefined,
|
|
|
|
|
}
|
|
|
|
|
communityChat2 := &Chat{
|
|
|
|
|
ID: "community-chat-2",
|
|
|
|
|
ChatType: ChatTypeCommunityChat,
|
|
|
|
|
FirstMessageTimestamp: FirstMessageTimestampUndefined,
|
|
|
|
|
}
|
|
|
|
|
nonCommunityChat := &Chat{
|
|
|
|
|
ID: "non-community-chat",
|
|
|
|
|
ChatType: ChatTypeOneToOne,
|
|
|
|
|
}
|
|
|
|
|
communityWithTimestamp := &Chat{
|
|
|
|
|
ID: "community-with-timestamp",
|
|
|
|
|
ChatType: ChatTypeCommunityChat,
|
|
|
|
|
FirstMessageTimestamp: 12345,
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
chats := []*Chat{communityChat1, nonCommunityChat, communityChat2, communityWithTimestamp}
|
|
|
|
|
|
|
|
|
|
filteredChats, filteredIDs := s.m.filterCommunityChats(chats)
|
|
|
|
|
|
|
|
|
|
s.Require().Len(filteredChats, 2, "Should have filtered 2 community chats")
|
|
|
|
|
s.Require().Len(filteredIDs, 2, "Should have 2 community chat IDs")
|
|
|
|
|
|
|
|
|
|
s.Require().Contains(filteredChats, communityChat1, "Should contain communityChat1")
|
|
|
|
|
s.Require().Contains(filteredChats, communityChat2, "Should contain communityChat2")
|
|
|
|
|
|
|
|
|
|
s.Require().Contains(filteredIDs, communityChat1.ID, "Should contain ID of communityChat1")
|
|
|
|
|
s.Require().Contains(filteredIDs, communityChat2.ID, "Should contain ID of communityChat2")
|
|
|
|
|
|
|
|
|
|
s.Require().NotContains(filteredChats, nonCommunityChat, "Should not contain nonCommunityChat")
|
|
|
|
|
s.Require().NotContains(filteredChats, communityWithTimestamp, "Should not contain communityWithTimestamp")
|
|
|
|
|
|
|
|
|
|
s.Require().NotContains(filteredIDs, nonCommunityChat.ID, "Should not contain ID of nonCommunityChat")
|
|
|
|
|
s.Require().NotContains(filteredIDs, communityWithTimestamp.ID, "Should not contain ID of communityWithTimestamp")
|
|
|
|
|
}
|