Bisq-2 UX challenges

[chimp1984]

I just had a conversation with @UX-P about Bisq-2. To summarize the information about the UX challenges and rough ideas I thought its best to post it here for further discussions.

Bisq-2 comes with multiple options on many different layers.
I give here an overview about different categories. Some are constrained by each other, but some have flexibility (e.g. Fiat settlement is a flexible option for current Bisq protocol but not BTC settlement as its integrated with the security aspect). I give examples of the options we intende to integrate. Initially it will be limited to the most important, but conceptually those options are open.
Options are roughly sorted from "best" to "worst" according to core values of Bisq (security, privacy, accessibility, convenience). I only add those where we have already experience or at least a good idea about it. There will be more like interesting options using Oracles, DLC based contracts,...

• Multiple clients
  • Desktop application
  • Headless application controlled via REST or Grpc API
  • Mobile light client (remote control for a full node in users control)
  • Mobile (semi) full node client (will likely still use some specialized nodes in the network for Gossip network functionalities, but does not require running an additional full node.
• Multiple contract types
  • Asset Swaps
  • Options
  • Futures
  • CFD/Bets
  • Loans
• Multiple trade protocols
  • Atomic BTC <-> BSQ swaps
  • Atomic asset swaps on Liquid (e.g. BTC-L <-> USDT)
  • Atomic cross chain swaps for BTC <-> XMR based on Farcaster protocol. Could be extended to other coins as well
  • Lightning Network (LN) based 3 party trade protocol (@stejbac is working on that, not 100% sure yet if its feasible)
  • Bitcoin MultiSig based protocol (like current Bisq protocol using 2of2 MS + delayed payout tx). Supports dispute resolution with mediators and arbitrators.
  • Bitcoin 2of2 MultiSig without dispute resolution
  • BSQ bond based protocol. Reputation is provided by locked up or burned BSQ
  • Reputation based off-chain protocol. Does not provide security based on smart contracts but use reputation (flexible what type of reputaton is used, can be a social media account or PGP web of trust).
• Multiple security mechanism (constrained by the trade protocol)
  • Atomic swap on same chain
  • Atomic cross chain swap
  • MultiSig based
  • Collateral based
  • Reputation based
• Multiple smart contract layers
  • Bitcoin mainnet
  • LN
  • Liquid
  • Monero
  • Bisq DAO
  • Any other blockchain if a trade protocol requires it
• Multiple wallets (wallets integrated via RPC if trade protocol requires it)
  • Bitcoin core
  • Electrum
  • Liquid wallet
  • LN wallet
• Multiple settlement methods for the crypto currency (if not constrained by the trade protocol)
  • Bitcoin mainnet
  • Bitcoin on LN
  • Wrapped BTC on Liquid, RSK or ETH or any other blockchain
• Multiple settlement methods for the fiat side
  • Bank transfer
  • Fintech payment providers
  • Cash by mail
  • In person
• Multiple identities (an identity is a key pair and a network address - like onion address). User can manage identities.
  • Isolated identity for each interaction (best privacy, but does not allow features like reputation, account age witness)
  • One Identity per payment account (avoid linking ID from trades where real life ID is exposed - like SEPA - to others with better privacy where only a user name or email is exposed - like Revolut)
  • One Identity for all fiat accounts, one for all altcoins accounts (avoid linking ID over to altcoin trades)
  • One global identity for all (privacy like in current Bisq, allows local reputation and account age witness feature)
• Multiple privacy networks
  • Tor
  • I2P
  • Clear net (only relevant for network nodes like seed nodes)

These options create a variety of trade-offs between different core values:

• Privacy
• Security
• Accessibility (mobile vs. full node, simple UI for newbies vs. feature richness for pro traders)
• Convenience (speed, effort for technical setup like running a full node,...)

It would be good to show for each option the trade off (e.g. some graphical element indicating that the selected option is great for security but comes with some costs on convenience). This should help to build awareness that one cannot get the best of all -otherwise we would only implement that ;-).

To not overwhelm the user with the amount of functionalities and options we need to find a UX solution which radically simplifies all that.
I think it is possible to start with a default (recommended) path and guide the user through the various steps, offering options to dive deeper at each level and learn about the context of each option. It might have some aspects of a guided education experience where the user learns more iteratively and related to their goals (e.g. a hardcore BTC maximalist does not need to learn about XMR-BTC swaps).

It could start with a UniSwap like interface of what the user wants (I only sketch out an asset swap here).
Initially the user sees 2 sides for the assets with an amount text field and a combobox for currency selection.
In between the 2 fields is the price which is set to the market price by default. A next button moves to the next step.

I have:
[____] [EUR]
Price: 45 000 BTC/EUR
I want:
[____] [BTC]
[>> Next]

Then in the next screen we move further down the options tree (select protocol,...). Maybe we can use an approach to derive information from the application data to select the recommended option. E.g. if the user has BTC in their wallet the protocols requiring BTC are in the recommended options list.

[chimp1984]

An additional idea to lower teh barrier of entry would be to add a special kind of offerbook which does not contain executable offers but offer intents with some very basic information the user provides and knows without learning about Bisq (e.g. I want 0.01 -0.02 BTC for a good price. I can pay in EUR).
Pro-traders with reputation (e.g. using locked up BSQ , we need to ensure to keep scammers out) can be the counterparties to engage with those newbies in a private chat and figure out which kind of offer is suitable for them. The pro-trader can either point the newbie to an existing offer or create a new one for them.

It is very similar to the keybase trade model but bringing the trade execution settlement to the Bisq app and onboard a new user so they feel more comfortable to go on trading with the regular model later.
Maybe @pazza83 has some input here?

It would also emphasise the social aspect of Bisq (you are trading with a real person, can learn from them, interact with them) which is a very distinguishing aspect not found in DeFi platforms like Uniswap or CEX.

[Conza88]

They have to be online for it to remain taken? Or that also getting scrapped? Expiry of offer? e.g. set a week, and if not taken - disappears?

[pazza83]

It is very similar to the keybase trade model but bringing the trade execution settlement to the Bisq app and onboard a new user so they feel more comfortable to go on trading with the regular model later.
Maybe @pazza83 has some input here?

Having the Bisq-2 allow for new traders, with no BTC, begin buying BTC on Bisq directly in the app would be a positive step forwards.

Currently the Keybase model relies upon reputation. I like the idea of Bisq-2 having multiple identities so that an established trader could use on identity linked to reputation and/or BSQ bond to facilitate a trade with a new user, whilst at the same time have a separate identity for say the BTC/EUR market or BTC/BSQ market that does not link to any reputation or BSQ bond.

The current Keybase model could be improved in Bisq-2 by the following:

• Have options for traders (with reputation / BSQ bonds) to make offers to sell BTC for specific payment methods / currency
• Have option for new traders to make offer to buy BTC with specific payment methods / currency
• Inclusion of a chat function in this market for buyers to ask questions and sellers to answer
• Inclusion of a support feature should either trader want to escalate trade to mediator / support agent
• A way for Bisq to charge trade fees on accepted trades

