Select network address: distinguish between discovered instances and contactable instances

bjester commented 2 years ago

Observed behavior

Kolibri instances on the same network discover each other using a Zeroconf mDNS broadcast. We use this functionality to surface the network addresses of these instances when selecting an address for syncing a facility (one example). In the event the network instance has a typical firewall setup, where incoming packets are dropped on most if not all ports, we may have discovered the instance but would be unable to connect to the port on which Kolibri is running.

If the firewall drops incoming packets, requests will appear to "hang", including the request in our network locations API.

Errors and logs

Forever loading 183738670-4a78f005-4f3b-4441-99e6-634e76ea9eb1

Expected behavior

Ideally, we should set reasonable timeouts on requests to network instances to avoid forever loading states in the Select network address modal. Additionally, discovering an instance through Zeroconf, but being unable to complete requests to it, is useful information to surface to the user. This sort of situation would likely be indicative of a firewall active on the network instance.

Figma for new designs

User-facing consequences

Would Kolibri consider improving its user interface [...] — so that in future people don't again waste hours/days every time — fighting this same battle? https://github.com/learningequality/kolibri/issues/9594#issuecomment-1209768398

Steps to reproduce

1) Set up 2 instances on a network, both with the same facility 2) On one instance, add a simple firewall that will block access to the port Kolibri is running on from the local network 3) From the instance without a firewall, attempt to sync to the firewalled instance 4) Observe issues with selecting a network address

Context

Kolibri 0.15 OS: any Browser: N/A

holta commented 2 years ago

Thank you @bjester for writing this up, to help out regular everyday citizens trying to establish Sneakernet-of-Alexandria civic/learning networks — w/o drowning in complexity !!

💯

nucleogenesis commented 2 years ago

I think that this might require some new strings to indicate the error state or issue to the user (ie, is the source bad, should they try again, etc) so I'll put this in the pipeline for 0.16

bjester commented 1 year ago

@jredrejo @AllanOXDi Mentioned that I should be keep an eye out on how changes to this will touch work made by them with respect to the Vue composables on the frontend.

bjester commented 1 year ago

Important considerations

we should apply the UX enhancements to all usages of the network address selection modal, which includes facility data syncing, channel/resource import, and setup wizard workflows
for the single-learner device setup workflow, we previously introduced visibility into the Kolibri instance's version within the modal since pre-0.15 devices don't support single-user syncing

UX Selection states

an instance is disabled because the Kolibri version is below some threshold
an instance is disabled because it was manually added but is neither detected nor contactable (check network connection?)
an instance is disabled because it was detected but isn't contactable (check firewall / check everything except Kolibri)
an instance is disabled because it was detected or manually added but contacting the instance results in some request error (check the other Kolibri instance)
an instance is enabled because it was detected or was manually added, and it's contactable

learningequality / kolibri