Post Tournament Idea Collection

[da-kami]

This discussion is meant to be a collection of ideas for what do do and how to approach it after the tournament is over.
At the moment we are highly focused - this can help us remember things so we can re-visit them later.

I propose to write up different topics as answers and then we can discuss each topic (i.e. each answer) in the comment section below.

[da-kami]

• Known user interface issues
  • Choice of colors of confusing - green red for different semantic parts of the application
  • Choice of certain icons is confusing in context
    • see: Fix screen overflows, refactor Amount display #136 (comment)
  • Complexity of CFD screens
  • The navigation to settle a position is slightly different than for opening (two-step subscreen vs. one-screen).

[holzeis]

I would also like to see a success screen after opening and closing a position. Currently we are simple navigated to the overview screen which is not very satisfying (to me 😅)

[da-kami]

• Channel managment
  • Do we want to allow more than one channel? At the moment we have one channel for one maker within one wallet.
    • Do we want to have multiple channels with the same maker?
    • When do we expect / need multiple makers and what does it mean for channel management?
  • Should the taker connect to other nodes as well or rely only on the maker?
  • How much control should the user have over channel management and where should it be located in the UI?
    • Wallets like Phoenix hide the complexity of channel management from the user. Can/should we hide it?
    • Is it a good idea to add actions to the Lightning wallet like open/close channel?

[bonomat]

When do we expect / need multiple makers and what does it mean for channel management?

Let's try to get the maker=lightning-node=1-channel relation out of our heads.
The interesting setup is the one of a star, where all takers/makers are connected with the same node.

classDiagram
taker_1 <--> tentenone : 
taker_2 <--> tentenone : 
maker_1 <--> tentenone : 
maker_2 <--> tentenone : 

Loading

[holzeis]

tentenone could become an enabler node, where makers and takers can find each other. The makers could then as well be phones, since tentenone is always on for opening channels.

Would be cool to enhance our current app with the feature of creating an offer 😉

[da-kami]

• Backup
  • How do we want to manage backing up the Lightning data stored on the phone? Can backup be "continuous"?
  • How do we want to back up the 10101 CFD data? Can backup be "continuous"?

[holzeis]

The tentenone node could offer to store encrypted backups of the user data. this could be bound to the seed phrase - which obviously will not be backed up..

Backups would then happen regularly.

Alternatively, we could also connect to the apple, google cloud, nas, etc.

[da-kami]

• CFD lifecylce model
  • We know that our Offer-Order-Cfd model is not optimal. It would be good to come up with a better model prior to building maker/taker for production again.

[holzeis]

Can you share your experience? What is not optimal about it?

[da-kami]

