particl / particl-desktop

The GUI application for Particl Markeplace and PART coin wallet. A decentralized peer to peer marketplace –free, secure, private, untraceable.
https://particl.io
GNU General Public License v2.0
175 stars 89 forks source link

Improvement to Address Book Labeling of Escrow Deals #1239

Open cryptoguard opened 5 years ago

cryptoguard commented 5 years ago

Currently, each marketplace transaction is associated to an escrow smart-contract and added to the user's address book. The labeling is actually terrible from a UI/UX point-of-view because it doesn't give a clue what that escrow was actually for (that is, probably unless you are an advanced user).

Here's the current labeling:

screen shot 2018-11-09 at 1 37 47 pm

I would suggest we change the label from the ID of the escrow smart-contract to the name of the purchased product or service. For example, instead of showing the label screenshot above, it could display something like "Samsung TV Escrow Contract" where "Samsung TV" is the name of the listing associated with the escrow smart-contract.

AllienWorks commented 5 years ago

I already mentioned this, we have a task logged for this. I suggested to completely hide all these addresses in Address book.

IMO doesn't make sense to automatically save these to Address Book, as it should be a place only for user to save addresses. These automatically saved escrow-related addresses doesn't make much sense.

Another alternative is to hide them by default, but offer displaying them via filter:

Filter by:
- Public
- Private
- Market-related
AllienWorks commented 5 years ago

Duplicate of https://github.com/particl/particl-desktop/issues/1057

zaSmilingIdiot commented 5 years ago

I'm not convinced yet that we should be doing this. On the surface it seems plausible and valid, but consider what happens in the future when we have possibly multiple dApps included on the platform.

If we consider the WALLET as a separate app from the MARKET, then we technically need to either provide a means for the wallet to query a list of addresses from each included app for labelling purposes, or the wallet needs to provide a means for each app to change labels of the addresses contained within it. I personally don't like either options from a secure point of view if this means providing bulk address updates (or exposing the entire address book to any specific dApp). Except if the latter option was an SDK/API call that the dApp can use to save user labelled addresses from within the dApp. It could then also potentially be limited to query its own addresses from the address book.

I do agree that we could provide decent filtering over the addresses in the wallet address book. And I don't see the point in having all of the addresses listed either - this currently appears to me to be a different view over the History table data. Perhaps this should only contain addresses that the user has chosen to specifically save? Like a phone book :) In this scenario, the user could save entries into this address book from the history page (note that this is specifically from the wallet "dApp"). As mentioned above, we could then possibly include the option for the future SDK to provide a means for a dApp to access or save an address with a user provided label.

AllienWorks commented 5 years ago

Perhaps this should only contain addresses that the user has chosen to specifically save? Like a phone book :)

Exactly my point of view. Address book is a collection of user-saved addresses. Nothing else.

I understand that other dApps will need to create addresses as well etc., but does the user really needs to see them? Shouldn't this all happen automatically on the background? What I see as the best way to do this is:

  1. hide all but user-saved addresses in Address book by default
  2. offer filtering only specific dApp-related addresses via Filter (e.g. "Show only X addresses"; replace X with dApp name)

Regarding address labels, it makes sense to me that each dApp should be responsible for some meaningful labels - current weird escrow_asdkfnklgnsmdfl addresses are really nonsense indeed; would be way better if it included Listing's name in there as @cryptoguard suggested.

But then again, I don't understand fully all the technicalities with SDK & other dApps. I'm just sharing my view from users'/UX perspective.