Most users won't check console logs, so we should present them with an error another way. Ideally with recommendations to fix it.

Originally posted by @garyray-k in fedimint/fedimint#2360 (comment)

Gateway webserver has authentication mechanics. For MVP, let's make the user to enter in this password instead of reading it from the environment. We'll need to make sure our MVP deployment scripts don't hardcode password so I can login to @okjodom's gateway :)

This may require fedimint changes but making the issue here so we get the end-to-end change.

define types for gateway route hints

This code gets run, but I don't see anything show up

We should ideally never been in the state where they're rendered so should remove the default basics. At a minimum, we should remove the button that advances.

Originally posted by @garyray-k in fedimint/fedimint#2360 (comment)

https://hub.docker.com/layers/fedimintui/guardian-ui/ is current ~1k Mb
We should improve on this.

https://github.com/fedimint/ui/blob/master/Dockerfile.guardian-ui#L5-L7

This site should be able to run on really lean & weak hardware since it's just a basic web app, but doing the build can blow out memory on some smaller machines. A quick find / replace would be much more efficient than doing a full build. Should also improve start-up times dramatically when not using the default env var.

Ref: Figma

Initialize side main panel experience of the admin ui dashboard. Main panel would just contain the elements we presently have prototyped in the admin ui

The config server shuts down as we finalize the configuration of the federation, currently, we just use a timer to wait for the transition to happen on the backend.

Yeah so the tricky thing is that once you start consensus, the config server shuts down and the regular api starts up, so it necessarily kills the socket. Ideally the config server would stay up long enough to respond to the rpc, indicating that it successfully started the server, and then shuts down. Worth an issue to improve the understandability of the code IMO.

I haven't spent enough time here to know if this is a reasonable timeout, but you are correct that it could hypothetically not be enough time. Unfortunately while I was working on this, this part of starting consensus would cause the backend to panic and crash. Might be worth some retries if we find it's prone to taking longer than this.

Originally posted by @wbobeirne in fedimint/fedimint#2360 (comment)

See TODO in SetConfiguration.tsx

Originally posted by @garyray-k in fedimint/fedimint#2360 (comment)

This pops up first thing on the setup form, which instantly draws your eyes to it. It shouldn't show an error until the user has touched the field, or the user has attempted to submit while it's empty.

We've run into a problem during some of our test setups that is easy to miss when you're developing solo, or setting up a 1 of 1 or 2 of 2 federation. Right now followers attempt to run DKG as soon as they approve the configuration. This is problematic if in e.g. a 2 of 3 federation, only the leader and follower 1 have joined. Follower 1 has not yet gotten any information about Follower 2 who will join shortly, so their DKG is incomplete. Once follower 2 attempts to run DKG, it'll fail because follower 1 will reject them.

We need to re-architect this so that followers go through the following flow:

1. Follower pastes in leaders WS API URL
2. Follower is presented with configuration from leader
3. Follower hits approve on configuration
4. Follower is presented with a screen that shows the status of all peers, and says that it's waiting for the leader to continue
5. Follower sees that the leader's status has gone from SharingConfigGenParams to ReadyForConfigGen
6. Follower transitions to the RunDKG screen and attempts to run DKG

Followers will not know how many guardians the leader intends for the federation to have, so they will not see the rows that indicate guardians that have not joined yet like the leader does.

          We can type guard this using `'status' | 'set_password' | etc. etc.` so only certain strings can be used when making the call. It then also serves as a one stop point of reference for what RPC methods are supported. I believe that to be especially important if there's ever a time when we export this API as a package/library for use in other apps.

Originally posted by @EthnTuttle in #28 (comment)

(once we have releases)

connectionCode in apps/guardian-ui/src/components/FederationDashboard.tsx is an example. The connection info string is very long cannot be viewed in full in the CopyInput element.

We currently don't have unit tests on our Guardian UI components or logic. It seems the gateway UI is set up to use Jest but also doesn't have a lot of tests.

