status-go/cmd/status-cli
shashankshampi 14dcd29eee test_: Code Migration from status-cli-tests
author shashankshampi <shashank.sanket1995@gmail.com> 1729780155 +0530
committer shashankshampi <shashank.sanket1995@gmail.com> 1730274350 +0530

test: Code Migration from status-cli-tests
fix_: functional tests (#5979)

* fix_: generate on test-functional

* chore(test)_: fix functional test assertion

---------

Co-authored-by: Siddarth Kumar <siddarthkay@gmail.com>

feat(accounts)_: cherry-pick Persist acceptance of Terms of Use & Privacy policy (#5766) (#5977)

* feat(accounts)_: Persist acceptance of Terms of Use & Privacy policy (#5766)

The original GH issue https://github.com/status-im/status-mobile/issues/21113
came from a request from the Legal team. We must show to Status v1 users the new
terms (Terms of Use & Privacy Policy) right after they upgrade to Status v2
from the stores.

The solution we use is to create a flag in the accounts table, named
hasAcceptedTerms. The flag will be set to true on the first account ever
created in v2 and we provide a native call in mobile/status.go#AcceptTerms,
which allows the client to persist the user's choice in case they are upgrading
(from v1 -> v2, or from a v2 older than this PR).

This solution is not the best because we should store the setting in a separate
table, not in the accounts table.

Related Mobile PR https://github.com/status-im/status-mobile/pull/21124

* fix(test)_: Compare addresses using uppercased strings

---------

Co-authored-by: Icaro Motta <icaro.ldm@gmail.com>

test_: restore account (#5960)

feat_: `LogOnPanic` linter (#5969)

* feat_: LogOnPanic linter

* fix_: add missing defer LogOnPanic

* chore_: make vendor

* fix_: tests, address pr comments

* fix_: address pr comments

fix(ci)_: remove workspace and tmp dir

This ensures we do not encounter weird errors like:
```
+ ln -s /home/jenkins/workspace/go_prs_linux_x86_64_main_PR-5907 /home/jenkins/workspace/go_prs_linux_x86_64_main_PR-5907@tmp/go/src/github.com/status-im/status-go
ln: failed to create symbolic link '/home/jenkins/workspace/go_prs_linux_x86_64_main_PR-5907@tmp/go/src/github.com/status-im/status-go': File exists
script returned exit code 1
```

Signed-off-by: Jakub Sokołowski <jakub@status.im>

chore_: enable windows and macos CI build (#5840)

- Added support for Windows and macOS in CI pipelines
- Added missing dependencies for Windows and x86-64-darwin
- Resolved macOS SDK version compatibility for darwin-x86_64

The `mkShell` override was necessary to ensure compatibility with the newer
macOS SDK (version 11.0) for x86_64. The default SDK (10.12) was causing build failures
because of the missing libs and frameworks. OverrideSDK creates a mapping from
the default SDK in all package categories to the requested SDK (11.0).

fix(contacts)_: fix trust status not being saved to cache when changed (#5965)

Fixes https://github.com/status-im/status-desktop/issues/16392

cleanup

added logger and cleanup

review comments changes

fix_: functional tests (#5979)

* fix_: generate on test-functional

* chore(test)_: fix functional test assertion

---------

Co-authored-by: Siddarth Kumar <siddarthkay@gmail.com>

feat(accounts)_: cherry-pick Persist acceptance of Terms of Use & Privacy policy (#5766) (#5977)

* feat(accounts)_: Persist acceptance of Terms of Use & Privacy policy (#5766)

The original GH issue https://github.com/status-im/status-mobile/issues/21113
came from a request from the Legal team. We must show to Status v1 users the new
terms (Terms of Use & Privacy Policy) right after they upgrade to Status v2
from the stores.

The solution we use is to create a flag in the accounts table, named
hasAcceptedTerms. The flag will be set to true on the first account ever
created in v2 and we provide a native call in mobile/status.go#AcceptTerms,
which allows the client to persist the user's choice in case they are upgrading
(from v1 -> v2, or from a v2 older than this PR).

This solution is not the best because we should store the setting in a separate
table, not in the accounts table.

Related Mobile PR https://github.com/status-im/status-mobile/pull/21124

* fix(test)_: Compare addresses using uppercased strings

---------

Co-authored-by: Icaro Motta <icaro.ldm@gmail.com>

test_: restore account (#5960)

feat_: `LogOnPanic` linter (#5969)

* feat_: LogOnPanic linter

* fix_: add missing defer LogOnPanic

* chore_: make vendor

* fix_: tests, address pr comments

* fix_: address pr comments

chore_: enable windows and macos CI build (#5840)

- Added support for Windows and macOS in CI pipelines
- Added missing dependencies for Windows and x86-64-darwin
- Resolved macOS SDK version compatibility for darwin-x86_64

The `mkShell` override was necessary to ensure compatibility with the newer
macOS SDK (version 11.0) for x86_64. The default SDK (10.12) was causing build failures
because of the missing libs and frameworks. OverrideSDK creates a mapping from
the default SDK in all package categories to the requested SDK (11.0).

fix(contacts)_: fix trust status not being saved to cache when changed (#5965)

Fixes https://github.com/status-im/status-desktop/issues/16392

test_: remove port bind

chore(wallet)_: move route execution code to separate module

chore_: replace geth logger with zap logger (#5962)

closes: #6002

feat(telemetry)_: add metrics for message reliability (#5899)

* feat(telemetry)_: track message reliability

Add metrics for dial errors, missed messages,
missed relevant messages, and confirmed delivery.

* fix_: handle error from json marshal

chore_: use zap logger as request logger

iterates: status-im/status-desktop#16536

test_: unique project per run

test_: use docker compose v2, more concrete project name

fix(codecov)_: ignore folders without tests

Otherwise Codecov reports incorrect numbers when making changes.
https://docs.codecov.com/docs/ignoring-paths

Signed-off-by: Jakub Sokołowski <jakub@status.im>

test_: verify schema of signals during init; fix schema verification warnings (#5947)

fix_: update defaultGorushURL (#6011)

fix(tests)_: use non-standard port to avoid conflicts

We have observed `nimbus-eth2` build failures reporting this port:
```json
{
  "lvl": "NTC",
  "ts": "2024-10-28 13:51:32.308+00:00",
  "msg": "REST HTTP server could not be started",
  "topics": "beacnde",
  "address": "127.0.0.1:5432",
  "reason": "(98) Address already in use"
}
```
https://ci.status.im/job/nimbus-eth2/job/platforms/job/linux/job/x86_64/job/main/job/PR-6683/3/

Signed-off-by: Jakub Sokołowski <jakub@status.im>

fix_: create request logger ad-hoc in tests

Fixes `TestCall` failing when run concurrently.

chore_: configure codecov (#6005)

* chore_: configure codecov

* fix_: after_n_builds
2024-10-30 14:49:26 +05:30
..
.gitignore fix_: minor change to log message id (#5309) 2024-06-07 13:17:49 +03:00
README.md feat(cli)_: add a command 'server-account' to be able to re-run existing accounts (#5329) 2024-06-12 11:00:51 +03:00
main.go feat(telemetry)_: publish peerId (#5534) 2024-07-31 20:27:43 -07:00
message.go feat_: call telemetry upon error pushing envelope (#5430) 2024-06-28 13:24:04 +03:00
serve.go chore_: check mvds for tests (#5928) 2024-10-09 09:23:15 +03:00
simulate.go chore_: add fleet flag to cli (#5478) 2024-07-04 09:15:58 +03:00
util.go test_: Code Migration from status-cli-tests 2024-10-30 14:49:26 +05:30

README.md

Status CLI

The Status CLI is a command line interface for interacting with the Status messenging process. It is a tool for developers and QAs to test the communication workflow without running Status desktop and mobile app.

Features

  • Create a new account
  • Send and receive contact request
  • DM between contacts

Build

Go to cmd/status-cli directory and build the binary

go build

You can also run make status-cli in the root directory to build the binary.

Run

Run serve command:

# run alice's server
./status-cli serve

# run charlie's server in another terminal with the logged pubkey of Alice
./status-cli serve -n charlie -p 8565 -a <alice-pubkey>

You can send direct messages through JSON RPC. If you also want to send messages through terminal enable interactive mode (with the -i flag)

JSON RPC examples:

# get waku info
curl -XPOST http://127.0.0.1:8545 -H 'Content-type: application/json' -d '{"jsonrpc":"2.0","method":"waku_info","params":[],"id":1}'

# get peer info
curl --request POST --url http://127.0.0.1:8545 --header 'Content-type: application/json' --data '{"jsonrpc": "2.0", "method": "wakuext_peers", "params": [], "id": 1}'

# send contact request from charlie to alice (use -a flag will automatacally send contact request when starting)
curl -XPOST http://127.0.0.1:8565 -H 'Content-type: application/json' -d '{"jsonrpc":"2.0","method":"wakuext_sendContactRequest","params":[{"id": "0x0436470da23039f10c1588bc6b9fcbd4b815bf9fae4dc09c0fb05a7eaaf1670b5dbdbc757630d54bf2f8be45a796304dc42506c3f4172f499f610a9ed85d9b0d4c", "message": "hello"}],"id":1}'

# send dm from charlie to alice
curl -XPOST http://127.0.0.1:8565 -H 'Content-type: application/json' -d '{"jsonrpc":"2.0","method":"wakuext_sendOneToOneMessage","params":[{"id": "0x0436470da23039f10c1588bc6b9fcbd4b815bf9fae4dc09c0fb05a7eaaf1670b5dbdbc757630d54bf2f8be45a796304dc42506c3f4172f499f610a9ed85d9b0d4c", "message": "how are you"}],"id":1}'

# send dm from alice to charlie
curl -XPOST http://127.0.0.1:8545 -H 'Content-type: application/json' -d '{"jsonrpc":"2.0","method":"wakuext_sendOneToOneMessage","params":[{"id": "0x042c0ce856c41ad6d3f651a84c83f646cdafdf3a26a3d69bce3a6ccf59b23b5a366c12162045d5066abad7912741a6e6c6e8e11e7826c4c850a1de7a2bae24a79c", "message": "Im fine, and you?"}],"id":1}'

Run serve-account command

The ./status-cli serve command will generate a new account, it will print in the console the key UID of that account, if you want to re-run that created account (i.e.: run the account with the same public key), you can do so with this command:

./status-cli serve-account -n alice -kid 0x02887ff8dddb774ad836c00c8fd30ef9bc45d6b23f1f8cad1bff07d09cb378c3

You will need the same name and key

Run simulate command

# simulate DM between two accounts
./status-cli simulate

# simulate DM in a interactive way
./status-cli simulate -i

# simulate DM with 3 messages
./status-cli simulate -c 3

# run in light mode
./status-cli simulate --light

You can run the commands with --light to work as a light client.

Logs are recorded in file *.log and terminal.

JSON-RPC use cases

Start two CLIs adding each other as contacts

# terminal 1 (alice)
./status-cli serve -n alice -p 5500
# note the public key and the key id from the output

# terminal 2 (bobby)
./status-cli serve -n bobby -p 5501 -a <alice_pub_key>

Restart any existing account

# notice we need both the name and the key id (not the pub key here)
# the key id will be pressent in the logs when a new account is created, same as the public key
./status-cli serve -n bobby -kid <bob_key_id>

Create community

Have two CLIs running (alice and bobby)

# 1. (alice) create community
# this call will return the community id
curl --request POST \
  --url http://127.0.0.1:5500/ \
  --header 'Content-type: application/json' \
  --data '{
 "jsonrpc": "2.0",
 "method": "wakuext_createCommunity",
 "params": [
  {
   "membership": 3,
   "name": "cli-test-1",
   "color": "#ffffff",
   "description": "cli-test-1"  
  }
 ],
 "id": 1
}'

# 2. (bobby & alice) fetch community (use communityId from step 1 response)
curl --request POST \
  --url http://127.0.0.1:5501/ \
  --header 'Content-type: application/json' \
  --data '{
 "jsonrpc": "2.0",
 "method": "wakuext_fetchCommunity",
 "params": [
  {
   "communityKey": "0x02bea5af5779d5f742f2419cc0d819d3ce33adb922e8e90bdf3533fd121d52d4bc",
   "waitForResponse": true,
   "tryDatabase": true
  }
 ],
 "id": 1
}'

# 3. (bobby) request to join community (use communityId from step 1 response)
# this call will return the requestsToJoinCommunity.id
curl --request POST \
  --url http://127.0.0.1:5501/ \
  --header 'Content-type: application/json' \
  --data '{
 "jsonrpc": "2.0",
 "method": "wakuext_requestToJoinCommunity",
 "params": [
  {
   "communityId": "0x02bea5af5779d5f742f2419cc0d819d3ce33adb922e8e90bdf3533fd121d52d4bc"
  }
 ],
 "id": 1
}'

# 4. (alice) accept request to join community from bobby (use requestsToJoinCommunity.id from step 3 response)
# in the response you can see the community id and the chats' ids for that community ($.result.communities[*].chats[*].id)
curl --request POST \
  --url http://127.0.0.1:5500/ \
  --header 'Content-type: application/json' \
  --data '{
 "jsonrpc": "2.0",
 "method": "wakuext_acceptRequestToJoinCommunity",
 "params": [
  {
   "id": "0x1b828fe8c778403268ffcf80b892f8be46cf9a85ba2c9f479bfb0c0a807a71f4"
  }
 ],
 "id": 1
}'

# 5. (alice) send chat message (bobby should receive it)
# chatId is the community id concatenated to the chat id (from step 4 response)
curl --request POST \
  --url http://127.0.0.1:5500/ \
  --header 'Content-type: application/json' \
  --data '{
 "jsonrpc": "2.0",
 "method": "wakuext_sendChatMessage",
 "params": [
  {
   "chatId": "0x02bea5af5779d5f742f2419cc0d819d3ce33adb922e8e90bdf3533fd121d52d4bcdfe601d1-096c-4201-b692-fcdb81ef0cec",
   "text": "hello there",
   "contentType": 1
  }
 ],
 "id": 1
}'

# 6. (bobby) leave the community (use communityId from step 1 response)
curl --request POST \
  --url http://127.0.0.1:5501/ \
  --header 'Content-type: application/json' \
  --data '{
 "jsonrpc": "2.0",
 "method": "wakuext_leaveCommunity",
 "params": [
  "0x02bea5af5779d5f742f2419cc0d819d3ce33adb922e8e90bdf3533fd121d52d4bc"
 ],
 "id": 1
}'

# Optional:
# 7. (bobby & alice) fetch community again and verify the members (curl from step 2.)
# 8. Instead of creating a community always you can restart alice and bobby and proceed from step 2. Alice is the owner

Private group chat

Have two CLIs running (alice and bobby)

# 1. (alice) create the group chat including bobby's public key in it, 
# the response will have the group chat id to send messages to it
curl --request POST \
  --url http://127.0.0.1:8545/ \
  --header 'Content-type: application/json' \
  --data '{
 "jsonrpc": "2.0",
 "method": "wakuext_createGroupChatWithMembers",
 "params": [
  null,
  "group-chat-name",
  [
   "0x04d3c86dfc77b195b705e1831935066076018aa0d7c40044829801ebbfe9b06480ce4662072bf16a3ca7cb8f6289207614deceaf7d33e099dfc9281610375fec08"
  ]
 ],
 "id": 1
}'

# 2. (alice) send the message to the id of the group chat (from step 1 response)
curl --request POST \
  --url http://127.0.0.1:5500/ \
  --header 'Content-type: application/json' \
  --data '{
 "jsonrpc": "2.0",
 "method": "wakuext_sendGroupChatMessage",
 "params": [
  {
   "id": "8291eae1-338c-4481-9997-04edd2d2bbed-0x0490cbce029eaf094c7f2dcf1feb2d60e91ab1498847eb29fa98cc5ea5a36666b3f9ada142f3080f5074abd942c863438f6af9475f30781790c7e36f9acd2ac93e",
   "message": "hello"
  }
 ],
 "id": 1
}'