search

tocwex / fund

A sovereign platform for peer-to-peer economic activity with on-chain settlement and trusted identity assessment of work completion.
GNU General Public License v3.0
7 stars 0 forks source link

add interface indicators for stale/failed connections and state transitions #84

Open sidnym-ladrut opened 4 months ago

sidnym-ladrut commented 4 months ago

The changes in #70 herald %fund's first state transition, which will cause the first set of pub/sub desynchronizations. Ideally, a subscriber that has been desynchronized from its host can indicate within its UI that this project is in a bad/invalid state.

sidnym-ladrut commented 4 months ago

There are technically two distinct kinds of descyhronization in SSS:

  1. Stale desyncs: The subscriber cannot contact the host, but hasn't encountered any explicit failures in communication.
  2. Fail desyncs: There's been an explicit failure in communication, indicating that some action needs to be taken to fix the subscriber or the host.

Since we'll likely be using Tlon's negotiate library to mediate protocol versions, I'm pretty sure that all post-upgrade mismatches will lead to fail desyncs (if they get repopulated at all; details forthcoming).

thelifeandtimes commented 4 months ago

My expectation here is that this needs to be addressed for a project depending on whether you are viewing it on the host or not; so there are 3 things to be able to indicate to an end user:

  1. This ship is (or at least claims to be) the host of the project.
  2. This ship believes itself to be in sync with the host (based on some recent ping? maybe checking for equivalency between their desk hash, the host's desk hash, and ~tocwex's desk hash?)
  3. This ship is not in active communication with the host

I can imagine depicting this similar to how %tlon does group / peer connectivity. It seems like a useful design pattern to piggyback on--do we have any blockers to that type of dynamic reloading since we aren't using react? If we need to force user interaction, I can design a 'check connectivity' button/trigger, and/or a 'last affirmative connection' display, but depending on how much stuff that becomes it might be something we push to a footer element or other sort of overlay.

Open Questions (not urgent):

sidnym-ladrut commented 4 months ago

I can imagine depicting this similar to how %tlon does group / peer connectivity. It seems like a useful design pattern to piggyback on--do we have any blockers to that type of dynamic reloading since we aren't using react? If we need to force user interaction, I can design a 'check connectivity' button/trigger, and/or a 'last affirmative connection' display, but depending on how much stuff that becomes it might be something we push to a footer element or other sort of overlay.

We could hack this together by adding a new type of poke and associated POST request, but I think this would work best in the context of a HTMX componentized refactor.

  • currently, only the host serves a version of the page to the clearweb--Do we want to enable the oracle to do this as well by default? does that fuck with the way we gather pledges or would it be just a trivial change to make the page public from the oracle? If this is an easy change, it might be worth considering in order to give a bit of a 'trust but verify (by trusting the oracle)' option for people who don't have the fund app installed. If this creates a whole bunch of work for how to verify and communicate pledges back to the host, we should not get bogged down in this idea. Or if we think it creates more uncertainty and questions from the end user's perspective

This would be hard to do at present because pledge/fund authenticity is guaranteed by the sender. That is, if I receive a %mula from ~zod, I verify that the %mula has ~zod as the pledger/funder before accepting it.

We could allow these requests to be arbitrarily forwarded/relayed, but that would require message signing. We want to support that workflow ultimately anyway, but it's a bit down the road.

thelifeandtimes commented 4 months ago

We could allow these requests to be arbitrarily forwarded/relayed, but that would require message signing. We want to support that workflow ultimately anyway, but it's a bit down the road.

Yup. No hurry on this. Relevant tweets: https://x.com/tocwex/status/1796771761524240480

thelifeandtimes commented 4 months ago

Here is the prototype where i have this demonstrated within the tooltip: https://www.figma.com/proto/BzP6poTdN53qJMiUc0shgz/%25fund-v2?page-id=60%3A5345&node-id=144-3619&viewport=2066%2C463%2C0.3&t=pmiNhTBRcbUnzdML-1&scaling=min-zoom&starting-point-node-id=144%3A3619

Mouse over the vertical ellipses to the right of Project Overview to see the behavior.

Here also is a quick little video for reference: https://sfo3.digitaloceanspaces.com/sarlev-sarsen/sarlev-sarsen/2024.5.31..23.8.34..cc8b.4395.8106.24dd-Screen-Recording-2024-05-31-at-4.05.59%E2%80%AFPM.mov

The component to see here is currently in %fund v2 project > Full V2 Designs > Prototype Components > Tooltip. This file will likely move to the ~tocwex.syndicate Asset Library if we think this will be viable to implement. Component link should be this: https://www.figma.com/design/BzP6poTdN53qJMiUc0shgz/%25fund-v2?node-id=321-1139&m=dev (let me know if that link worked; it should put to to the exact component in dev mode, but I am curious how good the deep linking is)

Thinking here that probably we could do the poke at hitting the toggle, and then have a refresh option on the overlay so we don't have to deal with trying to push updates? image

thelifeandtimes commented 4 months ago

What is not displayed here is the different states of the connection status. Thinking we have the following: Yellow Dot - Pending Response Green Dot - Connected (desk-hash) Purple (or gray?) Dot - Version Mismatch Red Dot - Connection Failed Teal Dot - You are the Host!

If those look good, I'll refine the various prototype states and get the tooltip type component into the asset library