As a Provider, I reply to a request to show my interest in fulfilling it.

[kikipluche]

Abstract:

In Swarm City, a deal is created when a Seeker and a Provider accept each other in a request made by the Seeker.

How it could work:

A User taps the hashtagItem to open the detail view.

In the detail view, the Provider can tap the reply button. The Provider can now enter a message for the Seeker.

When the Provider confirms, the unlock-password view is displayed. The Provider's public key has to be known by the Seeker, so the Provider must decrypt the wallet to reveal the public key.

When no user account is present on the device, the user is redirected to the create-account flow /new-here. After completing this flow, the user is returned to the item detail view.

After confirming the password on unlock-password, the reply is sent to the API, and the Provider's reply appears below the request on the item detail view.

How the API could work:

function replyRequest
*messaging

The API could keep a cache for every hashtag. The hashtagItem's key is the dealHash. The reply can be added to the array replies in the hashtagItem object.

After the update the API emits a hashtagItemChanged event.

---

What it looks like in front end:

Userflow: https://invis.io/ABGM89SX3V5#/293499476_-Hashtag--contractadress---dealhash-_REPLYING_I
( > in Invision, hold shift to see clickable areas)

---

route: /hashtag/[contractadress]/[dealhash]

On the detail-page of an hashtagItem, the user sees a big white button with blue reply-icon, unless:

• the user is the Seeker
• the user has already replied

When the button is tapped, the reply-area (where the replies were visible) changes to show:

• an input field, label copy: "Your reply"
• avatar
• copy "for (value) SWT."
• 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 reply process is aborted, returning the reply-area to its previous state of showing the current replies.

When the user taps the big white button with blue V-mark, he confirms his reply, triggering password-unlock.

After signing through the password-unlock, the underlying page (/hashtag/[contractadress]/[dealhash] ) becomes visible again, now showing the newly posted reply.

Before the client receives a response from the API, the opacity of the reply is 50%. After the client receives a response from the AP, the reply is shown in full opacity.

---

Desktop view:

---

Invisionlinks with login (for inspect mode!):
mobile: https://projects.invisionapp.com/d/main#/console/13838256/293499476/inspect
desktop: https://projects.invisionapp.com/d/main#/console/14147648/294446716/inspect

Documentation / references

EthCrypto : https://github.com/pubkey/eth-crypto

♡

[kikipluche]

@faffydee make extra screen 50 % opacity of the reply until there is a response from the API

[faffydee]

Done!

[matthewcarano]

@kikipluche @kingflurkel @faffydee can we amend this Epic a little bit? I'd like to change these things:

Under "How it could work" I propose changing "Provider" to "User".

I also propose removing this sentence:

"The item is added in the client's redux and is overwritten when confirmed on the blockchain, just like "pending" in transactionLog."

Because the blockchain isn't involved in this step. The API is.

Thank you all.

[matthewcarano]

@kikipluche @kingflurkel @faffydee I propose 2 other changes.

Under "What it looks like in front end" let's change:

"After signing throug password-unlock, the underlying page..."

to

"After signing through the password-unlock, the underlying page..."

and

"Before any reponds of the API was received, the opacity of the reply is 50%. When we do get a responds from the API that the reply is posted, then it is shown in full opacity."

to

"Before the client receives a response from the API, the opacity of the reply is 50%. After the client receives a response from the AP, the reply is shown in full opacity."

[kikipluche]

@matthewcarano made the changes.

[kikipluche]

@eduadiez @dapplion
This is how the front end is written, followed by what is expected from the API:

A Provider taps the hashtagItem to open the detail view.

In the detail view, the Provider can tap the reply button. The Provider can now enter a message for the Seeker.

When the Provider confirms, the unlock-password view is displayed. The Provider's public key has to be known by the Seeker, so the Provider must decrypt the wallet to reveal the public key.

When no user account is present on the device, the user is redirected to the create-account flow /new-here. After completing this flow, the user is returned to the item detail view.

After confirming the password on unlock-password, the reply is sent to the API, and the Provider's reply appears below the request on the item detail view.

Front End

channel: replyRequest

API

Service: replyRequest
Parameters:

• dealID
• hashtagAddress
• replyDescription
• avatarHash
• userName
• dealValue
• public key of replier, encrypted with seeker address

API adds dateTime / blocktime
API adds reputation number

LevelDb dealItem is updated, which triggers an hashtagItemChanged event.

Example JSON file params for replyRequest:

{    
            "itemHash": "0x06d0540d044ea8d6efd0a994c5235aebaa414607c632f6f0f1b5d6ea658a829a",
	    "hashtagAddress": "0xeba08e7a1d8145b25c78b473fbc35aa24973d908",
            "replier": {
                "username": "Harry Humble",
                "avatarHash": "QmQTTfDbE5wM1dvucWpaEmERXC75RUDhppoZLcBjNWLQ6D",
                "address": "0x369D787F3EcF4a0e57cDfCFB2Db92134e1982e09",
	        "publicKey": "full public key",
            },
            "description": "I can help you with that",
        }
}
      

The API will add to the hashtagItem object (=deal on API) with corresponding itemHash (=dealHash):

(With public key, we mean the full ethereum public key, not the shortened address)

replies =
    [
        {
            username: "Harry Humble",
            avatarHash: "QmQTTfDbE5wM1dvucWpaEmERXC75RUDhppoZLcBjNWLQ6D",
            address: "0x369D787F3EcF4a0e57cDfCFB2Db92134e1982e09",
            publicKey: "0x04836b35a026743e823a90a0ee3b91bf615c6a757e2b60b9e1dc1826fd0dd16106f7bc1e8179f665015f43c6c81f39062fc2086ed849625c06e04697698b21855e",
            reputation: "5",
            description: "I can help you better",
            dateTime: 1528215492,
        },
        {
            username: "Kars Rhyder",
            avatarHash: "QmQKDGf2TvWHHbwXJFe5cGj2NYGtKy73CMuuxozbv2LCy1",
            address: "0x369D787F3EcF4a0e57cDfCFB2Db92134e1982e09",
            publicKey: "0x04836b35a026743e823a90a0ee3b91bf615c6a757e2b60b9e1dc1826fd0dd16106f7bc1e8179f665015f43c6c81f39062fc2086ed849625c06e04697698b21855e",
            reputation: "5",
            description: "I can help you with that",
            dateTime: 1528215492,
        },{
            username: "Peter Pan",
            avatarHash: "QmS2aCaZqChcpwWQNAJExTXDedUpQiaVWo2LDHA8HYRvJf",
            address: "0x369D787F3EcF4a0e57cDfCFB2Db92134e1982e09",
            publicKey: "0x04836b35a026743e823a90a0ee3b91bf615c6a757e2b60b9e1dc1826fd0dd16106f7bc1e8179f665015f43c6c81f39062fc2086ed849625c06e04697698b21855e",
            reputation: "5",
            description: "I can help you tomorrow",
            dateTime: 1528215492,
        }
    ]
      

---

Todo API:

• Create task for replyRequest: get data in and write to leveldb
• Create subscription replyRequest
• Write test for replyRequest subscription