• Settle on Jest or some other framework
• Implement reusable testing patterns
• Mock backend API calls for use in tests
• Integration tests

fedimint/fedimint#2485 (comment)

This is memory intensive. Failed on $6 digital ocean server. Eventually just embed the build/ directory when we create the container. This line:

CMD if [ ! -z "$REACT_APP_FM_CONFIG_API" ]; then yarn build;fi && serve -s apps/guardian-ui/build/

I believe this should only impact dev environments since reproducing this is pretty far out there for an edge cases.

We default to local storage to hydrate SetupContext so if you restart/clear a federation in the middle of setup, the UI will see that there is already SetupContext state in local storage and hydrate the context. This will not match the actual state of the backend.

To reproduce:

1. startup a local federation and continue through only part of the setup flow (stopping around verify guardians or some other intermediary step)
2. Stop the fedimintd instances and clear the federation data.
3. Restart fedimintd instances.
4. Browse to Setup UI and refresh. You should see an error (The websocket is not opened) or similar.
5. Check local storage cache and observe.

For each lightning node connected to the federation, we should show public node and routing information

• Fetch list of connected gateways using guardian api : #69
• Update lightning node info UX and show info
  • title gateways using gateway id
  • view gateway node using node id

This requires backend change to fully work.

• Create password screen
• Authenticate later with ^^ password. This needs a design. Initial screen has options to "login" or "create password".

Each Dockerfile for each app should only copy and build the app in question. Running yarn install in the root directory installs all of the dependencies necessary for all packages and apps, and running yarn build in the root directory builds all apps. We should only copy and build the apps and packages that we need per app.

        <CopyInput
          value={process.env.REACT_APP_FM_CONFIG_API || ''}
          size='lg'
          buttonLeftIcon={<Icon as={CopyIcon} />}
        />

We currently use the UI enviroment variable as the connection. However, this is incorrect and should be the FM_API_URL passed into the Coordinators config for fedimintd.

Currently the gatewayd doesn't connect to LND in the dev docker-compose setup.

Setup UI should support setting up federations on

• Testnet
• Regtest
• Signet
• Mainnet

Consolidate local storage keys to GuardianContext.tsx
Any other "state" should be handled here as well.

TBH I would like to get the password storage out of the API file altogether and move it in here. I'd much prefer that to just be a dumb class that takes all its inputs explicitly, rather than having some magic internal stuff going on.

Originally posted by @wbobeirne in fedimint/fedimint#2360 (comment)

From @justinmoon

One thing I would really like is a simple way to build little dashboard from a federation or gateway rockdb.

I would love to just have a jupyter notebook that I could easily write little scripts to measure things like:

• graph of federation balances over time
• lightning payment success rate over time
• what percent of epochs does guardian N get into over time
• average size of lightning payment over time
• how frequently do lightning payments enter refund case

@elsirion mentioned promethius, too, but I'm not very familiar with it

What I'd like to avoid is really long development cycles where someone thinks of a graph while prototyping dashboard in figma, then it's implemented in admin API, then implemented in frontend, then deployed. The feedback loop there will be really slow that way.

We should look to clear or reset SetupState persisted in local storage once the guardian UI transition from setup mode to Admin dashboard experience

Could probably use something like Vercel to deploy the UI itself. But we'd need a backend to run against which would be a little tougher. But gateway UI has mock API implementation so for starters we could just used a mocked-out backend.

This will cause an excessive number of state machines to be spawned

When inputting number of guardians, a user should be made aware of the 3*f+1=n where n is the total number of guardians, and f is the number of potential malicious guardians. Perhaps a link to the reasoning behind this can be included.

Mintgate defines and uses mock Gatewayd API which is really nice for development without starting a real Gatewayd instance.

Here is how it selects an API to use based on environment variable.

We need to plug in to the real Gatewayd API

Lay some framework for translating.

fwiw, I've seen json files work nicely for this.
i.e.

en.json

{
    "dashboard": {
        "title": "Fedimint Guardian Dashbaord"
    }
}

