Collaboration: Fedimint

[mouxdesign]

Fedimint

Bitcoin is a powerful human rights technology that enables anybody in the world to be their own bank.

Anyone, anywhere in the world, can run their own node, custody their own funds, and transact permissionlessly over the Bitcoin main chain or the Lightning Network.

We believe that creating simpler, private user experiences will be critical in promoting the human rights benefits of bitcoin.

Fedimint is built on three guiding pillars.

Community Custody
Ideally bitcoiners should run their own nodes and custody their own funds.

Many people find the technical challenges of running their own nodes and holding their own funds through recovery phrase management prohibitively difficult, and opt into trusting a third party custodian like exchanges or custodial wallets.

These users sacrifice their privacy and security in favor of speed and convenience. This represents a systemic risk to the bitcoin network as large quantities of bitcoin are aggregated into single custodians.

Fedimint aims to address this by distributing custodianship across millions of communities, making it simple for them to bank themselves. These community focused 'banks' are known as Fedimint Federations.

We are building a solution which allows users to onboard to Bitcoin in a manner they find extremely convenient, without sacrificing privacy and security.

Fedimint allows bitcoiners to onboard new users, assisting them in their custody and payment model. Instead of referring a new bitcoiner to a third party custodian, you can onboard them yourself as part of a Federation.

Put another way it allows you to be your mum's / friends / villages bank.

Project goals

• UI that manages the lightning gateway
• Onboarding process of setting up the federation
• Admin UI: This would be for when the federation is already set up
• Mobile app

Resources and links

Discord
Website

[mouxdesign]

Fedimint call #3

Apr 26, 2023

Link to the call on Youtube (pending)

Agenda

• Understand the user personas built
• Come up with some more information about these for the user journey
• Other next steps

Notes

• Shall we start with these guardians? Then try to focus on user groups and interview them to get some insights

• Shall we focus on some segments? Define some demographics. Product and marketing details to define these proto-personas related to the guardian ones

• What jobs does the interface need to do to satisfy what these guardians will need to do?

• Interviews could slow down the process - maybe focus now on the jobs these users will need to do? We don’t always have access to the users but we can get some on conferences?

• Users with leadership roles in the federation may have more knowledge of Bitcoin and be more tech-related people. Kitman mentioned that these kinds of roles could be contacted at Bitcoin conferences. Skyler mentioned that these are more developer kind of users (than the activist persona) and may be easier to contact through Fedimint Discord or Telegram channels to get some feedback.

• Sahil took us through some ideas/wireframes that he had already prepared (link to Figma file)

• What should be the main Figma file? The one that can be shared across the team. The main file should be somehow taken care of. Think about how to manage this. (check)

• What about having 2 different files? One for sharing with everyone, and also another one that can be used with DEV teams and being more like a source of truth.

• Who will be the main devs in the project?

Kitman will be on the BE side
Jodom and Justin will be on the FE side.

• Proposed a design repo for the notes and other assets

Next actions:

• Jodom creates the “design” repo on github
• https://github.com/fedimint/design
• Anyone interested in find the users and set up the userflows
• Anyone can give us some feedback on the wireframes proposed
• Jose will prepare the user journey for next call

[justinmoon]

Design repo is created https://github.com/fedimint/design

[joseabarreram]

Fedimint call #4

May 3, 2023

Agenda

• Project catch up
• User journey map - collaborative exercise (link Figjam)
• Next steps

Notes

• The dev team is working currently in understanding the API
• Sahil is working on organizing how the journey would be. Focused on the table for invited Federation guardians. He pointed out that is needed to think about the error cases during the admin setup flow.
• It was mentioned that the link that the leader shares with the other guardians is somehow a link to the leader API - kind of a “login code” – it won't be a URL
• You will need to enter a password when you enter for the first time so you can authorize it. Still needed to be defined if this password will be stored in the server.
• Something that DEV needs to be aware of is in how much the server will be needed to be restored (for certain situations)
• Somehow the leader needs to educate the guardians - the UI needs to be somehow on focus in a continuous journey - mentioned Constantine- train the trainer point of view. We need to include more documentation in the UI, videos, and so on. Make the UI more informational.

Next actions

• We’ll go through the next step on the User journey map on our next call
• Compile feedback: Sahil would like to get some feedback on the verify your guardians' step; also on step 2 where there are dividers for different sections (wallet settings, network connectivity,,..)
• Start working on the componentization (DEV team would really appreciate this as soon as possible)

[joseabarreram]

Fedimint call #5

May 10th, 2023

Fedimint’s Discord server
Link to Figma

Agenda

• Project catch up
• Next steps

Notes