To be fair there might not be much difference between the market above and a market for those who choose to use a reputation or BSQ Bond security model to complete their trades. Maybe the market above could be limited to a specific BTC/Fiat amount and/or only include sellers that have had their reputation verified and/or have a required amount of bonded BSQ.

I really like all the possibilities that would come with Bisq-2 but I do agree that it brings with it significant UX challenges. This is made even more complex by being able to run Bisq on multiple clients. Would the idea be for the design to be mobile first? Should you be able to do everything on a mobile you can do on a desktop? Also are is a users client's able to connect at the same time / used interchangeably, or, will it still be the case that only one instance of client can be used?

[chimp1984]

Yes some sort of reputation will be key, otherwise scammers will take over. Yes I agree it will be very similar to the reputation based trade protocol, the intent was to provide a more simple user interface and bring in more the social aspect.

Would the idea be for the design to be mobile first?

We don't have a dedicated mobile developer, so that would be one reason why thats rather a NO. The other is conceptually it will ad more complexity (some sort of relay nodes will be likely needed). Also for the semi-full version, it will likely only work on Android as Tor on iOS is a challenge.

Should you be able to do everything on a mobile you can do on a desktop?

The basic use cases should work on mobile as well. But have not thought deeper about it...

Also are is a users client's able to connect at the same time / used interchangeably, or, will it still be the case that only one instance of client can be used?

Thats problematic with the onion address (or I2P address). If you run both apps its not clear which one will receive it (I think Tor would behave like a load balancer, so randomly one or the other hidden service would get the message). Also data synchronisation will be a challenge. The apps supporting such features are all based on centralized services where all your data is kept, with such a model that can be easier achieved.

[pazza83]

Thanks for explaining. So the multiple clients should still be seen as stand-alone as most users will be using one Bisq instance on one type of client.

I assume the mobile light client will allow users to connect to their Bisq desktop or headless application? Would the UI for this similar to the mobile (semi) full node client?

Mobile (semi) full node client (will likely still use some specialized nodes in the network for Gossip network functionalities, but does not require running an additional full node.

This will be the client that increases accessibility by allowing users with only access to an Android phone to connect to the Bisq network.

We don't have a dedicated mobile developer, so that would be one reason why thats rather a NO. The other is conceptually it will ad more complexity (some sort of relay nodes will be likely needed). Also for the semi-full version, it will likely only work on Android as Tor on iOS is a challenge.

Do you see Bisq-2 being developed primarily for a desktop application that can also be accessed via a mobile running Android? Could therefore a mobile option be a later addition to Bisq-2?

I guess I am asking how high up the priority list is Bisq-2 being able to be run from a mobile device?

[chimp1984]

I have not thought too much about the mobile app. But basically the light client might have only minimal use cases as a full node is anyway needed. Similar like currently the API does not support all Bisq use cases.

Bisq-2 has lot of challenges and comes with a lot of work. My focus is on the desktop app, but I would love if we can develop in parallel the mobile app as well, but it depends on dev resources. Atm there is no mobile dev and it would be a bit too early anyway as too many things are still very open and not worked out in details.

[chimp1984]

I have tried to lay out a possible user journey for creating an offer.
Feedback highly appreciated....

The idea is to have a process which is easy enough for newbies to follow. Pro traders can choose to get displayed all the steps in one screen to get a faster experience.
All sections after protocol selection are optional and context specific to the chosen protocol. In many cases the summary section is shown after the protocol selection.

An open question is if we should support multiple protocols to be selected for an offer. Power trader will probably like to have this feature but it increases UX complexity quite a bit. Maybe we prepare to support it technically but leave it in the UI with a singe protocol selection, which will likely be the default use case for most users anyway.

Selection of the contract type (e.g. Swap trades, Loans,...) is done by choosing the relevant UI menu item. This only models a swap trade (asset spot exchange).

Swap Trade

1. Asset selection

Swap 
---------------------------------------------
From:  [BTC]
To:    [USD] 
---------------------------------------------
[NEXT >>]
---------------------------------------------

2. Set amount and price

Here the previous screen expands to show also the input fields for the amounts and the price information, fields and toggle. A advanced option icon enables to enter an amount range as well.

Set amount and price
---------------------------------------------
From: 	[  0.01] [BTC]
@ Rate: [  0.00] % <-> [50 0000] BTC/USD 
To: 	[   500] [USD] 
---------------------------------------------
[NEXT >>]

3. Protocol selection

The amount/price section gets now visually into the background but user can still edit and change it

---------------------------------------------
From: 	[  0.01] [BTC]
@ Rate: [  0.00] % <-> [50 0000] BTC/USD 
To: 	[   500] [USD] 
---------------------------------------------

Table with protocols show different properties. Only those which work with the selected assets are enabled for selection.
User can select multiple. Some info icon will link to more details.

Choose trade protocol(s):

Protocol type	Select	Security	Speed	Costs	Convenience	Settlement	Trade amounts
Atomic cross chain swap		Best	1 block	Miner fee	Require full nodes	XMR/BTC	0.0001 BTC-2 BTC
Liquid swap		Best	1 block	Miner fee	Require Liquid wallet	Liquid	0.0001 BTC-2 BTC
BSQ swap		Best	1 block	Miner fee	Require BSQ wallet	BTC	0.0001 BTC-2 BTC
Bisq multisig		High	min. 1 block, max. 4 days	Miner fee, trade fee	Medium	BTC onchain, Fiat accounts, Altcoin wallets	0.0001 BTC-2 BTC
LN 3 party protocol		High	max 1 day	LN fee, trade fee	Require LN node	LN	0.0001 BTC-0.5 BTC
BSQ bond based		Medium	Can be instant	trade fee	Require BSQ	Any	0.0001 BTC-0.1 BTC
Reputation based		Low	Can be instant	trade fee	Require manual risk assessment	Any	0.0001 BTC-0.05 BTC

4. Settlement options

Settlement options if protocol selection supports it. If the chosen protocols do not have optional settlement this section is skipped.

The protocol you have chosen lets you define the settlement option. Please select which you support:

Reputation based: 
Send BTC with: [On chain, LN]
Receive USD with: [Zelle, CashApp]		

Bisq multisig (the BTC side is onchain):
Receive USD with: [Zelle, CashApp]		

5. Protocol specific options

Depending on the selected protocols there can be more options be set.
If the chosen protocols do not support options this section is skipped.
Some of those options might be integrated in the previous screens already when the user clicks on "advanced options" buttons. E.g. set a range for the amount or a trigger price to deactivate the offer. Other options like fee payment (BSQ or BTC) or security deposit are only relevant for certain protocols.
Options are pre-filled with recommended default values.

6. Funding

Depending on the selected protocols there might be requirement for reserving funds for potential takers as it is the case with the Bisq multisig protocol.
If the chosen protocols do not require funding this section is skipped.

7. Choose identity

The user can choose to use a new identity for each new offer (default) or if they have decided against that they can select which identity to use for that offer.
This section is only for advanced users who prefer full control. By default it is not shown.

8. Offer summary

Show a summary of all details about that offer and a publish button to publish it to the network.

[ripcurlx]

Looking good already! Here are my comments:

1. Asset selection
   Swap

I think we shouldn't use swap at this step already as the protocol will be chosen at a later stage. I'd rather go with Exchange or something similar.

The amount/price section gets now visually into the background but user can still edit and change it

I'm not sure if we should let the user edit it in this screen, I'd rather offer a step back. This makes screen design more clean (keeps validation at one place) and I also think noobs are more used to this step by step (go back to previous step) methodology.

Table with protocols show different properties. Only those which work with the selected assets are enabled for selection.
User can select multiple. Some info icon will link to more details.

I'd only show what is possible and hide what is not. I'd go even that far to hide all possible protocols and only show our suggested one for this exchange. Letting the user open the available options if she wants to. IMO 90% will go with the suggested option. We can introduce the user to other protocol options at a later stage of her user journey in Bisq.

4. Settlement options

Settlement options if protocol selection supports it. If the chosen protocols do not have optional settlement this section is skipped.

I'd again only show/suggest one option and let the user expand to see the other option available if she is interested.

[pazza83]

@chimp1984 thanks for detailing the user journey for creating an offer.

The idea is to have a process which is easy enough for newbies to follow. Pro traders can choose to get displayed all the steps in one screen to get a faster experience. All sections after protocol selection are optional and context specific to the chosen protocol. In many cases the summary section is shown after the protocol selection.

With regards simplifying the user journeys I wonder if making and taking should be treated slightly differently on the assumption that Bisq newbies are more likely to be takers. Therefore, this process can/should be simplified (also there are less options to choose from as they are essentially filtering the existing offers).

Therefore, if having an easy process for newbies to follow, maybe, it should focus on getting them to take not make an offer.

An open question is if we should support multiple protocols to be selected for an offer. Power trader will probably like to have this feature but it increases UX complexity quite a bit. Maybe we prepare to support it technically but leave it in the UI with a singe protocol selection, which will likely be the default use case for most users anyway.

I think it would be ok to have only one protocol per offer. Each protocol will likely come with a different security model and would be priced accordingly. I imagine it would get too complex to have price being dependent on multiple variables eg; protocol, payment method, identity chosen etc. Maybe it would be good to define what is likely to be fixed per offer; eg price, protocol, identity?

1. Asset selection

Swap 
---------------------------------------------
From:  [BTC]
To:    [USD] 
---------------------------------------------
[NEXT >>]
---------------------------------------------

Do you anticipate the following will be possible?

Swap 
---------------------------------------------
From:  [BTC ] or [XMR] or [ETH] 
To:    [USD] or [EUR] or [GBP] 
---------------------------------------------
[NEXT >>]
---------------------------------------------

Would be great if Bisq 2 could allow offers to be created that increased liquidity by having multiple ways a taker could fund them, and allow them to be for multiple currencies. Similar to as proposed in Proposal to increase liquidity on Bisq by allowing each offer to have multiple payment methods and currencies associated with it.

2. Set amount and price

Here the previous screen expands to show also the input fields for the amounts and the price information, fields and toggle. A advanced option icon enables to enter an amount range as well.

Set amount and price
---------------------------------------------
From: 	[  0.01] [BTC]
@ Rate: [  0.00] % <-> [50 0000] BTC/USD 
To: 	[   500] [USD] 
---------------------------------------------
[NEXT >>]

Can a BTC Buyer can come along and say I would like to buy 500 USD of BTC what are the offers available. This would be great but also it would seem to add more challenges. I am not sure what assets will be constants and what assets will be variables, or if all assets will be variables. Probably not explaining myself very well :) It would be great if everything was variable but I would imagine this would not be possible technically?

