In order to send SWT in Swarm City on Rinkeby, I need the public key, the username and the avatar of the receiver. For this, we use the concept of shortcode. We use this concept for 3 reasons:
to make sure all transactions happen securely in the same network
to make doing a transaction in Swarm City fool-proof
to not bother users with blockchain-jargon (public keys etc.)
How it works:
The receiver shares his shortcode with the sender. The sender taps the 'send-SWT'-button and enters an amount and a shortcode of the receiver in the first view of the send-flow. When submitting, an API call is made. The shortcode is sent to the API, the API returns the public key, the username and ipfs hash of the avatar.
The username is displayed, along with the avatar image that's resolved over https://ipfs.swarm.city/ipfs/[ipfshash].
The sender confirms the identity of the receiver. The sender then confirms the total transaction (= amount and receiver). When confirming, a transaction is created on the sender's client. The sender signs this transaction. The signed transaction is sent to the API service "sendSignedTransaction".
A green progress screen is shown. The user can continue as soon as the transactionHash is received.
This screen has a timeout of 30 seconds - meaning if a transactionHash is not received in 30 seconds, the green screen will show an error and the user can return to the wallet view.
When successful, the journey ends at the wallet-view, where a new historyItem is seen in the transactionHistoryList.
Jobs:
N/a
API:
readShortCode
A function readShortCode that returns the user data for the given shortcode.
emit : readShortCodedata:
{
shortcode: <String> // shortcode - like "12345"
}
This function returns the payload that was attached to this shortcode - if it exists and didn't yet expire. the return code for the data will be 200.
In the wallet-view, we see the 'send SWT'-button in the middle of the page, above the 'shortcode'-button.
When the user taps the 'send SWT'-button, the middle part of the page changes: the two buttons disappear, and first view of the send-flow appears.
First view:
The first view of the send-flow contains:
inputfield (label: 'Amount', type: 'Number') for the amount you want to send
inputfield (label: 'Receiver’s shortcode', type: 'Number') for the shortcode of the receiver
x-mark (cancel-button)
big white button with blue next-icon (confirm-button)
When the x-mark is tapped, the flow is cancelled: this makes the default view appear again in the middle of the page (= 2 buttons).
The big white button is disabled until the values of both inputfields are valid:
The amount is a Numeric value with decimals
The amount is less than the total balance
The amount is more than 0 SWT
The shortcode is a Numeric 5 digit value.
When the big white button is enabled, the user can tap to submit the values and go to the second view.
Second view:
The second view of the send-flow contains:
copy: 'Looking for receiver…'
blue x-mark (cancel-button)
There is a timeout of 30 seconds on this view - when there's no response, the view changes to third view - errorstate.
When the receiver is found, the view changes to third view - normalstate.
When the user taps the blue X-mark (cancel-button), the whole process is aborted.
Third view - normalstate:
The third view of the send-flow contains:
copy: 'Receiver found!'
avatar of the receiver
userName of the receiver
the publicKey of the receiver
blue x-mark (cancel-button)
big white button with next-icon (confirm-button)
When the user taps the big white button with next-icon, he confirms the receiver, and the page changes to the confirm-sending-page.
When the user taps the blue X-mark (cancel-button), the whole process is aborted.
Third view - errorstate:
The third view - errorstate of the send-flow contains:
copy: 'No receiver found.'
blue x-mark (cancel-button)
When the user taps the blue X-mark (cancel-button), the whole process is aborted.
confirm-sending-page
The confirm-sending-page contains:
copy: 'You’re about to send (amount) SWT to (receiver userName)'
copy: 'This can't be undone.'
black x-mark (cancel-button)
big white button with blue V-mark (confirm-button)
When the user taps the black X-mark (cancel-button), the whole process is aborted.
When the user taps the big white button with blue V-mark, he confirms the transaction, triggering the password-unlock for signing this transaction.
confirm-sending-page (with password-unlock)
The password-unlock is an overlay on the page it is on. It contains:
avatar
inputfield (label: 'password?')
black x-mark (cancel-button)
big white button with blue V-mark (confirm-button)
When the user taps the black X-mark (cancel-button), the password-unlock dissappears, showing the page below as she was.
When the user taps the big white button with blue V-mark, he signs the transaction. The signed transaction is sent to the API. The page changes to progress-page.
transaction-progressing-page
The transaction-processing-page contains:
copy: 'Your transaction is being processed.'
copy: 'Received TXhash'
white dots / white V-mark / black XmarkWhen the txhash hasn't arrived yet, we see the 3 white dots (animating). When the transactionHash hàs arrived, the dots turn into the white V-mark. There is a timeout of 30 seconds on this page. When the timout ends and no transactionHash was received, the 3 white dots turn into the black Xmark and the errormessage is shown, as seen on transaction-progressing-page (error).
a big white button with a black next-icon
When entering the page, the big white button with black next-icon is disabled. When the transactionHash is received (making the white dots turn into the white V), the button is enabled.
When the user taps this button, the page changes back to wallet-view, ending the send-flow (resulting in a new historyItem).
transaction-progressing-page (error)
The transaction-progressing-page (error) contains:
copy: 'Your transaction is being processed.'
copy: 'Received TXhash'
black Xmarksee explanation above
a black line
copy 'Something went wrong, no TXhash was received.'
a big white button with a black prev-icon
When in this view, the process of sending has failed (because no transactionHash was received).
Tapping the big white button with black prev-icon, will lead the user back to the wallet-view.
Abstract:
In order to send SWT in Swarm City on Rinkeby, I need the public key, the username and the avatar of the receiver. For this, we use the concept of shortcode. We use this concept for 3 reasons:
How it works:
The receiver shares his shortcode with the sender. The sender taps the 'send-SWT'-button and enters an amount and a shortcode of the receiver in the first view of the send-flow. When submitting, an API call is made. The shortcode is sent to the API, the API returns the public key, the username and ipfs hash of the avatar.
The username is displayed, along with the avatar image that's resolved over https://ipfs.swarm.city/ipfs/[ipfshash]. The sender confirms the identity of the receiver. The sender then confirms the total transaction (= amount and receiver). When confirming, a transaction is created on the sender's client. The sender signs this transaction. The signed transaction is sent to the API service "sendSignedTransaction".
A green progress screen is shown. The user can continue as soon as the transactionHash is received. This screen has a timeout of 30 seconds - meaning if a transactionHash is not received in 30 seconds, the green screen will show an error and the user can return to the wallet view.
When successful, the journey ends at the wallet-view, where a new historyItem is seen in the transactionHistoryList.
Jobs:
N/a
API:
readShortCode
A function
readShortCodethat returns the user data for the given shortcode.emit : readShortCode data:
This function returns the payload that was attached to this shortcode - if it exists and didn't yet expire. the return code for the data will be 200.
response on success:
response on failure:
If the shortcode is not a valid shortcode, the API will return a 400 response code. The user data is not returned.
sendSignedTransaction
A socket handler that accepts a signed transaction and puts it in the transaction pool.
emit : sendSignedTransaction data:
response on success:
response on server error:
API Documentation
Reference of server code : https://github.com/swarmcity/SwarmCityAPI/blob/master/src/functions/SendRawTxFunction.js
Example usage on client: https://github.com/swarmcity/SwarmCityAPI/blob/master/test/testSendRawTx.js#L34-L41
Socket cheatsheet https://socket.io/docs/emit-cheatsheet/
What it looks like in front end:
route: /my-wallet
In the wallet-view, we see the 'send SWT'-button in the middle of the page, above the 'shortcode'-button.
When the user taps the 'send SWT'-button, the middle part of the page changes: the two buttons disappear, and first view of the send-flow appears.
First view:
The first view of the send-flow contains:
When the x-mark is tapped, the flow is cancelled: this makes the default view appear again in the middle of the page (= 2 buttons).
The big white button is disabled until the values of both inputfields are valid:
When the big white button is enabled, the user can tap to submit the values and go to the second view.
Second view:
The second view of the send-flow contains:
There is a timeout of 30 seconds on this view - when there's no response, the view changes to third view - errorstate.
When the receiver is found, the view changes to third view - normalstate.
When the user taps the blue X-mark (cancel-button), the whole process is aborted.
Third view - normalstate:
The third view of the send-flow contains:
When the user taps the big white button with next-icon, he confirms the receiver, and the page changes to the confirm-sending-page.
When the user taps the blue X-mark (cancel-button), the whole process is aborted.
Third view - errorstate:
The third view - errorstate of the send-flow contains:
When the user taps the blue X-mark (cancel-button), the whole process is aborted.
confirm-sending-page
The confirm-sending-page contains:
When the user taps the black X-mark (cancel-button), the whole process is aborted.
When the user taps the big white button with blue V-mark, he confirms the transaction, triggering the password-unlock for signing this transaction.
confirm-sending-page (with password-unlock)
The password-unlock is an overlay on the page it is on. It contains:
When the user taps the black X-mark (cancel-button), the password-unlock dissappears, showing the page below as she was.
When the user taps the big white button with blue V-mark, he signs the transaction. The signed transaction is sent to the API. The page changes to progress-page.
transaction-progressing-page
The transaction-processing-page contains:
When entering the page, the big white button with black next-icon is disabled. When the transactionHash is received (making the white dots turn into the white V), the button is enabled.
When the user taps this button, the page changes back to wallet-view, ending the send-flow (resulting in a new historyItem).
transaction-progressing-page (error)
The transaction-progressing-page (error) contains:
When in this view, the process of sending has failed (because no transactionHash was received). Tapping the big white button with black prev-icon, will lead the user back to the wallet-view.
Documentation / references
N/a
♡