Modals that get rendered in bulk should be grouped together in their containing page.

• Wallet edit modal - wallets table
• Wallet info modal - wallets table
• Send tx modal - wallets table
• Send tx modal - names table
• Update name modal - names table
• Transfer name modal - names table

Perhaps look into using the modal hooks instead.

• Lowest block hashes
• Money supply?
• % of Krist owned?
• Name purchases have increased block value for x blocks
• Transaction volume, krist mined over time

I knew I forgot something

I just made a krist wallet on kristweb and dont know how to initialize it, could anyone please help?

The 'Recent Transactions' card on the AddressPage does not auto-refresh at all currently. Conversely, an address's transactions table will auto-refresh even for unrelated events. Both of these are caused by the fact that there's currently no way to get a lastTransactionID for an individual address. There needs to be a way to subscribe to an address's (and other data types) last transaction IDs.

The current idea I have in mind is a new hook, which uses useSelector under the hood. When mounted, it sends a message to the WebsocketService (maybe via the Context API?) to add a subscription for an address. When unmounted, it removes said subscription. A Redux store can contain a map of these subscriptions, and the useSelector hook can just fetch that refresh ID. The initial state doesn't matter; zero is fine, it will only increment when it changes, thus triggering a refresh.

To handle multiple subscriptions, it'd probably be best to give each subscription a UUID. Then, the useSelector hook can just subscribe to its own UUID, and the WebsocketService can remove that UUID when unmounted. This would allow two different components to subscribe to the same address at different times and unmount/unsubscribe at different times.

Now that simbathesailor/babel-plugin-use-what-changed#14 was merged

Remove linkify dependency

kristweb:backup-import beginning import

When editing a wallet and changing its category to a new one, that new category does not appear in the other wallets in the table until the table is refreshed. Possibly happens in other cases too. Something probably wrong with the hook/dependencies for getting the categories; maybe add a useCategories hook?

Currently the whole SyncWork routine runs every time a block is mined, which triggers a /work/detailed request. The request is pretty cheap, but it might be good to try and avoid it unless necessary (i.e. unless the 'dashboard' page is open). Should be trivial with a useEffect hook with the lastBlockID as a dependency.

Honestly, SyncWork can probably just be moved into the Dashboard page instead of being a global service component.

Adding new contacts to adress book in unverified state don't require main password verification. It just adds them then asks to verify password when trying to edit one.

Use history API to store pagination state, sorters and filters in the history stack?

Perhaps hide .nyi

https://www.richsnapp.com/article/2019/06-09-reduce-spread-anti-pattern

Disable wrapping within a single hint, but allow wrapping multiple hints

This is probably true for other links (e.g. the sidebar) too; currently clicking the settings icon multiple times will push an item to the history stack for each click, which means that you have to click the browser back button (or the page header back button) n times to get back to where you were. There seems to be a lot of different ways to solve this issue, most of them revolving around disabling the link when you're already on that route (see <NavLink>). Further reading: remix-run/react-router#5362

Need to do some prop merging. See NamePage's aRecordEditTooltip

Instead, defer SyncWallets to after websocket is connected, and just use the single batch request. The single-wallet updates are too much of a performance hit with 20+ wallets

As KristWeb v2 is becoming more mature, I'm now ready to begin accepting translations again. In terms of completion, I'd say en.json contains around 75% of the keys that a 2.0 release needs. While that means that translations contributed now will still need to be updated again before release, updating them now provides a lot of time to work on them. Shipping with full translations is not necessary for release, but I think it would be a great added bonus for the maturity of the application, as well as accessibility.

Contributing translations is entirely voluntary, but your help in updating them would be much appreciated.

Updating your translations

I haven't yet made a tool to merge locale JSON files, however there is a CSV containing each language and the keys/missing keys. The missing keys (sourced from en_GB, ignoring plurals) are merged into each language. As well as this, there is always the en.json file as a reference.

I tried to keep the pre-existing translations as stable as possible during the rewrite, however a few now-unused keys were removed due to a change in features. From today onwards, all existing keys are considered stable, and will not be removed. Any text that requires changing will instead receive a new key (e.g. intro2 to replace intro).

The following keys have been removed from en.json:

• sidebar.guestIndicator - The 'guest' system has been removed
• masterPassword.browseAsGuest - The 'guest' system has been removed
• masterPassword.intro - The master password system was reworked. Superseded by masterPassword.intro2.
• masterPassword.dontForgetPassword - The text is no longer relevant, though a new key with similar text may be added in the future.
• masterPassword.loginIntro - No longer relevant.
• masterPassword.helpWalletStorage - The text was outdated, and a new key with similar text will be added in the future.