3. Protocol selection

I am assuming one protocol per offer...

Therefore, how I would anticipate the protocol selection is a little different.

I would make this this first choice.

Eg:

1. Choose Buy / Sell
2. Choose protocol

In my imagination both these options would be in the GUI, and are selected prior to beginning to make an offer.

Also, I think it would be a better user experience for the more 'difficult / knowledge based' decisions to be made earlier on in the user journey. Things should get progressively easier not harder :)

[chimp1984]

Yes, I think there will be only one protocol per offer supported.
Multiple payment methods will likely be supported. I am working currently on that part.
The need for reserving funds for an offer will likely get removed also for the Multisig protocol. For the others its anyway not there. So creating multiple offers has less "costs" as in current Bisq.

[Conza88]

Being pedantic; but if protocols could be removed from being shown i.e. like currencies I will never use can be removed, that would be great.

[chimp1984]

I'd rather go with Exchange or something similar.

Yes, still trying out whats the best term here... I just want to avoid the buy/sell terminology as it does not work well with currency pairs where its not clear what the base (dominant) currency is, like when exchanging BTC-L to WBTC or altcoin-altcoin or fiat-fiat.

I'd only show what is possible and hide what is not.....

As we will start anyway only with 1 or 2 protocols and slowly grow that over time, I think for the start we dont have that problem anyway. But later when the full spectrum is available I am not sure if we can really make the selection for the user.
E.g. if they want to change BTC-USDT there are likely at least 2 or 3 realistic options (Liquid swap if the user has a Liquid wallet added, Bisq Multisig, Reputation based). Sure we can still try to make the best selection from what the app knows (e.g. if a Liquid wallet is added or if the user has set up a USDT account for Bisq Multisig or if he has created a user profile with some sort of reputation for the reputation based protocol).

I'd again only show/suggest one option and let the user expand to see the other option available if she is interested.

I think that will not work well as its for instance the payment method selection. If the user has only one payment method for that asset pair then we can auto select it as in Bisq but otherwise we cannot make the decision for them.

I started yesterday a bit with it but I tend to just implement the technical part probably as a one page contains all options version which might be the "expert version" later with full control about all options.
I use the current Bisq design as I don't want to sped too much time on design/styling as long we have not even a dedicated design and css is not my strength anyway...
Based on that, I can continue to work on the domain part and a UI dev can pick that up and work with @UX-P on the best solutions.

[UX-P]

This is really helpful. @ripcurlx I’ve started on a user flow diagram and will post it soon for feedback on design considérations. @chimp1984 when possible, please could I have the following details for the diagram:

Could I know which one or two protocols Bisq2 will be initially using?
Key user needs that may help you choose: Fast transactions, cheap fees, privacy, trust and the accommodation of users who have no Bitcoin to trade.

If there is not yet a confirmed decision on this, could you suggest two examples that can temporarily be used for the user flow.

