As a user, I can generate a shortcode to share the data needed to do a SWT-transfer from another Swarm City client to me.

kikipluche commented 6 years ago

Abstract:

In order to do a token transfer in Swarm City on Rinkeby, the sender needs the publicKey, 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 ethereum network
to make doing a transaction in Swarm City fool-proof
to not bother users with blockchain-jargon (public keys etc.)

How it works:

When the user taps "shortcode", an API call is made. This API call expects a publicKey, the avatar image data (base64) and the username. Then the API generates a shortCode, and checks if it already exists. If so, it generates a new shortCode.

The shortCode is stored in LevelDB, together with the publicKey, the username and avatar. The shortCode is returned to the client. The shortCode can then be shared with the user that wants to send SWT.

When the user (while viewing the shortCode) taps the blue X-mark, thus closing the shortCode-view, the client unsubscribes and the shortCode + publicKey, username and avatar are removed from LevelDB.

Jobs:

shortCodeCleaner

Clears the expired shortCodes and their data from the LevelDB after the validity period has expired.

API:

provides topic createShortCode to subscribe to. The client should provide this data:

{
  publicKey: <String>,      // user publickey
  username: <String>,    // username
  avatar: <BASE64>,      // Base 64 hash of avatar image.
}

The response of the registration is a subscriptionId and the shortCode itself, and the validity.
```
{
shortCode: <String>, // 5 digits
validity: <Number>, // validity in ms
}
```
when the validity expires - you automatically are unsubscribed from the topic, and the data is removed on the worker-node.
Allows client to unsubscribe from the topic.

What it looks like in front end:

route: /my-wallet

In the wallet-view, we see the 'shortcode'-button in the middle of the page, below the 'send SWT'-button.

When the user taps the 'shortcode'-button, the middle part of the page changes: the two buttons disappear, and the shortCode-view appears.

The shortCode-view contains:

copy: 'Your temporary shortcode'
the shortCode
a blue X-mark that serves as a close-button

The shortCode is now ready to be shared with the sender by the receiver.

As soon as the shortCode is created by the API, it is valid for 120 seconds. If a user stays on the page for this long, the last 30 seconds, a countdown (copy: 'This shortcode expires in x seconds') + progressbar (blue) will appear, announcing when the shortCode expires. The progress bar starts full, empties down starting from the right

When the countdown ends, the shortCode expires, and the shortCode-view disappears, making the two buttons appear again in the middle of the page.

Tapping the blue X-mark (close-button) unsubscribes from the topic, and makes the shortCode-view disappear. The two buttons appear again in the middle of the page.

Documentation / references

N/a

bkawk commented 6 years ago

A base 64 image of the avatar, not an ifs hash, there is no need for extra round trips and changes to the infrastructure at this juncture.

'pubkey' is to be renamed to 'publicKey'

'shortcode' is to be renamed to shortCode

xardass commented 6 years ago

Question, in what direction does the progressbar increase/decrease? Does blue filling increase or decrease?

Update: It starts filled blue, decreases to the left (according to faffy)

kikipluche commented 6 years ago

Changes in the epic:

progress bar starts full, empties down starting from the right
Front end will receive base64
Renaming shortCode, publicKey

kikipluche commented 6 years ago

19/3: epic is clear for devteam and ready for execution

xardass commented 6 years ago

Can publicKey be renamed to address on the API side? This is how it's currently written, and it makes more sense on a technical level. There needs to be no rewrite on the API here if we change the wording in the epic from publicKey to address.

xardass commented 6 years ago

I see why there is confusion, in epic #6 (for channel readShortCode) the payload definitions don't match with this one. I propose we follow how it's defined in epic #6, as this is how it has been implemented in the API:

{
    response: 200, 
    data: {
      address: "0xabc...123",
      userName: "swarm citizen",
      avatar: <String> // base64
     }
}

xardass commented 6 years ago

I wrote the code according to my comments above.

swarmcity / SwarmCityConcept