There's a few things to note about the translation system:

Localised numbers (new!)

Interpolated numbers can now be localised directly in the locale file. Almost every number in KristWeb uses this function now, so that numbers will be formatted with thousands-separators in English (e.g. 1000 -> 1,000). The behaviour of this localisation will depend on the system, not on the chosen language (may change in the future). A localised number interpolation may look like this:

    "nameCount": "{{count, number}} name",
    "nameCount_plural": "{{count, number}} names",

<Trans> substitutions

You're likely already familiar with this, but across the locale files, there are substitutions that look like <1 /> or <1>Contents</1>. These refer to React components that are part of the translation string. You are allowed to re-order them, place text before or after them, etc., but do not change the numbering. The number is part of the source code. Additionally, the tags may optionally contain contents; you are allowed to translate this. Examples:

    "blockValueBaseValue": "Base value (<1></1>)",
    "blockValueNextDecrease": "Decreases by <1></1> in <3>{{count, number}} block</3>",
    "blockValueNextDecrease_plural": "Decreases by <1></1> in <3>{{count, number}} blocks</3>",
    "blockDifficultyHashRate": "Approx. <1 />",

Locale files and languages.json moved

The locale files are now located in public/locales/{lang}.json, instead of in a subdirectory for each language. The languages.json file, which contains a list of all languages, is now located in src/__data__/languages.json. You no longer need to edit utils/i18n.ts to add a language.

Testing your translations

If you have access to the KristWeb v2 private beta, then you can test the translations directly on the live beta. Head to Settings -> Debug settings -> Translations to see the i18n debug page, which allows you to track the progress for each language. Then, click Import JSON or drag a locale file anywhere on the page to import your locale file. The existing locale will be replaced, though your language will revert back to English on the next page reload.

If you really need hot-reloading, and don't mind spending some time compiling the project, then check the private repo in tmpim for installation instructions (DM me on Discord for further information).

As usual, when you are done, you can either send me the updated translations file, send a PR, or push straight to master. Feel free to ask any questions here, or on Discord.

These errors are extremely unlikely to appear, but it's important to know that if they did, they would silently appear nowhere (probably even trigger an UncaughtPromiseException). This function needs to be wrapped in an error handler too.

The same may be true for NameEditModal.

The debug logs are never visible unless you explicitly turn them on with a console command, but it's probably time to start trimming some of them down.

I believe the editing initialValues and password population could be grouped together

• Move wallet storage to IndexedDB (#41)
• Move contact storage to IndexedDB (#41)
• Bulk encryption/decryption on web worker
• Websocket connection on web worker
• Main wallet fetching on web worker

I think this will usually be ignorable because, as far as I can think of, the modal won't be triggerable unless you have a wallet and an owned name. But, just in case, it should be checked for.

Its neither YYYY/MM/DD HH:mm:ss nor is it a relative time. Instead it seems to always be in local absolute time format.

Disable it with a tooltip saying "Transactions cannot be sent to v1 addresses, as they have been deprecated."

now can be used to provide the current date; perhaps the server time can be used to sync?

1. Visit https://krist.club/network/addresses/k64shopdmi (or any other address that has a name which it did not originally own)
2. Look at Names

If the "3 years ago" is intended there it might be worth prepending "Registered" to the duration there so it would look like "Registered 3 years ago"

Currently, /me/transactions and /me/names will list the network transactions/names if you have no wallets saved. They should probably show "No Data" instead, perhaps a result screen that says "Add some wallets first!"

Perhaps also make table columns larger to fit potentially larger date formats

This is a feature request. You should have an option to have recurring payments from your own wallet to another wallet (say a subscription based shop).

Everything on my computer is set to light mode, everything matches except Kristweb, I can't find the light mode option if there is one, please add this :)

This is caused by these lines:

I think the WebsocketConnection should temporarily decrement or increment the name counter for each applicable wallet, and have a per-address throttled sync (same as the balance syncing is currently) to get the 'eventually consistent' name count.

Not really sure what's happening here:

Transaction http://localhost:3000/network/transactions/2009082

Side-note; I don't think contextual addresses use sent_name/sent_metaname yet, would probably be improved if it did

You asked me to make an issue here lol

The wallet table overlaps the page header at some smaller screen widths. Obviously the tables will eventually have unique mobile views, but for the time being this should at least be fixed. Perhaps make the tables able to scroll horizontally when they absolutely must?

See kfyu on dev node