es.json

{
    "dashboard": {
        "title": "Panel de Guardian de Fedimint"
    }
}

It's then reference in typescript:

<Text>
    {i18n.dashboard.title}
</Text>

/**
 * Given a map of peers, determine which one is you.
 */
export function getMyPeerId(peers: Record<string, Peer>) {
  // TODO: Find a better way to do this than using env var?
  const myApiUrl = new URL(process.env.REACT_APP_FM_CONFIG_API as string);
  return Object.entries(peers).find((peer) => {
    const apiUrl = new URL(peer[1].api_url);
    return myApiUrl.origin === apiUrl.origin;
  })?.[0];
}

Originally posted by @garyray-k in fedimint/fedimint#2360 (comment)

We should explore building a gateway Admin interface packaged as an LnBits extension.

After you've joined a federation and load the guardian UI page, there is no loading state while it's fetching the list of federations. But once the call completes they show up.

If something goes wrong, we currently have no way to restart short of restarting fedimintd. Would be nice if we had a button + backend API to accomplish this.

https://www.npmjs.com/package/eslint-plugin-react-hooks is a really valuable eslint plugin to have, it will catch common stale closure issues in hooks. We've probably got a few offending hooks as it is, so we'll also want to fix those.

If you're setting up a federation, and one guardian starts consensus before sharing their verification code, you run into a problem where now they are no longer able to see their verification code, and all other guardians will be stuck on the VerifyGuardians step.

We should fix this in at least one of two ways, but probably both:

1. Warn the user before proceeding that they must share their code, make them confirm they have
2. Show the verification code somewhere after setup so they can rectify this if someone is stuck

This functionality exists, but we need to update it to the new designs.

• Connect screen
• Loading state

No attention was paid to dark mode while building out the initial guardian setup UI. We'll need to tweak theme.ts to have values for dark mode, and likely need to tweak a few components that use the theme object to style various things.

Chakra docs on color modes: https://chakra-ui.com/docs/styled-system/color-mode

Here is my preferences and recommendation for all Fedimint UI projects

fedimint/fedimint#1266 (comment)

Enable a Guardian to input a node for their instance to use:

• input node URL
• show default node url from local config gen
• confirm node connection w/ feedback
• frontend ability to switch FM_BITCOIN_RPC_KIND

We recommend people setup with 2n + 1 fedimintd instances, and certain bugs (e.g. #83) only rear their ugly heads with 3 or more guardians in a federation. We should make this the default, and update our README instructions to reflect a 3 guardian setup.

To ensure a consistent UI experience, we should be using useTheme everywhere there are style props passed to a component.

Should useTheme here for button sizes.

Originally posted by @garyray-k in fedimint/fedimint#2360 (comment)

When there's no members or a connected lightning node, guardian ui should show two message bars showing how to gateway operators can connect to the federation.

Tasks:

• Implement message bar UX
• Add appropriate message to show the guardian (clarify messaging and copy)
• Detect state using guardian api and show / hide message bars

Ref:

• Figma

In apps/guardian-ui/src/GuardianApi.ts the startConsensus method is flaky due to how we currently handle the API switch. The UI gets caught in a "setup" state but in reality, consensus has already started running. A refresh of the UI leads to "method not found" errors as it tries to determine where in the setup process is it.

I have tried a few approaches but none have yielded consistent results.

relevant Discord conversations:
https://discord.com/channels/990354215060795454/990354215878688860/1122657638388338819
https://discord.com/channels/990354215060795454/990354215878688860/1124158861876674571
https://discord.com/channels/990354215060795454/1105908596614627428/1121760876286976071

With Fedimint's modules, the Guardian UI needs to account for any additional modules and display their configuration properly for setup.

Originally posted by @garyray-k in fedimint/fedimint#2360 (comment)

Per comment in GuardianApi.ts, we should confirm the error is related to and handle it appropriately.

Originally posted by @garyray-k in fedimint/fedimint#2360 (comment)