Symbol Wallet Features Requests: Search & Sort + Receipts

Ideas
#1

Symbol Wallet Features Requests:

I have two feature requests that are related, and fall under a general umbrella of “Accounting”

In database systems we have come to take for granted complex accounting and data management tools.

Anytime we shop online: we search, sort by attributes, exclude data, and otherwise make extensive use of defined parameters to display the data we want. - All from user friendly GUIs.

In the future, data management software with such capabilities will become a standard in distributed ledgers as well. Today we just have the basics, we call them “wallets”

It would be sensible to consider this and take at least small steps, and thus:

Today I want to focus on two specific accounting features that will empower endless possibilities.

Transaction Search & Sort

This is quite self explanatory. In accounting, browsing is a nightmare.

No individual or business wants to scroll through hundreds of transaction records to find specific ones. Even the average crypto user doesn’t like this.

Let’s make it easy to search and sort transaction history with defined parameters.

Here are some examples:

  • Display only transactions with XYM amounts between 1,000 and 1,500
  • Display only transactions between dates Dec 18th, 2020, and Dec 20th, 2020
  • Exclude all transactions with XYZ mosaic amounts equal to or less than 100
  • Display only transactions made between Dec 18th and 20th, that contain 100 or more ABC mosaic, and have a transaction message attached.

Now I will segway into use cases built upon this, and introduce the second Symbol wallet feature request:
I had difficulty settling on a one word definition, as the capabilities far exceed our traditional understanding.

Receipts

When we make purchases at any store, we take one thing for granted: Receipts.

In a data flow diagram, receipts are a secondary transaction based on a prior transaction. IF you give money, you receive receipt.

IF purchase data is entered into the database, a copy of the corresponding data is provided to the customer as a proof of purchase. AKA: Receipt.

Beyond proof of purchase, receipts can also bundle additional data:

  • Brick and mortar stores often print coupons on receipts.
  • Software purchases include license codes with receipts.
  • Airline travel purchases include itineraries with receipts.
  • Lottery purchases include official lottery codes with receipts.
  • Crowd funding participants receive receipts qualifying them for specific products.

My proposal is to build into the Official Symbol wallet a user friendly method to generate transactions & aggregate transactions based on prior transactions.

Conclusion:

Search and sort functions allow one to quickly identify transactions, and make the necessary corresponding transactions.

Beyond what I have already mentioned, these capabilities allow:

  • Symbol wallet to empower ICO & STO issuance, with variables.
  • E-commerce integration
  • Crowdfunding of unique items.
  • Issuance of verifiable signed receipts
  • Refunds
  • Much much more.
7 Likes
#2

This needs to be supported in the API server but it will in theory be possible in the future with enough community support. So it is really more of an API server request than a wallet server request.

1 Like
#3

Can you the exact flow of one of these examples?

#4

The Symbol mobile wallet has a sort by sent or received txs, and has a search function.

1 Like
#5

As for traditional receipts, a really big problem is how to connect blockchain payments into the existing accounting/inventory/supply chain/ERP software suite. Most companies have their traditional point-of-sale system. That might be something as simple as a Square, but could be a whole cash register. Often times as things are scanned, the inventory system is updated. It is really hard plugging into these existing point-of-sale systems. This has been a big problem for all of blockchain, not just NEM. I was working with a project called RapidZ that was trying to solve this friction point in Taiwan. Need to check into see how they are doing.

2 Likes
#6

Example: In Paypal transaction history. I can click the transaction, and pick “refund” - I can also select multiple payments, and refund full amount, or other set amount.

In Symbol wallet, allow similar capability via a feature to auto insert the respective Symbol addresses, as selected from transaction history, into a new outgoing transaction / aggregated transaction.

#7

Maybe receipts isn’t the best word, I’m not speaking of traditional POS systems nor paper receipts. Wouldn’t expect integration for that.

By receipts I mean any sort of secondary transaction based on a prior transaction.

You send me $XYM, I send you XYZ mosaic.
Or you send me XYZ, I send a message “Thank you”
Or 1,000 people send me XYZ mosaic, and I send a “Thank you” to all.

Even the most rudimentary improvements on this area would help increase UX and functionality for average person.
Anyone that actually uses crypto wallets much knows it’s not very fun.

There’s a mess of transaction history.
Always copy+pasting addresses, hoping you really did get all the characters selected.
Double checking. Triple checking.
Sending payments, and wondering “Do they know I paid them?”

I understand the argument “well if a business needs that, it can be built on Symbol” - but I would say that we should do what we can to make the default Symbol wallet experience as user friendly as possible for a wide range of situations.

We can build the best blockchain, but nobody sees it. Wallet is first impression.
No matter how advanced a vehicle’s engine is, I wouldn’t use it as a daily driver without power steering.

#8

receipt might be a misleading word due to the feature and the specificity of the word

just to make sure I understand what you are saying, are you asking for a (client) feature that allows the user to perform actions on transactions (does not matter if sent or received), and depending on the transaction the user gets a different set of available features?

for example, for sent transfer transactions you could have the option “repeat”, “repeat to different address” (copy), or “ask for refund”

and for received transactions you could have “send acknowledgement”, “return”, “forward”

basically a way in which the application automatically fills the transaction “form” (or even directly announces the new transaction) based on a previous transaction - all of this could be done completely from the client side, though if more advanced features were sought, this would require the client app to understand/design a format/code to be added to the transaction message (still client side, but requires more thinking and probably not a very resilient design)

1 Like
#9

Yes! Defined options would actually make it a little more advanced that my original thought. My thought was more along the lines of this process:

User can do the following:

  1. Open wallet, log in.
  2. Use search, attributes, or other methods to refine the displayed transaction history.
  3. Select one, or multiple transactions from transaction history.
  4. Pick “Generate new” - filling the form for a new transaction.
  5. Enter details: Message, XYM amount, gas fee, etc
  6. Click “Send” - Broadcasting transaction

Tie this into Address Book, where Symbol addresses can be labeled, to improve UX even further.

#10

@leoinker with regards to the client-side UI/UX enhancements to empower actions on transactions i cannot give you any input

relating to the filtering options, we’ve added some missing options we thought were relevant that you were commenting to the REST server that should allow clients to make similar queries to what you pointed out - the only thing we left out is to filter by whether a message exists or not because we thought it was too specific, but if you think it is something that definitely should be there, please open an issue and the team will consider it, or other interested people may chip in

note that we have added the options to filter by range height, not timestamp, this is on the hands of the clients or SDK’s to offer, after all it is a conversion between timestamp and height that can, and i believe should, happen client side, since the blockchain works with heights after all

2 Likes