Once this is decided, I would need information based on the 1 or 2 chosen protocols:

Protocol selection
Table with protocols show different properties. Only those which work with the selected assets are enabled for selection.

• Which assets combine with each protocol?

Settlement Options

Settlement options if protocol selection supports it.

• Could you please provide a list of settlement options, matching them to each protocol if applicable.

Protocol Specific Options

• Please provide a list of the specific options for each protocol if applicable.

• List of advanced options for each protocol

• Which protocol requires fee payment and security deposit?

Funding
Depending on the selected protocols there might be requirement for reserving funds

• Protocols which require the user to reserve funding, if any.

Thanks!

[chimp1984]

Could I know which one or two protocols Bisq2 will be initially using?

I think a reputation based protocol (similar like users trade in the keybase channel, security is based on some sort of reputation) is likely the easiest to implement. I plan to start with that first as it also does not require wallet integration.
The next might be a Liquid Atomic swap. I think that would be also quite easy and would give a great user experience for very fast and safe swaps (Liquid has 1 min. blocks).

The next priorities from my side would be the current Bisq Multisig based but that will require also the DAO integration so that will come with higher effort.
Atomic cross chain swap XMR-BTC is also a top prio but might be one of the more challenging ones and will require to user to run some extra software (likely: XMR full node, BTC full node, farcaster daemon).

Key user needs that may help you choose: Fast transactions, cheap fees, privacy, trust and the accommodation of users who have no Bitcoin to trade.

Yes I think with those 2 mentioned we cover quite some space which is currently not served in Bisq. Current Bisq will probably also operate just in parallel until all the features are implemented in Bisq 2.

Which assets combine with each protocol?

The reputation based protocol is totally open to asset selection. People can trade anything against anything also fiat-fiat. Though we should make clear a boundary that we do not want to support a OpenBazaar like marketplace as this comes with very different challenges, even there is quite some overlap technically.

The Liquid swap will support all Liquid assets, main focus will be on BTC-L and USDT. I guess they started with NFTs as well and game tokens. I am not following (and not interested) in those, but as long they can be swapped as an asset on Liquid there should be no limitation. Contrary to Bisq there will not be a curated list of assets users can trade but will be open to anything users want to trade as long its technically supported.

Could you please provide a list of settlement options, matching them to each protocol if applicable.

For the reputation based protocol there will be also no limit. We will likely integrate the major settlement methods which we support in Bisq (SEPA, ZELLE, Revolut,...) but contrary to current Bisq there also will not be a curated list of settlement methods, but users can add their own in some flexible format (this will lack some validation features and counter-parties need to pay more attention to potentially insecure methods).

For Liquid swaps both sides are settled on-chain on Liquid.

A main challenge for that reputation based protocol will be how to make it sufficiently secure to keep scammers out. It might be that initially only DAO approved sellers can trade there. E.g. to limit it for users who want to buy their first Bitcoin from trusted Bisq contributors/market makers who have set up a BSQ bond and got support by DAO voting.

Please provide a list of the specific options for each protocol if applicable.

There will be some options which will be available for most protocols and mostly integrated into the relevant UI area.

• Range for amount by adding a min. amount value (integrated into the amount input UI)
• Percentage based price following market rate
• Trigger price to deactivate offer (as in current Bisq)

Reputation based protocol:

• Chat user name. I have not thought out the chat integration but I assume it will be mandatory to provide a user name, even if its the derived automatically from the offer ID. But for earning reputation users will likely stick to a chosen user name.
• Max. duration for the settlement
• Reputation info (BSQ bond based, social media account link,...)
• Maybe: Break down trade amount in sequence of smaller trades (e.g. newbie wants to get 0.1 BTC but 5000 USD is too much of a risk to send to a market maker, so they decide to split it into 5x 1000 USD payments and only after the buyer has received the BTC they move on to the next trade - buyer has to send fiat first, so they take the higher risk). Not sure if that should be an option as user can negotiate that in the chat as well.

Liquid swaps:

• I am not familiar with securities on Liquid but I assume to trade those some KYC checks are required as they are only open for KYCed investors. If that is the case, there might be assets which require some KYC verification integration. Not clear yet if that would be feasible to support in the context of Bisq's privacy focus. For the start I think we can ignore those sort of assets. Beside that I am not aware of a potential option for Liquid.

There might be options for the fee payment for any protocol.
The fee payment is an open question and not clear idea yet how we deal with it. We do not want to add friction for fee payment or degrade privacy. For the reputation based protocol it could work via the market makers. E.g. they have to burn BSQ to get the "license" to trade there. They earn by market price premiums so they can calculate those costs into the price and the newbie trader pays the trade fee indirectly via the price.
For Liquid we could add some bonded role in the DAO who receives the fees on Liquid and sells it to BTC and then to BSQ and burn the BSQ. Is a bit of a hack and not great.... Maybe we launch BSQ on Liquid some day then it would become easier to just pay the fee in BSQ-L. For the start we can just omit the fees as well. Maybe Blockstream is interested to support Bisq and thus making fee payment less required as well?

List of advanced options for each protocol

The advanced options are those which are not required to be changed by the user and can be left to default values like security deposit in Bisq. On the other hand selecting a payment method can only be pre-selected in case the user has only one payment method for that currency but of there are multiple the user need to decide and we have to make the choice more prominent in the UI.

Which protocol requires fee payment and security deposit?

Regarding fees I wrote above already. It largely an open question.
Security deposit is so far only required for the Bisq Multisig protocol.

Protocols which require the user to reserve funding, if any.

I think thats as well only required for the Bisq Multisig protocol.

Atomic swaps require to have funds in the wallet so that when a taker takes the offer it can be executed, but it will behave similar like BSQ swaps where the funds are not "reserved", instead we check the wallet balance if it can serve a potential trade. This allows multiple offers which would in sum exceed the wallet balance. To avoid lack of funds problems we update the visibility of offers each time the wallet balance changes, so if there is not enough balance for a certain offer this offer will get hidden from the network until the wallet has sufficient funds again (it will get automatically republished then).

Hope that clarified things.
There are still many open areas where we have to work out the solutions step by step...

[UX-P]

Thanks for the detailed response, this most definitely clarifies a lot of points. The user diagram will hopefully help to identify some open areas and introduce new considerations.

[chimp1984]

I found out now whats the confusing issue in current Bisq for people with Buy/Sell direction. We use always BTC for the buy/sell perspective also for altcoins where the base currency is the altcoin.

The concept of base curreny and quote currency carries already the information what is the part which one considers to buy or sell because the quote/price is the price for 1 unit of the base curreny, so the base currency is always what to buy or sell. For BTC-Fiat that is BTC and is also as it is used in Bisq. But for altcoins the altoin is the base and here the confusion happens as in Bisq we treat also BTC for the BUY/SELL perspective.
Futhermore the Buy/Sell separation in the screen does not work as one has to first select the market to define what the base curreny is.

