# `#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