Update functional_requirements.md #22
Conversation
| @@ -4,7 +4,7 @@ This document maintains functional requirements for the Haveno user interface. | |||
|
|
|||
| ### Startup | |||
| - On first startup, the user must configure a password. | |||
| - On first startup, the user can use a local node or configure a remote node (url, username, password). | |||
| - On first startup, the user can use a local node or configure a remote node (url, username, password). (Need specificity, what kind of node, haveno daemon, monero node?) | |||
There was a problem hiding this comment.
This was referring to a Monero node.
But actually maybe it's better to simply default to the provided set, and allow them to customize the node afterwards.
There was a problem hiding this comment.
We should keep it simple perhaps, have some trusted community nodes, have it randomly select among them, and encourage the user after onboarding to either host their own with instructions or give them resources to find one. We could also create a pool of all nodes by scanning popular sites like Monero.fail etc to build a bootstrapped listed which is load balanced over. It could be implemented as an optional part of the stack on the installation process to the desktop, just to make it super easy and have it self-manage, self-heal, auto restart etc.
| @@ -50,13 +50,13 @@ This document maintains functional requirements for the Haveno user interface. | |||
| ### Settings | |||
| - The user can export a backup of their Haveno instance to a zip file. | |||
| - The user can view the mnemonic phrase of their Haveno wallet for manual backup (excludes funds locked in multisig). | |||
| - The user can configure a local or remote node. | |||
| - The user can configure a local or remote node. (Needs specificity) | |||
There was a problem hiding this comment.
Again referring to a Monero node.
Just a couple things to be clearer on