MiniServer: basic mini-wallet operator functionality

[johnwhitton]

Overview

Enable SMS controlled Mini-wallet operator functionality for pay and transfer triggered by SMS messages from the user.

See this Internal demo

Description

This enhancement enables mini-wallet functionality via the API's. Including operator functionality (pay and transfer) as well as end user functionality (deposit, withdraw, authorize). Users can trigger pay and transfer functionality by sending SMS messages to the operators twilio managed phone number.

Simple Process Flow

We will start with the native token flow and then add other tokens in a separate issue.

1. User Deposits funds into the miniWallet
2. User Approves Funds funds for a creator(developer) in the MiniWallet
3. User Receives a request for Payment for Funds to a creator.
4. User Pays the creator(developer)

Assumptions
a. All user interactions can (and probably will) also be implemented using
i. From Creator Apps integrating with the sms-wallet client approve screen as explained in the demo
ii. By additional client functionality for deposit, approve and payment (to be developed separately).

b. Request for Payment will handled separately.

Technical Description

The focus for this enhancement is triggering a payment by the user to the creator via SMS (item 4) above. Specifically creating the foundational building blocks which can then be further enhanced.

Technical Flow

1. User sends an sms to the operator phone number to trigger payment
2. Twilio server receives the message and triggers a call to the sms-wallet-server via webhook
3. The server validates the signature of the request is from twilio.
4. The server reads the payload to decide which action should be taken

Technical Components

Following is an overview of the technical components to be implemented

• min-wallet support: simple instantiation of AssetManager contract and helper functions for operators to interact with pay and transfer functionality
• Twilio Configuration: To receive SMS messages and forward them to the sms-wallet server
• Server API supporting messages forwarded from twilio
• Twilio Signature Authentication: to ensure that only trusted api calls from twilio are processed.
• Parsing Logic: To interpret the message and perform the appropriate operator actions.
• Localhost testing: We can test locally using the twilio cli to enable a proxy using ngrok.

Approach
We will start with a minimum viable product (MVP) to ensure the infrastructure is in place, parsing logic will be added later.
The mvp will upon receiving a message from a user the operator will pay an amount on their behalf to an approved recipient.

Go Live Checklist (for discussion)

Optional Enhancements

• NFT Minting Capabilities
• Transfer Functionality
• MiniWallet Page on https://demo.smswallet.xyz (preloads deposit, approve and withdraw)
• Additional (non-sms) API's for balance and payment receiving JSON
• Batch APIs allowing creators to request and transfer funds from multiple users
• Utility API's for getting Approval Amounts for Users and for Creators
• Creator CLI Used to generate URL's

Standalone Local Environment

• MiniWallet Contract priority tasks completed MiniWallet Smart Contracts Testing and Deployment #3
• MiniServer deployed integrating with Local Ganache Instance
• Twilio Accounts setup (user, creator)
• GCP DataStore Setup
• Test Suite covering all positive and negative use cases
• Docs Updated
  • Swagger Docs
  • API Client
  • Creator Tutorial on https://docs.smswallet.xyz
  • Creator Tutorial video internal example

Harmony Testnet Environment

Harmony Mainnet Environment

References

• API Documentation Postman (WIP)
• SMS controlled Mini-wallet
• Twilio Webhooks
• Twilio Markup Language: TwiML™ for Programmable SMS
• Programmable SMS Quickstart for Node.js
• Webhooks Security: Validating Signatures from Twilio
• Twilio Proxying to your localhost
• Twilio CLI proxy using ngrok

[polymorpher]

"AssetManager Administrative" components are not needed. One can simply do it in a console. Client API is not needed either. It will be entirely performed on the client side directly interfacing the blockchain.

Token tracking and NFT identity tokens seem to have higher value than the other proposed Future Enhancements

[johnwhitton]

Based on Feedback from @polymorpher we will focus on enabling operator mini-wallet functionality triggered by SMS messages from the user for the first phase. As such the original design above will be updated.

Here is a copy of the original design for posterity

Overview

Increase server functionality to support the SMS controlled Mini-wallet.

Description

This enhancement enables mini-wallet functionality via the API's. Including operator functionality (pay and transfer) as well as end user functionality (deposit, withdraw, authorize). Users can trigger pay and transfer functionality by sending SMS messages to the Operators Twilio managed phone number.

Technical Description

Following is an overview of the technical components to be implemented

Technical Components

• Server API supporting Twilio Webhooks
• Server API'S supporting AssetManager Operator Functions (pay and transfer)
• AssetManager Deploy Functionality as part of Server Deploy
• AssetManager Administrative Functions for Managing Operators
• AssetManager Administrative Scripts for Managing Limits and Pausing contracts
• Client API's for MiniWallet User Functionality (deposit, withdraw and authorize)
• Testnet Deploys of Sample Tokens (ERC20, ERC721, ERC1155) used for

Future Enhancements

Following are optional future enhancements that may be addressed under separate issues

• AssetManager Token Tracking of Approved Tokens
• ERC777 Support
• Gas Management Functionality
• NFT identity Tokens (ERC721, ERC1155)
• User minted Tokens

References

• API Documentation Postman (WIP)
• SMS controlled Mini-wallet

[johnwhitton]

Status Update: Have configured Twilio test account to send test messages to sms-server running on localhost

[johnwhitton]

Design Notes

• Can simplify server deployment to just support one network (not mulitple)
• Initial POC will take basic input from user (pay, to, amount) e.g. p 4158401410 10
• Initial POC will only support operator functions (i.e. pay and transfer) user functions such as looking up their balance can optionally be added later.
• Can default values such as recipient country code from user information
• May implement a queuing system where a request can be sent to the user for payment and they respond with approved. The queue would give context as to which payment the user was paying

[johnwhitton]

Updates

• Will work on this issue under Initial version of miniwallet server #7
• Have refactored so miniserver is now a standalone server
• Have included swagger UI as configurable

Have tested with the following flow
Note : User actions are currently created using the demo page with contract calls to AssetManager
Note: Creator actions are triggered by sms messages using the Twilio CLI
Note: All tests are currently local using a local ganache instance

1. User Deposit 10 ETH
2. User Approve 1 ETH for the creator
3. Creator Checks Balance: twilio api:core:messages:create --from "+14158401410" --to "+17372327333" --body "balance
4. Creator Requests Operator to Pay 1 ETH: twilio api:core:messages:create --from "+14158401410" --to "+17372327333" --body "pay"
5. User withdraws 1 ETH

[johnwhitton]

Internal Demo Video

[johnwhitton]

Have forked PR #7 in PR #8
Can either merge miniserver functionality first (#7) and progress smart contract enhancements after (#8) or ignore #7 and just merge #8.