I intended to drop the BUY/SELL concept/terms in favor of "want/ask" and "have/bid" but that does not match well with the market and quotes. There is some network effect which has led to a one sided market (e.g. There is only a BTC-USD market but not a USD-BTC market). For some Forex inverse markets exist (e.g. EUR-USD and USD-EUR) but that is expectional and we would not get market quotes for any crypto markets if we arbitrarily flip base and quote currencies. For new markets or niche markets there might be in fact that some exchanges list it the one way and others the opposite way and there might be 2 opposite quotes, but I guess we can ignore that and network effects will favor one as the winner over time.

So my current plan it so move back to the BUY/SELL term, basically as used in the Fiat markets in Bisq. And I realised that the market selection is the first important step.

So my updated concept is:

1. Select market (currency pairs)
2. Select Buy or sell (always in perspective to the base currency from the chosen market)
3. Set amounts and price
4. Select trade protocol
5. Select settlement method

I had implemented most of that alreayd but after figuring out that the ask/bid concept does not work well I will redesign what I have and move on to the option selections...

I also did check some of the CEX where I have an account and they basically all follow that concept as well.
Some offer next to the normal trade a swap like or instant trade option where the use the terms: FROM -> TO similar like in uniswap.
I guess there might be some option in Bisq for offering such similar trade option as well by using bonded market makers, but I prefer to stick atm on the main trade concepts.

[chimp1984]

Here an update of my current prototype:

Instead of settlement methods it will be the user settlement accounts. If the user has none yet setup they can add one...

I tend to not support multiple protocols as that makes UX much more complex.
I will probably still support it in the domain so it can be added later, but I guess the extra costs on UX and dev effort do not justify the benefits (likely only used by some pro traders). A trader can publish multiple offers with diff. protocols. The extra cost for reserving BTC for an offer will likely be not present in Bisq 2 anyway and if still its only for the MultiSig based protocol.
But we plan the improve the MultiSig based protocol as well with the ideas around the one-tx protocol proposals...

[ripcurlx]

Looking promising already as a power user interface 😄
I also think having Buy/Sell in one screen makes it easier to grasp 👍 . Is there a reason why you named the navigation on the left Swap trades? Maybe it should be named just Buy/Sell? Regarding the naming of markets we could also think about if trading pairs is easier to understand for a user. I'm also thinking about what we could name trade protocols instead. It sounds very technical and intimidating for noobs IMO. Maybe How do you want to secure your trade? > Select security guarantee? or something similar?

[chimp1984]

Yes agree, wording should be improved. Have not spent too much time on that yet. Swap trades was from the original intention to avoid buy/sell and use more the mental model of swaps but that is dropped, so will rename it.
We still could use the swap terminology when users trade assets where there is no market (e.g. liquid assets), but dont want to spend time on that niche... But the current concept requires that there is a clear definition whats the base and quote currency / e.g. that there is an existing market defined (and quotes are available).

I prefer to keep the more technical terms for the current state as it helps me to design the domain but once that is more of less complete we can ask @m52go if he can help to find better terms.

[UX-P]

I have started a User Flow diagram of the reputable trader and new trader user journey demonstrating a way in which their paths could potentially cross to make a successful trade. This helps to identify user behaviour and pinpoint delays, successes and drop off points. When you go through this it is important to note how you feel during the journey.

Feedback is very welcome as it helps with identifying and working on improving these touch points.
Please also feel free to contribute in pinpointing any technical aspects I would have not considered and which parts would need reviewing as this is currently a base to help with designing a user focused UI.

The aim is to keep creating scenarios based on real life users to consider all aspects of the user journey. The diagram is based on the scenario below- a new trader wanting to purchase BTC using the Bisq 2 reputation protocol:

Scenario

'I am a new trader, I would like to trade Fiat to BTC to get started on Bisq. I’m not sure how much I would need as I am not too familiar with Bisq. I would prefer to trade with an experienced Bisq trader but I’m open to less experienced members of Bisq too.'

Click here to view User Flow

@chimp1984 I have just seen your posts, could you list any key options I may have missed out on?
@ripcurlx this layout provides a good view of where the terminology could be reviewed more effectively.

UX journey explained

Welcome page
Short welcome to Bisq 2, briefly stating the improvements from Bisq 1 using keywords: privacy, faster transactions, P2P, decentralised.

Tutorial
Short walk through/step by step guide on how to use Bisq 2 including where to go for support.

Contract type

• Reputation or liquid swap

• Tooltip available regarding reputation

• Tooltip available regarding liquid swap

Trader types

3 target markets have been identified for the reputation pathway.
The new trader, medium trader(regular) and reputable trader.
They all three have different paths and although they will cross during the user journey, the UI should accommodate for their individual needs.

1. New trader- No Bitcoin and would therefore require to buy BTC to get started on Bisq 2.

• Include tooltip on reputable trade

2. Medium trader- Has performed at least 1 trade using Bisq 2 (just an example, wording and trade amount can be changed).

• Trader has an option to create a username, UI should use wording to express this option is recommended for those who want to become a reputable trader

• Include tooltip on reputable trade

3. Reputable trader- Has performed a certain amount of successful trades, measured against their set username.

• Perhaps those currently known on 'buy-bitcoin' channel as regular sellers, should automatically be labelled as reputable.

• Include tooltip on reputable trade

Reputable trader

Profile
A small section with options based on the way users currently interact on #buy-bitcoin channel e.g. trade range, payment methods accepted etc.

Create username
Username is mandatory if the user wishes to be a reputable trader. I’m not sure this should be optional because as @chimp1984 mentioned, this is a part of the reputable trader experience. How do we avoid username clash?

Payment method

• Drop down menu of all options including a custom field SEPA, ZELLE, REVOLUT etc

Custom option should always be a secondary option.

• Consider this as a type box with predictable text, users should have the ability to add several payment method options similar to the interactions on Keybase.

Publish
Publish on the 'offers' tab containing a list of other offers from all 3 trader types. The trader has the option to wait to be notified of any potential traders or they can browse the 'offers' tab.
Filter new trader, medium trader or reputable traders available.
I can demonstrate on the user flow the events that will occur the next time the reputable trader opens Bisq 2.

Terms
Terms highlighting what Bisq is not liable for including any legal obligations. Include privacy and warnings regarding the exchange of personal and sensitive information.

Notification of potential trade
If a new trader or medium trader has created a proposal that matches the reputable traders criteria then they will automatically receive a notification (opt out option). A pop up will show a summary of the offer, prompting the reputable trader to accept or reject the trade. If yes, the chat will open up and both parties will enter a trade.

When the trade is over the new trader will click on the 'Successful Trade’ CTA, adding to the reputable traders track record.

Leave a note after trade
These notes should be posted on a feedback community channel. Encouraging further interaction even after the trade process. It is also a positive continuation to the user journey and could lead to further interaction on Bisq/Bisq 2.

New trader

