search

bisq-network / proposals

@bisq-network improvement proposals
https://bisq.wiki/Proposals
43 stars 16 forks source link

Remove attachment feature from dispute chat #336

Closed chimp1984 closed 3 years ago

chimp1984 commented 3 years ago

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

The attachments are likely a main factor for large mailbox messages. Currently it is about 4-5 MB of data for new users to download at initial data request. We optimized that to keep those data locally so repeated start ups will only request the missing data. But 5 MB is already pretty heavy for slow connections and increase the risk for connection timeouts. So I would suggest to remove the attachment feature in the UI. It can be done as a pure UI change so its very simple and will serve its purpose. To remove it from the data structure would have more complextity with backward compatibility. Receiving attachments should be still supported, so in case old clients who still can send them can expect that the receiver will see them.

Users who need to send a screenshot or the like should use an upload service for encrypted data. We can add a recommendation for a privacy respecting one (should be tor browser compatible). Its also important that mediators/arbitrators will not open an arbitrary link as it might lead to a malicious webpage as well.

Later once the feature can be expected to have reached a super majority we can enforce that min. version and not allow mailbox messages largers as expected. The normal data in mailbox messages is about the data used for trade messages so we can derived from that a safe limit and drop messages larger than that.

If that proposal gets support, is there any dev who want to implement that? As said its UI layer only work.

chimp1984 commented 3 years ago

Sorry I have not though enough about it before publishing ;-). I think the added security risks and complexity for the user to encrypt the screenshot and for the mediator to decrypt it is not worth it. We should have separated the attachment from the message so we could treat those lower prio data differently. But for now I think its better to keep it as it is. Mediators and arbitrators should avoid to send attachements as its more likely that the user is offline than it is that those agents are offline, at least they should be online each day so the mailbox messages should get removed rather quickly as well.

sqrrm commented 3 years ago

I agree that the attachment feature is problematic. Perhaps it would be better to only allow sending them as direct messages while both peers are online and fail rather than storing as mailboxmessage if the peer is offline. Message could be sent later when the peer comes online and UI could suggest to stay online for proper message delivery. Not the greatest UX but might be a way forward.

chimp1984 commented 3 years ago

Yes might be a compromise. For misq we will separate all mailbox messages by the content type, so it is easier to apply different strategies.

pazza83 commented 3 years ago

I agree that the attachment feature is problematic. Perhaps it would be better to only allow sending them as direct messages while both peers are online and fail rather than storing as mailboxmessage if the peer is offline. Message could be sent later when the peer comes online and UI could suggest to stay online for proper message delivery. Not the greatest UX but might be a way forward.

I think a requirement for user and mediator to be online at the same time would result in more problems and delay mediation / arbitration.

I think the better solution would be to utilize a file upload service as @chimp1984 mentioned above.