[bisq-network/bisq] Bisq-2 UX challenges (Discussion #5959)

[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.










-- 
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/bisq/discussions/5959#discussioncomment-2039463
You are receiving this because you are subscribed to this thread.

Message ID: <bisq-network/bisq/repo-discussions/5959/comments/2039463 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20220124/caecdee1/attachment-0001.htm>