14dcd29eee
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 |
||
---|---|---|
.. | ||
.gitignore | ||
README.md | ||
main.go | ||
message.go | ||
serve.go | ||
simulate.go | ||
util.go |
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
}'