• Sahil is helping Will and others to take finishing …
• Skyler asked about the current status of the admin screen; okjotdom mentioned that he would then be looking at the admin UI. After that, we can look at the admin UI setup screens from a UI perspective."
• Justin showed up about what is currently being built. He took us through the happy path/flow of creating a new federation: from setting up the leader details to verifying the guardians in the federation.
• "Once the setup is done, we don't want to distinguish between the leader and followers."
• The setup could be more convenient to do on a desktop. However, it should be possible to do it on mobile.
• Dynamic federations mean that different guardians can change once the setup has been done.
• What about anyone who could click and start running a server in the cloud? This would help to make it easier and more accessible to everyone using the product.
• It seems that the leader term provokes a lot of confusion.
• Consider adding support for translation early
• It would be nice to include more information on the landing page (the one that appears once the federation setup is finished). What information do we need to show on the dashboards?
• People asked about long-term plans for translation. This may be focused on a more long term. Until things get solid. However, the code will be helpful.
• Sahil asked about how to prioritize changes from a design POV. The options given were:
  a. For copy things: We can mention it before in the design channel of Discord.. .then if need it. Move it to a PR
  b. For core changes: make a PR
• However, maybe even some of the debate can happen in the Issue itself. The issue could be a good container for specific discussions on specific change requests
• Consider creating a 'Setup Guide' with FAQs accessible from all screens. Include 'Help' icons at areas in UI where questions/confusion could be anticipated.

Next actions:

Priority actions:

1. Getting the admin page ready
2. Get some more polish, copy, etc cleaned up
   It also needs designs for "Communicating error and recovery" through the setup process
   Gateway for Lightning users requires also designer work. Whoever uses this tool, may use also other to control their lightning nodes
3. Defining user personas for Lightning Gateway would be also required. Is anyone interested to get involved?

[mouxdesign]

Adding in the Fedimint personas that the team created for the guardian persona.
Link to Figma

Link to BitcoinTv call recording

[joseabarreram]

Fedimint call #6

May 17th, 2023

Link to call on BitcoinTV
Fedimint’s Discord server
Link to Figma

Agenda

• Project catch up
• Next steps

Notes

• Sahil will try to create some issues related to copy on the UI. We need to have a place to look at for making change requests. We are waiting for the UI to be built.
• Some settings may be more local for individual guardians. E.g. each guardian could be able to set the node to connect independently; should we also be defined on the UI? It was openly asked. Another point mentioned was that some modules will have different configuration.

Next actions:

• To work on the gateway administrator persona – this will be possibly the next work required to keep building Fedimint. We understand that this may be a different person from the guardian persona. This persona may be looking for making a profit by connecting to federations and helping users send and receive Lightning and charging for it.
  Is anyone interested to get involved? Jump to the chat in Discord.

[mouxdesign]

Update: During the last call we worked together on the Lightning Gateway User Persona.

This was done as a group by the developers providing some guidance and insight as to who those personas are as well as what their needs would be.

Three personas were identified:

1. An LSP

• Backed by a company
• Zebedee or Voltage
• They have more resources in the set-up
• Dedicated person managing the liquidity

2. A Lightning Router Node

• Someone that already has a successful routing lighting node (they already have liquidity on the network)
• Runs a big node and put out a lot of capital themselves to do that
• Does it in their spare time

3. The Guardian Gateway Operator

• Has just set up a federation
• Also sets up a gateway to serve their federation
• Learns about liquidity operations along the way

What are the UX Needs of these personas?

A rough visual of what these personas would need to see on the UI side of things.

Link to call recording on Bitcoin TV

[joseabarreram]

Fedimint call #7

May 24th, 2023

Fedimint’s Discord server
Link to Figma

Agenda

• Project catch up
• Next steps

Notes

• Seth was working on the dashboard. He told us about a UI kit that will help us to push our work faster (tailwind?). It has a cost. From the FE side, we are currently using https://chakra-ui.com/ (not sure if I understood it well, tho). Someone else mentioned https://uizard.io/ that it uses Gpt4 to generate screens, as a way to generate screens faster.

• He also took us about the work he has been doing on Figma for the guardian dashboard. Some comments raised were that guardians won’t be able to visualize the transactions - only the aggregates (need to find more about this). System won’t display individual transactions, only data/numbers that go up and down. Guardians don’t know anything about individual users - and they must not.

• Something also to take in mind is that Fedimint itself won’t have the concept of users - this would only be applied for the chat.

• Every new module will add extra functionality - So we would need a new module/tab/something to show this extra info.

• Skyler showed us some ideas that they put together about what a guardian can see:
  The balance, the guardian nodes (servers), and which are online/offline. Also, the Epochs section. This last one represents each consensus round that contains transactions (something similar to mempool blocks mining representation). As people can send money that they have not got yet, this mechanism is required to verify this information.
  He also showed us the ideas for Modules that you can switch on and off, and each will have its own functionality. This will impact the UI of the federation members (e.g. social recovery module, or password manager module to name some).

• Skyler recommended us to watch the talk that Justin and Obi did at the Bitcoin conference about modules (yet to be published). A bit technical but will help to have a better understanding of these modules.

• Lightning, ecash, and bitcoin stats would be the minimum/default modules for each federation apart from the other modules that can be added to a federation