Exchange
Drop down with 0.003 BTC as the placeholder, marked as recommended. This is often the amount recommended on the Keybase channel for starters. New buyers often ask for amounts between 0.002 BTC and 0.007 BTC as a limit, so perhaps consider setting a trading limit to prevent scammers as demonstrated on the Keybase channel.

Fiat equivalent should be displayed, this is a user friendly feature to help users familiarise themselves with cryptocurrency amounts and also to continue the user journey without having to leave the UI for a conversion calculator.

Short note
A little intro.. ‘Hi I am looking to buy BTC to start trading on Bisq,’. A friendly note makes the trader appear more trustworthy and honest.

List of reputable traders
Once the new trader has filled out the proposal they will click search and reputable traders will be listed. The user will pick the one they desire and a notification will be sent to that reputable trader. In case of no reply, trader can cancel and select a new match or browse 'offer' tab.
If notification is rejected by reputable trader, new trader will have the option to select a new reputable match (if there is one), publish on 'offer' page or browse.

Trade
Both parties will trade via private chat. This gives them the freedom to interact with each other, encouraging a regular discussion between 2 peers and fully incorporating the social aspect of P2P trading. The buttons available will be ‘support’ and ‘trade successful’.

Waiting for an available offer
Is the Trader still waiting for an offer after .. days for a reputable buyer? Prompt trader to browse other offers.

Trade was not successful? Open support
In case of unsuccessful trade both parties will have the option to open support.

Trade complete page
The trader will have the opportunity to continue their journey by initiating their first trade using Bisq.

New trade?
Maybe they will prefer to stay on Bisq 2, particularly after a good experience. Provide this option to continue repeat a user journey on Bisq 2.

Finish
Provide an exit in case user would like to cease their journey

'Offers' Tab

• A page displaying a list of all trade offers

• Filter by asset, premium etc.

• Trader filter: new, medium, reputable

[chimp1984]

Great thanks for the user journey! Looks very good already!

Here some comments:

How do we avoid username clash?

Thats a good question and I just thought recently about it.

