Lunie: design node switcher

[jbibla]

[nylira]

I don't think we're trying to make a network switcher, just a node switcher. Generally, our different testnets run on different versions of Cosmos SDK, so if we support this, that opens a can of worms regarding how we're going to store, and how many versions to store, of gaiacli and gaiad. That seems to be out of the scope of the issue.

What we're looking for is a place within Voyager to view full nodes, edit the list of full nodes, and select the full node that we want to connect to. Here are my thoughts on this:

1. In Voyager, we already have some way of finding out all of the peer IP addresses from the genesis.json file. Let's pre-populate connectableNodes[] with this information, and persist the array to localStorage. These generated connectableNodes[] should be immutable by the user.

2. There are full nodes and validators who are not in the genesis.json file. Users may want to connect to those too. That means we need to have an input field that accepts IP addresses and domain names. We also need an input field for the port number, which should default to 46657 (or something). Upon clicking "Add Node", Voyager should validate the address and the port number to make sure that a full node is in fact available at that location. If it's a valid, push it to connectableNodes[] with a flag that it is user created.

3. The user should be able to remove any node they've added to connectableNodes[]. The user should not be able to edit the node IP or port number of a connectableNode, because they're more likely to break the connection by making a typo. They can delete and make a new entry.

4. When the user clicks on a connectable node, we should have a loading icon in a modal that informs the user that the new connection is being made. When the connection succeeds, the user gets a success notification that they're connected to the new node.

5. If the connection to the node fails, the modal informs the user that the connection could not be made, and it tries to reconnect to the last reachable node. When the connection succeeds, the modal disappears. A red X appears next to the node that was unsuccessfully reached.

6. This may be controversial: Periodically (every few hours?), Voyager should try to connect to each of the connectableNodes[] in the background to make sure they're still alive. If they're not reachable, we add a red X next to that node.

[nylira]

More thoughts:

For a better user experience, we should allow users to paste in IPs with the port number attached into the address field. For example, if the user pastes http://43.23.65.24:46657, we should watch for a keyUp event, split the address at the last colon, and fill in the address and port number fields with the correct segments.

Also, we already have a list of full nodes and validators on the Staking page. Perhaps we can add an option on the candidate profile page to "Connect to this node".

[faboweb]

Very detailed design description. I like it. I would do 6) later as it sounds a little more complex.

For the IP input: You could have a mask where the user is only able to enter the IP address and it is wrapper by http:// and :46657 to reduce confusion and magic.

[nylira]

@faboweb I like less magic, I was just thinking about future cases where full nodes may change their gaiacli port. May not be necessary for MVP.

[faboweb]

Was also just an idea. You are right, that the gaiacli port may change on different networks.

[jbibla]

this sounds great. and i agree, the thoroughness of the description is very helpful peng! thanks!

this sounds like a nice feature - i'd recommend moving it to a wireframe. i can do this is if we want - or peng you can do it.

[nylira]

@jolesbi please feel free to make this wireframe

[jbibla]

it seems to me we already have a bunch of this in the explorer #monorepo

here is a list of "Peer Nodes" for example — http://165.227.247.94:8080/validators

there is also an input field on the home page of the monitor which appears to be for typing in a specific address although i can't tell if it's working or not...

---

1 & 2: as opposed to making the user input addresses of nodes, why don't we show them the whole list and let them search for and pick they one they'd like (like we do in explorer) — we can indicate which full node is a validator.

3: not sure if this is necessary if we follow 1 & 2 above. blacklisting is an option but i don't think this is critical for an MVP.

4 & 5: see wireframes 👌 i would add the connected node back to the bottom right if the user displays an interest in this kind of information (by selecting a specific node as opposed to going with a random one).

6: i don't see why this can't be real time like i would expect the explorer to be.

[nylira]

@jolesbi I think your solution of using the list of full nodes from Explorer is an awesome idea. It's less work for us and one fewer custom GUI for the user to learn.

Let's definitely add the connected node back to the bottom right.

[faboweb]

This all sounds very good. :)

[jbibla]

ok great. so i think the design part of this task is complete. we should consider the same interaction for "actions on list items that look like tables" as we use on the delegates list when choosing who to stake to.

we should discuss when to implement this non-trivial feature in the meeting perhaps?

@faboweb @nylira

[faboweb]

Closing this issue as the design part is done.