Light-client: I want to get hubs proposed which are well connected (Autopilot)

Created on 23 Jul 2019  路  23Comments  路  Source: raiden-network/light-client

User Story

As Chris I want to get hubs proposed which are well connected so that I can connect to a hub through which I can send transfers to a potentially high number of nodes.

Acceptance criteria

  • It is possible to select one hub
  • It is possible to enter the address of a hub
  • As it is time-critical it needs to be easy to implement

Tasks

  • [ ] Design @sashseurat
  • [ ] Implement in the SDK (@andrevmatos)
  • [ ] Implement in the dApp

Ideas

  • List dropdown
  • Using the PFS list
  • Adding a button and use a modal

Screenshot of the current implementation

grafik

8 sdk 馃枼 dApp 馃摫 Design 馃帹

All 23 comments

Duplicated of #155, but this title is better explanatory, closing that in favor of this one.

@andrevmatos We have estimated 100 points, but maybe due to our limited knowledge of the matrix protocol

691 is a short term workaround

Ideally, this wouldn't involve much matrix protocol meddling, but instead rely on PFS suggesting well connected and high uptime partners for us to connect to, possibly also taking into account higher probabilities on default configurations of being counter-deposited.
A local algorithm can also be developed, but as it'd only have access of instantaneous blockchain & matrix data, it'd always be less precise than long-living PFS data. Eventually, some on-chain reputation system is also expected to arise for this.

We can do it partly

  • Having a basic list of suggestions

@Dominik1999 It would be great if we could have https://github.com/raiden-network/raiden-services/issues/684 This would greatly simplify the onboarding of new users for the Light Client and would avoid us implementing an autopilot (Connection Manager).

Let's first create a small solution and wait for https://github.com/raiden-network/raiden-services/issues/684 to be implemented

  1. Partner / Hub is online
  2. Clients with 3 or 4 channels
    a) Connected with the connection manager
    b) Counter-deposited
  3. The highest number of channels

@Dominik1999 We should talk about the standard setting for counter-depositing to enable receiving from very well connected hubs.

Service PR is ready for review: https://github.com/raiden-network/raiden-services/pull/834

@karlb Do you need a review from us?

It's mostly unreviewed because the Berlin office is quite empty this week. I would clearly like feedback on it, but that might be easier to give when it's merged, as it will allow you to try it out on https://pfs-goerli.services-dev.raiden.network.

@manuelwedler Could you please add your learnings while implementing https://github.com/raiden-network/webui/issues/547?

Please also add a screenshot.

Thanks :)

Idea from @andrevmatos: Just a dropdown or list with the proposed clients. There should also be the possibility for a user to type an address.

Screenshot of the WebUI implementation:

grafik

@christianbrb The pfs endpoint is pretty straightforward to use. It ranks nodes and gives an ordered list back. It should be easy to integrate that into the light client. See this for the documentation.

If you want to link to the explorer highlighting the suggestion in the network graph, you can do so by adding a node query parameter to the explorer url, e.g. https://explorer.raiden.network/tokens/0x6B175474E89094C44Da98b954EedeAC495271d0F?node=0xEe12f8e36574C97eFfEf86723053c533649a561B.

Btw don't forget that the demoenv does not support the suggestions endpoint yet.

Hi @sashseurat :) Can we have a meeting on Monday to discuss this issue?

Hi @sashseurat :) Can we have a meeting on Monday to discuss this issue?

sure! invite me for a call :)

@eorituz We would need an upgrade of the demo environment to implement this issue. We would need to start with the implementation after the design has been done. An upgrade mid next week would be fine. Please coordinate with @paul for the correct version.

Meeting with @sashseurat and @weilbith

Notes:

  • Information, that the hubs are ranked (best first) Current top 3 suggested hubs (best first)
  • A maximum of 3 nodes is shown
  • Each hub is represented by an address
  • Ability to select one node and copy it to the input field
  • Link to the explorer
  • It could be the case, that the list cannot be fetched from the PFS server (error case)
  • Only minor changes to the design, if needed

Optional:

  • Defer the redesign of the Select Hub and Open Channel screen

Note from the planning:

  • @weilbith @taleldayekh Please let me know, if it is difficult to implement the design (once Sash has posted it). We might need to make compromises due to the upcoming mainnet release.

@christianbrb @weilbith
Here is a link to the figma click-dummy to illustrate the concept of selecting a hub:
https://www.figma.com/proto/bzhKhMCOzOPgOS0gr5gpLv/LC-Hubs-Selection-211?node-id=319%3A0&viewport=-1008%2C1182%2C0.6787916421890259&scaling=min-zoom

Screens

Default
LC - No Planned Withdrawals_ default

Selected
LC - No Planned Withdrawals_ selected

Error
LC - No Planned Withdrawals_ error

_Note: I updated the scan QR icon to show it is for scanning :) not displaying_

@sashseurat could you please add another screen for the loading state? The fetching of the suggestions is asynchronous. I would like to make the app working all the time, but while those hubs are fetched we show a loading state before we resolve it to either an error or the suggestion list. But theoretically if the user does not care and the network is slow or the service node does not respond fast, he should be able to use paste his own address and go ahead.
If you don't "care" I would just add a message to express the fetching state and add a small spinner below that. But I would be happy to get a more professional version by you.

@sashseurat could you please add another screen for the loading state? The fetching of the suggestions is asynchronous. I would like to make the app working all the time, but while those hubs are fetched we show a loading state before we resolve it to either an error or the suggestion list. But theoretically if the user does not care and the network is slow or the service node does not respond fast, he should be able to use paste his own address and go ahead.
If you don't "care" I would just add a message to express the fetching state and add a small spinner below that. But I would be happy to get a more professional version by you.

Sure, makes sense 馃憤
How about this message?
LC - No Planned Withdrawals_ loading

I also added a paste button/icon for the hub input field :)

Thank you very much for the fast design! :scream: :pray:
Alright. Is the spinner icon animated? :thinking:

I always stated that I don't want to question your design. But do you really feel like we need this paste button? It does not add any functionality. I think everyone should be able to paste text to an input field on any device.
Copy buttons might differ since they include fast and correct selection as well especially for formatted text. But here... sorry

Thank you very much for the fast design! 馃槺 馃檹
Alright. Is the spinner icon animated? 馃

Nope :(

I always stated that I don't want to question your design. But do you really feel like we need this paste button? It does not add any functionality. I think everyone should be able to paste text to an input field on any device.

It's just a nice to have, definitely not a huge impact. I'll remove it - it's probably not worth the implementation time.

Copy buttons might differ since they include fast and correct selection as well especially for formatted text. But here... sorry

Was this page helpful?
0 / 5 - 0 ratings