# `#WW2` - Meeting Notes
## Agenda
- [ ] What is the product of Wasabi Version 2?
- [ ] Establishing of a roadmap
## Goals
1. Peter Macormak Proof UI.
2. Not having to do manual coin control?
3. Rely heavily on the default workflow.
## Simple Send
- Simple Send Depends on the transaction structure
- Why not have a slider, that avoids creating change?
## Responses
- Receive Tab is simpler
- Auto coinjoin
- Needs password prompt
- Not in scope for wasabi
- Perhaps better suited for a wallet which is also supporting unmixed coins and payment flows
- Unclear who target user base is
- Research necessary
- Who is peter macormack?
- Goals
- Motiviations
- Frustrations
> *"Wasabi wallet is the first selection of privacy seekers."*
### Contacts
#### History of Labeling in Wasabi
- We didnt know how to use it.
- Tell users to label everything
- Then we realise the labels are best used if you specificy who the observer (people and entities) who knows whats happening with the transaction.
- Brought up issues
- How should label be called -> final observers
- Tradiitional labeling functioanlity disappeared
- Recieving from Company
- Should observer be every person at the company?
- In the end it was reverted to labels
There is only one useful descriptor (..for?)
- the one that encodes the xpub and script type
- payment code and output descriptor are bascially the same
### Proposed Payment Flow
#### How would other schemes like BIP78 be hooked onto this payment flow?
- Given I have pasted a Bip21 with PE2P param
- When I submit the payment
- Then it is added to the queue
- And I await the response
##### Clarify: Paying with credentials
##### Payjoin in a Coinjoin (wabisabi anonymous payment)
- "Reality check this is not a easy user flow"
- "It isn't something that can't be done"
#### How would lightning be implemented into this payment flow?
- [Airtable Form](https://airtable.com/shrbV7JXJCNuJWhHr?prefill_Priority=High&prefill_Privacy%20Level=High&prefill_Send%20via%20Coinjoin=True)
### Consistency of Queue, Coins, Transactions
### ACKs
- Labels as a Contacts Book
- Simplified Send Payment
- It is not just a bunch of features that are disjointed, but they play together
- (needs to put together in a ui)
- How should it be exported?
- vCard
### Summary
- There are concepts in here that are not inline with the goals of Wasabi 2.
- How is this going to accomodate for future features like lightning network
### Lightning Payment Privavy
- Payment hubs Paper (ask yuval).
- Doesn't have much to do with the payment flow but how things are set up.
- ...
### Problem: Lightning having to be online
- Should not be worried about
- Now everyone is online all the time
### Pay2Endpoint will be an important aspect of the future privacy and ux considerations in wallets.
- See magic wormhole
- Addressing the always online option
- Does not need to be always online
- Just only needs to be online during the exchange, like in messaging applications.
### Retrospective
- Miss understandings of the causual user persona
- In order to show to a wider audiance we need to have a nariative.
- This is not about wasabi
- This is the persona going through the process
- Consistency (navigation, transaction fragements)
- Familiarity
1. Intro
2. Setup of native with Alice
3. Prinpals
4. Consistency
5. Fragements coin list etc
6. Famarilitiy
7. Contacts List to give famialiritiy
# Table Of Contents
## Introduction
We started with a question @nothingmuch posted about amount organisation in the Bitcoin Design Slack - and it has lead us down its own rabbit hole of exploring use cases and user flows private payments together.
## Prinpals
### Consistency
### Famarilitiy
Lots of concepts being used in wallets are technically driven and often get surfaced to users in the interface causing confusion or a feeling of something being too forign.
## Concepts
### Transaction Fragements
### Batching
## User Concepts
### Payment Request
### Send Payment
### Contacts
### Pending Items