If we assume an orderbook (see: #138 (comment)) we likely don't need Offer, but only Order.
Both the maker and taker create Orders - a maker likely creates a limit order (for a certain price) that then waits in the orderbook to be matched. A taker can create a limit or market order. A market order will be matched by the orderbook based on the "current best price" of all orders the orderbook knows.
Orders can be partially or completely filled.

---

Concerning the Cfd: A Cfd should only exist once an Order was filled. It is questionable if we have to create a Cdf out of a partially filled Order (I guess eventually yes, but that would require a combined position which may add complication in our non-custodial setup).
For me the lifecylce of the Cfd is bound to the existence of the Dlc, whereas the Order is prior to this. The Cfd cannot exist without an Order that was filled. The Order can exist without the Cfd. We will likely have to introduce a persisted lifecycle for the Order` as well.

Some of my previous thoughts on refactoring the ItchySats model can be found here: get10101/itchysats#2555

[da-kami]

• Multiple services (from the get-go)
  • The navigation between wallet and (CFD) trading is complex - there is a "cut" when jumping to trading, and it's not super intuitive to understand that one has to use the menu to go back.
    • Initially there is likely only (CFD) trading for a while. Can/should we change the navigation to be less complex, knowing that eventually it might change to a more complex model?

[holzeis]

In my opinion, yes! I would not clutter the UI with components that bring no value to the user. Currently the mocked service cards are far to prominent.

[da-kami]

After a discussion with @klochowicz we came to the conclusion that:

• We agree that services that are not finished should not be shown in the application.
• It will be worth exploring how to just have CFD trading to navigate through from the wallet.

But, we have to be careful with simplifying the overall navigation design:

• "Simplification" is subjective
• If we simplify the "dimensions" of the application and the navigation we have to ensure that our screens do not suffer from becoming more complex.
• Be careful to think simplifications in navigation through as a whole - just because we reduce trading to CFDs does not actually mean we have one dimension less, but we limit one of the dimensions to exactly one item ;)

We agreed that it would be best to build on user feedback rather than investing time into coming up with an arbitrary simplification that might be a step in the wrong direction in terms of scalability. That said: It'd be great to base a decision on user feedback, so I think we should work towards user interviews!

Note: #557 will help with making the Dashboard more accessible throughout the application. In our previous discussions that was one of the main problem points. Maybe that's actually good enough - do we still need a more radical step back to the drawing board for this?

[da-kami]

• Multiple wallets
  • We said that we need a Bitcoin wallet as part of the application because of e.g. force-close.
  • Do we like the current split? Is it intuitive to understand the split between Dashboard, Lightning (i.e. off-chain) and Bitcoin (i.e. on-chain)?

[bonomat]

I think we should keep the on-chain wallet but rethink the split in the frontend, e.g. look at this: https://bitcoinqr.dev/

[holzeis]

I think the UI could display bitcoin / lightning balances better.

[da-kami]

• Onboarding
  • Onboarding into the wallet
    • How much onboarding do we consider for our initial target user?
  • Onboarding into CFD trading
    • Given that CFD trading will be the first main USP of the app, do we need onboarding for our initial target user?

[holzeis]

Might be covered with #411 ? obviously the app can not educate on CFDs, but on how to use them should be feasible.

[da-kami]

I am not sure #411 is enough. In addition to the initial onboarding tour that shows an overview of the app, I think it would be great to add CFD onboarding.
We could consider to add different user interfaces for trading - one that is simplified and one that is more complex. Through that we could cover onboarding of unexperienced users through the UI rather than something that explains the UI.

[bonomat]

• orderbook
  • we should start thinking of an order-book style and not broker-style, i.e. a maker creates an order which a taker can take
    • this has strong implications
      • on the frontend, e.g. a taker might now see an orderbook and a approximate market rate.
      • closing an order should be realized with placing a counter order to the orderbook (limited close) or go through immediately as a market order against any maker.

[da-kami]

For me this is strongly related to the creating a better "CFD lifecycle" model (#138 (comment)). I think we should drive re-thinking the model with an orderbook in mind.

[bonomat]

Just a small idea: we could redesign the app ala https://bitcoin.design 😬

[da-kami]

I think it would be great if we manage to take a step back for the app UI / UX and go back to the drawing board. In my initial answer to this discussion I proposed to:

1. Go back to the Figma wireframes and improve them (e.g. taking into account that the initial version of the app should not be that complex, see Post Tournament Idea Collection #138 (comment))
2. Create a high-fidelity Figma prototype together with a designer. => Here I see using https://bitcoin.design/ :)
3. (Re-)Implement

[da-kami]

• Alignment on terminology
  • Several things in the app UI are not aligned, if we call the same thing different in multiple places that can be confusing to the user
  • Sometimes the code does not align with the UI which can be confusing to devs and lead to misunderstanding

I think its' important that we align on terminology before jumping into redesigning the model, re-implementing / re-factoring code.

[da-kami]

Things I noticed:

• Lightning vs. Bitcoin
  • Transaction was used in both contexts which might be confusing
  • Order vs. CFD - we talk about cfd_order_detail - I am not sure this makes sense. For me the Order lifecylce ends when the Cfd starts, because the order is filled then.

[da-kami]

• Testing
  • When do we want to start adding (more) (end-to-end) tests?
  • How do we imaging end to end testing for 10101?
    • For XMR-BTC we spun up a regtest environment and actually started two binaries that we triggered to perform tasks.
    • For ItchySats we mocked the blockchain away and only tested on an actor level without actually running the binary against "the chain.
      • We already discussed that a setup that "always starts from zero" for each test does not scale super well - do we want to follow up on that?
    • Do we expect to have UI / flutter tests as well?

[bonomat]

More a question:

• we already know that electrum-client is a bottleneck. We need to think about either an alternative or how we can improve it.

[klochowicz]

we could try going with esplora, as we're not dependent on Umbrel infrastructure for self-hosting