Allow direct communication between traders

[ManfredKarrer]

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

Part of the new trade protocol proposal is to enable communication between the traders.
We should add that feature even before the new trade protocol is in place to help reduce number of dispute cases as most issues could be resolved by the traders themself.
The chat is the same like in the arbitration. It is mainly UI work to enable that after the trade has started (deposit tx is created). We need to set clear rules to avoid attempts of social engineering scams. Any such attempt would lead to a dispute and the one who started it would lose his deposit.

[clearwater-trust]

Providing the traders a way to communicate is a good idea. I think this will decrease disputes. It may be effective to include with the comms a way for the traders to CANCEL the trade if they both agree. That way, their trade can be completed without an arbitrator.

[ghost]

There was a proposal (or an issue) about only allowing usage of a limited pack of predefined messages between the traders.
This would be maybe easier to implement, and also make social engineering impossible.
I imagine that the scenarios leading to dispute are not hundreds and can be contained in a limited possibilities tree.
Also that could provide Bisq automatic and direct information on the most used branches, helping to improve the software without questioning the users.

[mpolavieja]

A trade communication system could be very useful to fight bank-account scammers. A pre-trade step would be needed so the BTC seller can somehow verify buyer´s bank account data before he reveals his own bank account details.

[meapistol]

Checking the validity of Bisq-owners ID or passport can often be done via websites: https://www.consilium.europa.eu/prado/en/check-document-numbers.html

A scammer would then have to know the account-holders Passport/ID-number which would deter most scammers. In suspect cases the seller could ask for an ID. Not sure how difficult this is to implement and for which countries these databases exist. The bottom link in the web-site gives a list of links for checking.

[m52go]

For the record, if (for whatever reason) implementing chat for traders becomes an issue, there's an interesting project called Briar which does peer-to-peer messaging over Tor. Conceptually they seem quite similar to Bisq.

With desktop apps, and proper auditing from our end to make sure everything is as advertised, their software may be able to provide the functionality we need.

At the moment they only have an Android app, so we would need more cross-platform options to actually use it in conjunction with Bisq. I was in touch with their founder recently to see where they are on desktop software, and it seems they're short on resources to release them until Fall of this year at the earliest.

But their core software is built in Java, and the founder was really happy when I told him about NetLayer, which apparently is a fork of a fork of Briar's original Tor plugin from years ago (small world!).

Anyway, point here is that there's another project out there working on something very similar, and people should be aware of it, even if we don't directly collaborate with them or use their software 👍

[m52go]

I have up-voted this proposal for the reason originally stated, quicker dispute of small issues, but also for reasons stated in #93 (chat as a component of measures against scammers, as Manuel mentioned above).

For the latter reason, the sooner we can get this implemented, the better, I think.

[kopite77]

The one possible issue I see with a chat is if someone purposely or even completely by stupid accident mentions that the trade is because they need crypto to fund some illicit purpose, that could put the other party at risk especially if they have traded via some fiat gateway and leaked information that way. There have been stories where people have gotten in trouble trading on localbitcoins because this happened. So I like the idea from @HarryMacfinned from earlier to have a limited pack of predefined messages between the traders.

[mpolavieja]

The idea of having predefined messages is very interesting. However I think we should be practical and just copy the same chat system we already have with arbitrators for direct communication between traders and see how it goes. Limiting it to predefined messages could be implemented later.

@flix1, could you please expand here on your concerns about implementing the chat you mentioned on #93?

[flix1]

could you please expand here on your concerns about implementing the chat you mentioned on #93?

Actually it was an example, not an objection.

For example for #90 you can go to a lot of trouble to integrate direct chat... or just include a field for an e-mail address in the contract...

In this case since the chat mechanism is already built for arbitration, I don't have any problems with re-using it. However if we had to choose between building it from zero... or just adding a simple text field to include an e-mail address... well it's clear which solution is simpler.

In fact if you have ever used Revolut to trade on Bisq, when it was first included it allowed the use of an e-mail address and users often communicated directly. Now that Revolut works only with a phone number... users still whatsapp counterparties when there are any delays. So direct communication already exists in practice.

Which brings me back to my point regarding security and reputation features in #93.

Many of these mechanisms could even be built on top of Bisq instead of in Bisq.

[mpolavieja]

Which brings me back to my point regarding security and reputation features in #93.

Many of these mechanisms could even be built on top of Bisq instead of in Bisq.

Yes. This is basically the reason behind of strongly suggesting to enable direct communication in #93. To allow traders to privately decide by themselves what to do. I am sure enabling this has its risks (social engineering, etc), but at the same time it would provide a lot of information on what path to take on future developments.

Moreover, it would be the only meaningful protection we have thought so far against scammers using stolen or bought IDs and money laundereres or any other undesirable type of users.

[m52go]

My issue with using external channels of communication is that almost all of them store metadata (at best) and full message contents (at worst), negating many of the privacy measures in Bisq. I don't think it makes sense.

The only suitable tool I'm aware of that might work is Signal, but then you have to reveal your phone number to each trader.

Built-in chat gets around these issues.

But if building chat into the software turns out to be more work than expected, I do think exploring other options is prudent. That's why I recommended checking out Briar above.

[flix1]

But if building chat into the software turns out to be more work than expected, I do think exploring other options is prudent. That's why I recommended checking out Briar above.

Chat is already built (currently used for arbitration). So it is definitely better to use it.

[bitcoinuser]

Hi,

I don't know how the trader chat is being implemented, but I really wouldn't like to receive any kind of messages from people I'm trading. I think should have an option, when creating an offer, to allow or not have chat with the trader. I think this option could be optional changed from not allow to allow, after the offer is accepted, but not the other way around.

[bitcoinuser]

There was a proposal (or an issue) about only allowing usage of a limited pack of predefined messages between the traders.

I like this idea too.

[y3v63n]

I like the idea as sometimes with Altcoin Instant option, it takes more than one hour to complete a trade so it would be nice to be able to let the other trader know that you started the transaction so that they don't open a dispute.

[chimp1984]

Implemented with bisq-network/bisq#3165.
Can be closed.

[chimp1984]

@mpolavieja Can you close that as it is implemented in v1.1.6.