`status/waku.nim` is an older module that provided just enough waku v2
integration to allow for a test.
This commit modifies it re: the recent nim-waku refactor efforts so that it and
the test for it works correctly.
The module will soon be overhauled by moving the example client's waku
logic (with some adaptations) into `status/waku.nim`.
The example client we're building is more than a "chat" program: it
has (beginnings of) support for wallets and eventually the full range of
capabilities implemented in nim-status.
Rename `examples/chat.nim` to `examples/client.nim` and make a number of
related changes/renamings that help to make it more clear that the example
client is a "client in general", not just a chat client.
Also, put the copied example waku chat2 code under `examples/waku/`.
The name of the repo is not being changed. But instead of doing:
```nim
import nim_status
```
You would do:
```nim
import status
```
This is in line with nim-chronos (`import chronos`), nim-waku (`import waku`),
and many other Nim libs.
Copy protobuf specs from status-go, make necessary adjustments for use via
nim-protobuf-serialization. Many thanks to @richard-ramos for his help with
this aspect and others!
Implement "first steps" towards encoding and decoding Status payloads when
sending and receiving messages.
That consists of using an incomplete
`ProtocolMessage(ApplicationMetadataMessage(ChatMessage)))` wrapping of
messages, assuming all messages currently being sent correspond to public
chats. It's incomplete because there are many fields for which values are not
being derived, and there is no encryption performed.
A series of future pull requests will fill in the missing pieces and expand our
usage of the protobuf specs, i.e. allow nim-status to send and receive more
kinds of Status messages.
Note that the waku v2 content topics are not yet using a hash of the
user-supplied topic name; that will also be addressed in a future pull request.
It's also important to note that a refactor is pending re: moving the import
and usage of nim-waku inside the `nim_status` library, as well refactorings re:
exception handling, imports and exports, and other aspects that have been
commented upon in other recent pull requests. This commit builds on the work
done to date in the same way as before, but there is already awareness of what
should be changed and can be improved.
Ensure that joined waku v2 content topics (whether joined in the TUI or
specified on the command-line) conform to the recommendations in
[23/WAKU2-TOPICS](https://rfc.vac.dev/spec/23/).
Unrelated to the main focus of this commit: use a fixed-length array instead of
a sequence for collecting bytes of user input (keyboard and mouse) in the
`input` worker thread. It's more efficient to do it that way: less allocation
and garbage collection.
---
Closes#217.
Closes: #224.
Allows a user to import a wallet account via 12-word mnemonic seed.
The account is first imported in the account generator. Then a wallet account is derived at the root wallet path (m/44'/60’/0’/0/0) from the master key of the mnemonic. This account is then stored in the Accounts table of the user’s db.
Add funcs to support importing a wallet account via private key.
Support password validation before importing the keystore file. Prevent duplicate keystore files from being imported.
Add keystore file unit tests for storing and loading of key files
Add import wallet pk command to example chat client
Refactor web3_conversions imports to insteaad import `nim_status/conversions`.
Closes: #214, #215.
Almost all the work for #197 is included in this PR.
Generate a new wallet account using `/add`, `/addaccount`
feat: create settings when creating/importing a login account
When creating or importing a new account (a login account, not a wallet account), settings are now created.
feat: list wallet accounts
Wallet accounts can be listed using `/wallets`, `/listwalletaccounts`, and `/listwallets`. This gets all accounts in the user db that are not chat accounts. It would be much better to store all wallet accounts in the db using the `wallet` flag, however status-go did not do this, reserving that flag for the root wallet account and creating a unique db constraint on that column.
Closes: #204Closes: #205
feat: insert accounts in user db during create account
feat: insert accounts in user db during import mnemonic
1. This only handles `createAccount`. No other parts of CRUD are handled yet.
Closes: #199
Some functions in `nim-status` were attempting to do too much in comparison to their `status-go` counterparts. The filesystem in `nim-status` varied quite a lot from the filesystem in `status-go`, which made comparing functions difficult. The end result was that certain cryptographic operations, such as generating a `keyUid` did not match between `nim-status` and `status-go`.
This PR fixes this problem by first moving some account generation files around in the filesystem to more closely mirror `status-go`. Then, the account generation functions from `status-go` were ported over to `nim-status` and the example chat client was changed to use these new functions.
Once the port from `status-go` had been completed, it could be more clearly seen that the cause of the `keyUid` mismatch was due to the use of `nim-eth`’s `PrivateKey` type over `secp256k1`’s `SkPrivateKey`. `nim-eth` does not include the `0x04` prefix that `secp256k1` uses, because `nim-eth` is more focused on ethereum implementations which do not need the prefix. Switching `PrivateKey` (in `nim-eth`) to `SkPrivateKey` (in `secp256k1`) and `PublicKey` to `SkPublicKey` allowed the `keyUid` generation to match between `nim-status` and `status-go`.
There was also some confusion between two different `Account` types in the codebase. One `Account` type was for public consumption and stored in the unencrypted accounts db. The other `Account` type contained private keys and was meant to be stored in the encrypted user db. The public `Account` type was changed to `PublicAccount` to avoid confusion.
Other notable changes include:
- chore(nim-status): Keccak 256 hash the plain text db password before keying the db.
- feat(ex-client): Move the db interactions to the nim-status client instead of doing all of it in the task.
- chore(ex-client): Remove `bip32passphrase` from `/import` arg and assume an empty string for now.
### Todo:
1. Adjust `derive` to use hardened children. This can be shown in the “derive address from imported key” test that fails when uncommented. [An issue has been created for this]([https://github.com/status-im/nim-status/issues/211](https://github.com/status-im/nim-status/issues/211))
Reshuffle and organise files to resemble how status-go has organised its files. This helps to not confuse migration efforts and reorganises some nim-status code that was not well organised.
refactor: accounts.Account -> PublicAccount
Add support for the `/help` command, which dynamically builds a list of help commands based on the `help()` procs defined for each command type, ie `Login`.
The `help` proc returns a type of `HelpText`, which contains all the information necessary to render help information for that command. It contains the command, parameters (each parameters contains a name and description), aliases, and a description.
The help text is generated (at compile time) by a macro called `buildCommandHelp()`. Once the `/help` command is executed, the output of `buildCommandHelp()` is passed to the task runner so that a `HelpResult` event can be created and the help text can be displayed on screen. Because the text is generated at compile time, it is not necessary to pass this text through the task runner, and is displayed directly on screen in the main thread.
## NOTES
1. The help text is quite long, especially given there are blank spaces in between each command. This would require the chat client to be able to scroll unless it is sufficiently tall.
2. I am not married to the display output at all, even after experimenting with a few different layouts. There is some leftover rendering code in the `HelpResult` action which allows for the the command description to be written on the same line as the command name and keep the description spaced in line with all other descriptions, but it didn’t appear as readable as the format that I settled on in the end. I left it in there in case we wanted to change up how help is rendered.
A few uses remain:
* In `examples/waku_chat2.nim`; that code was copied from nim-waku and is only
for reference.
* In `chat/client/tasks.nim`, where the signature of
`proc statusContext*(arg: ContextArg)` is intended to match `type Context` of
`examples/chat/task_runner/tasks.nim` but we know the argument passed to it is
actually of `type StatusArg`.
* In multiple modules within `examples/chat/task_runner/`, where casting plays
a role in de/serializing data sent across instances of `AsyncChannel`, and
resolving the correct type of worker (thread or pool) per `kind` metatdata
tracked as part of worker creation.
Closes: #180.
Closes: #177.
Closes: #184.
Accounts can be created with the `/create` or `/createaccount` command. Existing accounts can be listed with the `/list` or `/listaccounts` command.
Account keyuid is now being generated on the multiaccount.
account.loginTimestamp is now NULL when inserted in the DB, and can be updated using `updateAccount` or `updateAccountTimestamp`.
fix: run migrations only on non-existant DBs
Removes the need to pass in a migration definition file. We do not need to run migrations, unless we are instantiating a DB.
Using a full matrix of static/shared linking has been useful in the past for
catching edge cases, but none have been experienced in recent months so limit
to static linking to reduce build and run times in this workflow. The full
matrix can always be activated in a PR branch if it's suspected we're bumping
into an edge case as experienced previously.
See: https://github.com/msys2/MINGW-packages/issues/9010
Also remove a previous workaround re: Rust in MSYS2/MINGW64 on Windows that's
no longer necessary.
And cleanup implementation of a workaround re: the `ar` utility on macOS,
i.e. do it the same way using an `if..fi` block.