• The gateway persona is someone in the federation that also runs a lightning node and aims to get some benefits. This is something that can be similar to https://mempool.space/lightning (gateway name, gateway node, check the network itself). You can also expect to see more than 1 gateway on federations.

• Mo asked about the customization on the code to share across the guardians - it’s seems something that it’s planned to be built in the future

• When you set up a lightning node, you get an extension that will enable you to connect to the dashboard.

Next actions:

• Get a list of things that need to be built that help designers to focus on the next steps:
  a. Guardians,
  b. Section for modules (Bitcoin related stuff - capacity)
  c. Setting/add new modules,
  c.1 Lightning gateways

[joseabarreram]

Fedimint call #8

May 31th, 2023

Link to videocall on BitcoinTV

Agenda

• Project catch up
• Next steps

Notes

• No updates from Sahil´s side - wasn't able to take a pass at the admin view this week

• Seth made some progress and showed us the new ideas based on last week's feedback.

• Something not so clear was about the module's sections and how they will interact within the admin screen. In the current implementation, it can’t be possible. You define it in the setup. In the future, this will be customizable so users can activate/deactivate modules anytime

• Adding some filtering may be good on the chart presented by Sahil.

• What denomination would be more relevant for users? Ecash or sats? These numbers will be the same. Ethan suggested that these may be separated, so guardians could notice something incorrect in the system.

• When users want to peg-in into the federation, the federation has a public address. You deposit into a federation, and this, in the future, will have that amount in e-cash notes. You can give to the federation X cash notes and the federation will give you back that amount of sats.

• If we see a difference between sats and ecash, it means that there would be a problem and guardians should alerts other guardians and (maybe) move the funds to another federation, self-custody, or another safe place

• Ecash notes are impossible to correlate inputs/outputs

• Epoch: the most important in a transaction system,. As Bitcoin has a mempool and there is no order until the block is mined. Epoch is similar to blocks in Bitcoin. In each Epoch, guardians stamp transactions. The time of mining this epoch is configurable to avoid mining empty blocks. The average is 3 seconds.

• You can have any configuration you want, but the federation is recommended to be 3+1 - the minimum recommended should be 4 guardians. Maybe a maximum of 20

• Connected lighting nodes number is not limited, so it could be a long list of nodes

• Lightning nodes could be gateways - members of the federation should be able to invite gateway players

• To invite members guardians and gateway players the code would be the same

• Which impact would have if a guardian goes offline? A number of guardians could go offline but there is a threshold where you should start worrying and the consensus could get impacted. (eg. if you have 7 guardians, 2 can go offline)

• What would happen if the consensus stop working?

• There is no way to understand if someone goes offline or is acting malicious (e.g. trying to hide transactions,...)

• Some idea shared with Jeff was to have a sort of a green fedi health light somewhere when all guardians are online and different colors as guardians go offline type deal toward red.

• The section with modules available for fedimint seemed well received

• The information about server temperature, etc.. may not be available. Depending on where it's deployed. However, maybe some minimum information could be requested to show guardians that the server is working right or not

[mouxdesign]

Created a list of FAQs which is a rough starting point of questions which users could ask themselves when 1) Starting a Federation 2) Managing a federation

Adding in some notes from the call on 14 June, one question we discussed was:

How can we create trust for the members in a Federation? Ideas that were mentioned were:

Infrastructure:

• The uptime
• Keeping up with consensus
• Running a reliable infrastructure

Hosting

How can guardians prove that they have sufficient hosting in the years to come?

Contributing to consensus

• How often are they contributing to consensus?

Duration

• Duration that the fed's been active.

[mouxdesign]

Links to previous call recordings:

BitcoinTv: 14 June
BitcoinTv: 21 June

[mouxdesign]

Link to call recording
BitcoinTv: 28 June

[mouxdesign]

Lightning Gateway UI

Link to call recording
BitcoinTv: 05 July

During the last call we discussed the Lightning Gateway UI designs and feedback on these designs were encouraged.

Userflow

Screen Designs

Link to figma

[mouxdesign]

Guardian UI

Today we discussed the guardian UI.

Comments from devs during the call;

• Display Epochs: Wont be able to display the number of Epochs
• Ecash displayed on the UI: Bitcoin and e-cash is the same thing so might not need to show them as separate items.
• Invite members: The option to create a single use invite code so that it can limit the number of people that can use an invite link.(Future iterations)

Idea: Federation info nuggets or "business cards"

• Inviting people to a Federation: Guardians provide info about the Guardian. Like some sort of business card.

We ideated on what information Guardians could provide when inviting people to the UI.

• A list of modules that the Federation has
• Identify themselves as something that’s identifiable, real name, social media handle, an avatar. (Whatever the Guardian feels comfortable with)
• Some sort of social proof mechanism, and then they sign in with a Nostr key

Invite code string: Possibly in the future creating a shorter version of that with some personalization.

Gateway UI design:

Ideated on this screen design:

• The withdraw and deposit could be in the same bucket as the balance and the Node id could go at the bottom.
• A fee rate that the gateway provider uses could be added to the screen.