One possible solution would be to use as identity the hash of the pubKey and derive an image and text representation which is easy to remember.
Tari (and asset issuance platfrom based on Monero tech) is using a series of emojicons for the addresses (see https://rfc.tari.com/RFC-0152_EmojiId.html). This makes difference in addresses easier to recognize and its shorter as the alphabet size is 1024 compared to 58 for Base58 encoding.

Beside that we could append some short auto generated sentence to the user-selected (not clash resistant) user name. This could be similar like seed words but choosen in a way to make at least gramatically a correct sentence:
E.g. "Chimp1984 - The lazy blue walking bean"
The selection of the words could be derived from the pubKey hash as well. So even if one impersonates a reputable user the weird sentence will be different and its easy to detect.

Beside those attempts to create a human recognizable representation of the hash of the pubkey there would be options to link to external identities (e.g. web domain, social media accounts, PGP keys,...) or to use a name registry solution. I fear name registry will come with quite some effort and dependencies so I would prefer to avoid that.
Using external IDs comes with some privacy issues, but maybe those who want to gain reputation are less concerned about privacy and its acceptable.

Liquid for instance use the web domain name as key identity for asset registration. Only inside that domain name the asset ID has to be unique. They verify that by requireing the asset issuer to upload a signed text to their webserver. So they piggy back on DNS. They also support onion addresses so that allows privacy again. I don't know how they deal on the UX side with conflicting asset names/codes (but distinct asset IDs due the domain usage)? E.g. if there are 2 tokens with the code XTR and they both use the same name as well (e.g. ExtraCoin) then there is still a UX challenge how to avoid confusion. The UI does not want to present the domain name next to the short strings of code/name. Maybe someone with more knowledge in Liquid can add their insights here. I assume UX was not their main concern and they leave that problem to the platforms integrating the asset exchange (like Bisq 2 ;-)).

...prompting the reputable trader to accept or reject the trade. If yes, the chat will open up and both parties will enter a trade.

If I understand that correclty it assumes that the RT is online and reacts manually on a offer proposal, right?
If so, it might be a unpleasant delay if the RT is not online.
One option could be to let RT auto-accept and they have a certain response time to get in touch with the new trader. They still can decline during the chat if the RT considers the NT as too risky, but I guess most of the time it will work out and even there is a delay for the response, the NT has the feeling to get "served" immediately.

List of reputable traders

I think it would be good to show the online-status of the RT. RT traders being online will be likley preferred.

An alternative could also be to let the NT publish their trade intent and RT who are online can manually send a take-request. The NT might receive multiple and can choose based on the reputaiton of the potential takers.
I guess a main factor for the NT will be execution time, so that approach could optimize that. To do risk estimation by checking reputation and learn the context of it, is some form of work. I guess its better that we reduce that work for the NT as far as possible.

The buttons available will be ‘support’

What kind of support do you have in mind? I guess real arbitration cannot be done as there are no verifiable proofs. But to offer mediation support helping with confusions/honest mistakes type of problems should work.
Some option for "reporting scam" might be needed as well.

I think the NT-RT trade scenario is only about buying BTC from the RT, not the other way round, right? I think thats the main demand as well and that way the RT does not carry risk as the NT need to send the Fiat first and only after the RT has received it they will send the BTC.

Regarding fees:
I think the best way will be that RT have to burn a certain amount of BSQ (proof of burn feature in Bisq) to be marked as a RT.
This amount alows the RT to trade for a certain time/or for a certain accumulated trade amount.
The premium on the price will be used by the RT to get the costs back and to indirectly transfer the trade fee over to the NT.

E.g. RT burns 100 BSQ and gets with that the permission to be a RT for NTs.
Lets assume they can do 50 trade with 200 EUR in average, so thats 10000 EUR trade volume and lets assume premium was 10% over market so they made about 1000 EUR profit. They paid 100 BSQ (lets assume thats 200 EUR), so their net profit is 800 EUR.
No idea if those numbers are realistic but it should show the idea...

I think to have rather small burned BSQ amounts but repeated quickly (e.g. each month they have to burn 50 BSQ) would lower the risk and would increase the accumulated amount of burned BSQ which represents the reputation of the RT.
Burning BSQ has several advantages to BSQ bonds here:

• If a RT engages in a scam their reputation is lost forever. No need for the DAO to engage in confiscating their bonded BSQ with a 1-2 months delay
• Accumulated burned BSQ increase reputaiton over time. Even if amounts are rather small they sum up over time and it become less "profitable" for the RT to engage in a scam.
• A new RT has automatically lower reputation. Reputation is earned over time and repeated games, just as usually the case in real life.
• Burned BSQ is automatically the trade fee. Bonded BSQ could not be used as a fee. So it solves the open problem how to charge a fee for those types of trades.

[UX-P]

I like that trading fee idea! It'll be an interesting implementing this into the UI. I'll add it to the user flow to present a step by step view of this concept.

I guess a main factor for the NT will be execution time

Auto accept is good but could prohibit the user from searching other trades if they believe that the RT has accepted. The key thing here would be to keep the user informed as to what is happening at all times with a message specifying an approximate waiting period, a ‘while you wait’ suggestion for example joining a community chat called ‘Bisq waiting room’ (best UX could be to automatically direct user here after auto accept). If there is no answer from RT, a notification after the waiting period suggesting they browse other reputable traders.

This way the waiting period is a positive feature. It could also attract more legitimate users and deter scammers, I can't imagine many users with malicious intent would want to wait.

What kind of support do you have in mind?
Yes as you said, A mediator that can help resolve any issue on both sides by providing advice, links, answering any questions about the process etc.

I have a question. In the reputation protocol, would a RT trader require a profile to buy, or would they simply create a regular offer?
Wouldn't a RT trader otherwise use Bisq version 1 or the other available protocol for regular trades? It would be important to know exactly how a reputable trader would use this specific protocol and why, It might be something I can look into.

[chimp1984]

I have a question. In the reputation protocol, would a RT trader require a profile to buy, or would they simply create a regular offer?

I see 2 options for the reputation protocol:

1. Using burned BSQ as requirement to be a RT
2. Allow any type of reputation like a link to a social media account and leave it to the NT to estimate the risks

I think the first option will be more safe and easier for the NT. So maybe better to focus first on that that protocol type and maybe later allow a more flexible protocol.

For that BSQ secured protocol I think we should require the BTC seller to have some min. amount of BSQ burned as "entry ticket" for posting an offer or taking an offer.
The user profile should consist of a RT chosen user name + some TBD way to protect against impersonation attempts. Even those might be less risk here as the burned BSQ is the primary source for the reputation.

... how a reputable trader would use this specific protocol and why

The why is mainly because of a considerable better price. What I heard in the keybase channels premiums of 10-15% are normal. Those premiums are not possible in the normal trade protocols.

Sorry I have not thought too much about the details of the reputation based protocol myself, so its all quite open still.
I start today with the trade protocol and I guess in about one week I have some prototype and assume that some things get more clear on the way.

[UX-P]

Thanks, that does answer the question as a good reason why RTs would be interested in this concept. I plan to create a proposal based on researching current and potential new users to evaluate their needs regarding the reputation protocol, this should help with any grey areas and open up to new considerations.

[chimp1984]

Here an update of the create offer process:

I combined the settlement method selection with the account selection. For Fiat the user has usually an account set up. On the crypto asset side they can choose to support alternative settlement methods next to mainnet. E.g. user accepts also BTC over LN if protocol permits that.

If user has no account set up a create account button is shown.

The UI is very preliminary here and would require much more refinement. E.g. if there is only one option we dont want to show it as a selection component but maybe if it makes sense as informational text (when there is only 1 matching fiat account its probably still good to show which account is used but user does not need to do anything). For the crypto side it does not make sense to show it.
There might be requirements for the wallet as well. E.g. the user gets preselected options based on the wallets they have integrated (E.g. Liquid next to BTC).

I leave it from here to go over to the offer book and take-offer screens. The settlement/account/options part will require more detail work and will likely see some iterations, but I think it becomes more clear when having the full process in place.

Also as some others suggested, the protocol selection should likely be done initially. Maybe even by having a different menu item or some other graphically different approach rather than to treat it as a selection option among others.

[chimp1984]

Here is an update on UI prototype:
Offerbook and take offer screens. I started to work on the trade protocol now.

[ripcurlx]

Getting better and better 👍 Maybe we should just remove the not selected direction below the Take offer to: to prevent any confusion with the red and green color coding.

[chimp1984]

Btw. The take offer here in the screenshots do not match the offerbook (I uploaded another one later as there was some small UI bug). So the selected SELL does not match the selected BUY side in the offerbook. If the user would click on BUY in the offerbook it would be also BUY in the take-offer screen selected.

[chimp1984]

Yes I just reused the selection component but I will set the inactive side invisible, so its more clear.

[chimp1984]

@ripcurlx
Fixed:

[chimp1984]

Got a Liquid swap protocol structure implemented (no wallet integration yet, so no real txs) as well as open offer view, pending trades and closed trades views. The views are very basic but are functional with the domain data. Trade protocol steps are not implemented yet as Liquid swaps behave like BSQ swaps without manual steps. Will implement it when doing protocols which have delays and human interactions.

Will work next on the user name domain and burned BSQ based reputation protocol and chat.

[flix1]

It's all looking amazing!

I think allowing the user-defined "Other (please specify)" field will yield very positive surprises and very welcome flexibility as new payment methods appear in the next few years.

The multi-interface part will be important - there are large regions of the world where it is mobile or nothing.

As for trade protocol selection... I think we should not hide it too much. At least at first we should allow some experimentation and maybe even an user-defined option for off-Bisq reputation "Other (please specify)".

My guess is that:

1. Atomic swaps will dominate BTC/altcoin trade,
2. Reputation will be most used for small BTC/fiat trades (eg: lightning network to Revolut)
3. 2of2 multisig + DAO (current Bisq1 protocol) will still be preferred for larger BTC/fiat trades (eg: BTC Mainnet to SEPA).

So the same user could presumably want to use all three protocols on the same day without wanting to change settings every time...

However that is only my guess. I could be absolutely wrong and maybe some completely new protocol will come to dominate. That is why I believe it is very important to keep options open for the future and allow user defined fields.

I can imagine that a mobile app would be much more streamlined and maybe offer fewer options to keep UX simple.

[chimp1984]

A protocol requires some implementation so it cannot be added by a user like a payment method or a new market.

I prefer to start with the rather constrained social trading concept where BTC sellers need to have burned BSQ as reputation.

But a more open reputation based protocol can be added later as well. I just think that the constrained version serves newbies best as there are not much options and security for small amounts should be good enough that newbies dont get scammed easily. With a more open approach users need to be more careful. Like on LBTC or Paxum where its quite some learning for newbies to not fall into the scammers many tricks.

Also other tools for providing reputation are likely less privacy friendly than burned BSQ.

[chimp1984]

I think each market will get its preferred protocol:

BTC-XMR -> Atomic cross chain swaps

BTC - Fiat -> Bisq Multisig and LN based 3 party protocol

USDT- BTC -> Liquid atomic swaps

BSQ- BTC -> BSQ atomic swaps

Newbies, small fiat-BTC amounts -> Social trading (burned BSQ based reputation)

Altcoins-Altcoins: The same tech as XMR swaps could be implemented if there is sufficient demand, but I doubt that will become a priority soon. Some liquid assets and maybe even securities on Liquid might become a new niche market (game tokens, NFTs,...) but as well not a priority from Bisq's side, but if tech is already available (by USDT-BTC swaps) it likely comes for free.

[chimp1984]

Update of user profile creation (WIP):

[chimp1984]

Got a very basic chat implemented.

[andyDoucette]

I feel like this is way too complex. It will take a ton of time to code and also 98% of the people will just use the defaults and be too scared to change them. Plus, if we ask the user to make so many decisions/climb a big learning curve we'll just lose users. Can we do our research to see what small combination of these will hit 90% of of the mass-market use-cases with minimal risk and drop the rest? The pareto principle has been validated in my life time and time again. By not doing the research in the name of "future flexibility", we're really just pushing work on thousands of users that we should be doing ourselves. We should map out the best path or three through all of these parameters and just implement that - if we absolutely need to, we could have a setting that says "risk aversion level" that says "low, medium, or high", and that could motivate up to 3 possible combinations of all of the above parameters (right now there are 2764800 combinations).

[chimp1984]

If you refer to the create offer screen, that is not a design suggestion, but work in progress to get the domain implemented.
Goal is to have 2 variations. One for expert traders where they can control all details and options and one for new traders with the most limited set of options possible which might be:

1. Select market
2. Select BUY or SELL
3. Set Amount (price will be set to market price)

Depending on the market/currency pair the protocol will be preselected. E.g. BTC - Fiat will preselect the Multisig protocol. XMR-BTC will preselect Atomic cross chain swap.

For the MS protocol, yes we can use the default security deposit value so the user need only to have enough BTC in their wallet to be able to fund the offer and can complete. If the user has setup only one payment account that will be choosen automatically.

[flix1]

We've tried making choices for users before and it's very hard to take it back if you make a mistake.

I absolutely agree that UX is deteriorated by too many choices. In my experience with sales funnels every choice leads to a 20% drop-off.

However I believe that optimisation and UX streamlining should NOT happen at this stage, but rather on mobile apps and web-apps that use Bisq2 as a backend.

We should be humble enough to recognise that we don't know what users want and even less what they will want 2 years from now. So allowing experimentation and choices early on and not closing doors is the right thing to do at the base layer. Flexibility will be key in the coming years as new payment, privacy, exchange methods come online.

Yes this is too complex for new users.

Ideally we would have something like this:

But you can build the second, simplified experience on top of the first structure. The reverse is not true.

In any case thank you very much for your input @andyDoucette I agree with your concerns.

All the same, the protocol will be built incrementally. The first releases will probably only have 1 or 2 options. Additional exchange protocols, etc, will be added over time and responding to demand

[pedromvpg]

A stepped approach attempting to show how simple the process is if done in small increments.
Minimal amount of options per screen and very clearly differentiated text with short instructions.

https://xd.adobe.com/view/1e1f3215-e5e0-4f0a-9e53-fde53a4c1c4e-4b4c/screen/41499a4d-75c5-478e-a893-78e768815b79

[chimp1984]

I think the terminology used in Bisq1 with using BUY/SELL Bitcoin for both fiat and altcoin is a conceptual mistake as marekt prices are defined by the base currency/quote currency model (left is the base currency, right the quote curreny, the price/quote is the amount of quote currency for 1 unit of the base currency). This led to the confusion users reported many times. For Fiat it is correct in Bisq 1 but for altcoins we have the "BUY Bitcoin" in the menu but intuitively users would think about "BUY XMR" or the like.
In your design proposal (what was for improving Bisq 1) it follows that incorrect mental model by using "Buy Bitcoin with".
I think to have first the market selection (BTC/USD, XMR/BTC,...) and then the direction selection (BUY/SELL) makes it much more clear. Those 2 first decisions could probably be switched as well, but most exchanges follow that flow as well to define first the market. The direction depends on the market (BUY for fiat means by BTC, buy for altcoin means buy altcoin).

Bisq 2 requires additionally a selection for the protocol. It could be done via the menu as long as the number of the supported protocols is small, but at some point it might be better to have a dedicated screen for it which could help to give some context information about the different protocols (e.g. compare different properties like security, costs, convenience).
I think the selection of the protocol is probably best done after the currency selection or as first step. It will restrict follow up selections (e.g. atomic cross chain swap will only support XMR/BTC so no need to add a currency selection, others will only work with certain settlement methods (e.g. Bisq Multisig requires mainnet BTC, so no need to show BTC-over-LN or BTC-over-Liquid,...)

[flix1]

By not doing the research in the name of "future flexibility", we're really just pushing work on thousands of users that we should be doing ourselves. We should map out the best path or three through all of these parameters and just implement that

I agree that we should do that @andyDoucette . We can map out the best path for each market and make it the default option. We can even hide the other choices behind an "advanced options" icon so that newbies don't even see it.

But we should not close the door to those options or to adding new ones in the future. That is a big reason for the current modular architecture - Bisq1 was built differently and closed the door on many innovations that came out afterwards and are highly demanded (eg: lightning network, XMR atomic swaps, many payment methods, altcoins, etc..).

Bisq1 also changed protocols more than once. The last one was from 2-of-3 multisig (arbitrators) to 2-of-2 multisig (DAO). The change broke backwards compatibility and forced all users onto a single path... with the modular architecture we could have just added the new protocol as a choice and users could have transitioned voluntarily and gradually.

The pareto principle has been validated in my life time and time again.

Yes, but if you check out the history of P2P exchanges like Localbitcoins, Paxful, Hodlhodl you will discover that the pareto 80% solution that is most used now is not the same one as was used on launch or in the first year. It evolved with tech. It's also not the same for every market. What 80% of US users need is not what 80% of Nigerians want. A one size-fits-all solution, while optimizing for UX, will never work for 80+ markets.

So again, I agree that when building Bisq2 we should make choices for users, especially as to which options are added first. But without losing the flexibility to add new options in the future. Future flexibility will be extremely important if we want Bisq2 to succeed in reaching China, Nigeria, Russia, Argentina, Mexico, India... and many other markets where Bisq1 has totally failed to take off.

Or regarding a market which currently is almost 80% of Bisq volume: XMR/BTC. Haveno would not even exist if Bisq1 had been more flexible. If the XMR users and devs that are working on it could have just built an additional Bisq module, they would have never undertaken the huge task of building an alternative project from the ground up at massive cost.

[flix1]

Let me try to illustrate the importance of flexibility with 2 examples:

1. Lightning Network smart contracts - these are being built and researched now. They might not be fully functional until 1 or 2 years from now... but they could become the standard for P2P BTC/fiat exchange in 2 years.

2. Atomic cross chain swaps - some exist now, but most are experimental. Many more are still in the research stage.

If we make a choice now and exclude these options forever, Bisq2 will be locked out of the best tech for P2P exchange. We might end up having to start again with Bisq3 or, more likely, Bisq will just fade away into irrelevance as dev and user interest moves on to other projects.

However if Bisq2 is a flexible platform - any dev that wants to try out one of these new techs will save a lot of time by just working on a Bisq module for that. Instead of having to spend years building the entire platform, they can plug into the Bisq2 platform, liquidity and community.