nimiq / hub Goto Github PK

A website should be able to request an address from a user to use. This request should accept an optional parameter to require a proof of ownership of that address (through a signed message via the Keyguard).

In the checkout flow, the initial overview screen and the success screen (after the transaction was signed) are missing.

The login success screen currently overwrites an existing wallet and re-detects new accounts and assigns a default wallet label and account labels to an imported wallet. However, if a user reimports a wallet, his existing accounts and labels should be used instead of overwriting them.

• selection: keyguard or ledger
• call keyguard
• receive answer from keyguard
• choose label
• success screen with info about what happened
• ledger wallets

For the checkout flow, the AccountsManager receives only the most basic data about a transaction, such as recipient, amount, data. All other things, like the sender, fee and validityStartHeight needs to be added by the AccountsManager itself, before being able to sign it via the Keyguard.

Now, I don't want users to have to wait for consensus before signing the transaction (because they have to wait for it afterwards when relaying the transaction, too), so I suggest getting the current blockchain height from various independant APIs (nimiq.watch, nimiqx, nimiqo, mopsus come to mind initially) and comparing them. If they agree with each other within 1 or 2 blocks, then take the lower one. If they are further apart than a certain number of blocks, fall back to network.

This would be magnitutes of times faster than having to wait for consensus, which can 1. take a long time on spotty internet connection and 2. freeze the interface for a couple seconds.

What do think?

Safeguard against potentially skipped database writes: nimiq/keyguard#125

We only support the ImageWallet format going forward, which is not compatible with legacy single-account wallets.

Enable to user to add a new account to their wallet, including labeling.

Explore whether createKeyguardClient in RpcApi can reuse _keyguardClient

E.g. "cancel payment" at the bottom. This is because currently it just calls window.close(), which is not allowed in redirect case. (Chrome 69)

Enable the user to rename wallets and accounts.

When the AccountsManager iframe's list() method is called to list available keys, the AccountsManager must also call the Keyguard's list() method to be sure all returned keys are actually available.

Furthermore, the AccountsManager should check after create() and import() calls as well, if the key has actually been stored.

The user should be able to change an existing passphrase for a wallet and also set a passphrase for non-encrypted wallets.

Current content of "prebuild" folder was copied there manually. We should find a better way how to import code we need for demos.

After having the keyguard signed a transaction in the checkout flow, show transaction details again and animate success message after successful transmission to the network.

First visible render is only after Vue and essentially the whole app has loaded, which takes a long time on slower internet connection. The loading spinner should already be visible instantly.

Integrate the browser warnings script we usually use to display warnings on outdated browsers, private tabs, etc..
Note that this should not be bundled into the main bundle to be able to run on old browsers that can not parse the main bundle due to syntax errors.

Maybe @Bettelstab could be interested in setting this up in webpack?

The newest revision of that script is in the getsome / onboarding app.
At this point we should probably also consider providing the browser-warnings via an own npm package.

Somehow the data url is different from the source.

Instead of just by balance.

Apply new Nimiq styling, can use https://github.com/nimiq/nimiq-style.

Notify caller when window is closed by user

Legacy keys (key-accounts before key derivation) must be able to be imported, displayed, selected, used, removed, exported.

(vue-components)

Cookies...?

We should try to detect adblockers and ask users to disable them.

On mobile device, onboarding component is broader then the Screen.

The first page of the checkout flow enables the user to select which login and account to use to pay. The case where no key is yet stored, is not yet covered.

A way to let the user import a key (from file or words) needs to be provided, after which the checkout flow should proceed regularily.

Exchanges mostly only guarantee an exchange rate for a certain amount of time. Thus a merchant should be able to set for how many blocks (~minutes) a transaction should be valid.

We would then use this to offset the validityStartHeight of the transaction.

Page and content layout needs to be adapted for screens smaller than 460px.

Disable ‘back to safe’ if there is no account.
How: probably as request parameter. Or always?

• Checking existing repos and how to do it best.

Resulting tasks:

• Adapting Boruca Messaging Lib to new @nimiq/rpc library.
• Checking @nimiq/network API.
• Integrating @nimiq/network into @nimiq/accounts.

Enable the user to "log out", to remove a wallet from their device.

After creating a new wallet, the user should be able to change the default values for the wallet and first-account label

Should we put RpcClient and RpcServer in a npm package? Or in a common library submodule?

The Keyguard client is affected by nimiq/rpc#5.

This happens when using a request that is directly handed through the accounts manager to the keyguard.

That way we would avoid nimiq/safe#52

Edit: While this might be a good behaviour for Safe, it might not for other apps (esp. ones with a useable logged out state). So better let the app handle this.

If a wallet was deleted in the Keyguard not through the accounts manager but for example by the browser, flag it as deleted in the accounts manager but keep the database entry such that the user doesn't lose his labels and can reimport the key with his old labels.

Accounts should use standardised errors, like keyguard.

Both wallet and account labels should be restricted to 63 bytes (not 64, to be able to store it in 6 bits while keeping the possibility of having a 0 length (which would then correspond to default labels)).

Note: 63 bytes does not mean 63 characters, as non-ascii characters can be multi-byte. Javascript's String.length is also not usable, as JS uses a 16-bit encoding, not 8-bit, and may thus report a shorter string length than would be in bytes.

Only relevant for 'loading'. 'Nimiq' should be put into the logo SVG.
CSS Font Loading is a W3C working draft, but well supported.
How to do it: see https://dev.opera.com/articles/better-font-face/#font-loading-events