As a seeker, I can post a new request in a hashtag, describing what I am asking for and how much SWT I am offering, so providers can see what my need is.

[kikipluche]

Abstract:

In Swarm City, hashtags are marketplaces. A hashtag gives context to a SWT token transfer.

Users (seekers) can post new requests in a hashtag, inviting other users (providers) to reply to their requests.

How it could work:

In /new-request/[hashtagContractAddress]/, a Seeker fills in a request description and a SWT amount.

When the Seeker creates a request, the client uses UUIDv4 to create the dealId. The dealId is then SHA3 hashed by the client which results in a dealIdHash.

Then the client creates a JSON object from the data of the request:

{
 "name": "Tester X",    //username of sender
 "avatar" : "<IPFSHASH>",    // the IPFS hash of the users' avatar
 "description": "Translate my 1 page manifesto from English to Dutch",    // description of the deal
}

Next, the JSON object is serialized into a string. The string is sent to IPFS by the API. The ipfsAdd function adds the string to IPFS, and returns the resulting IPFS hash to the client (itemDataHash).

The client prepares the hashtag contract function-call makeDealForTwo. This function expects itemHash, offerValue and itemDataHash as arguments. The contract function will read out the hashtagFee and add it as a parameter.

This results in the data argument for the approveAndCall function in the token contract.

The value of approveAndCall is request value + 1/2 hashtagfee.

The approveAndCall transaction is then signed by the user.

The signed transaction is sent to the blockchain by the API. The sendSignedTx function adds the signed transaction to the blockchain and returns the resulting transaction hash.

The request is now posted.

---

What it looks like:

Userflow: https://invis.io/ABGM89SX3V5#/288386962_-Deal-Create-New ( > in Invision, hold shift to see clickable areas)

---

route: /hashtag/[hashtagaddress]/new-request

On view /new-request, we see:

• an inputfield for the description, labeled "What are you looking for?"
• an inputfield for the amount, labeled "What is your offer?", followed by copy "SWT"
• small copy: "+" and hashtagfee/2 and "SWT hashtagfee"
• horizontal divider line
• If, and only if all inputs are valid: copy "Total cost:" and total cost of deal (=amount+hashtagfee/2) and "SWT"
• a big blue icon button with a next icon (disabled until both inputs are valid)

The input field "amount" is valid when:

• the amount is a Numeric value with decimals
• the total cost (=amount + hashtagfee/2) is less than the user's total balance

The description input is valid when:

• it has at least 1 character

When the big blue button is enabled, and is tapped by the user, the view changes to confirm-new-request-page (1).

The confirm-new-request-page (1) contains:

• copy: "Post this request for" and (amount+hashtagfee) and "SWT"
• copy: "This can not be undone." and (hashtagfee/2) and "SWT hashtagfee is included"
• 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 confirmation process is aborted and the view changes to /new-request, with the inputs still filled in.

When the user taps the big white button with blue V-mark, he triggers the password-unlock (2) for signing the transaction.

When the white button of password-unlock (2) is enabled (= when the password input has at least 1 character) and tapped by the user, the page changes to new-request-processing (3).

new-request-processing (3) is a processing page (https://github.com/swarmcity/SwarmCityPM/issues/26), in this case the copy on succes is "Request is posted."

When the enabled white button with black next-icon is tapped by the user, the view changes to page /hashtag (of that specific hashtag) with the new item visible.

The white button is enabled when:

• the client receives the transaction hash from the API

---

Desktop view:

---

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

Documentation / references

An example of the above flow can be found in the unit tests https://github.com/swarmcity/SwarmCityContracts/blob/master/test/HashtagSimpleDeal-makedeal.js#L217 Note that an additional signature is added to the makeDealForTwo function. This should be removed from the logic (smart contract + javascript)

The HashtagSimpleDeal.sol can be found here: https://github.com/swarmcity/SwarmCityContracts/blob/master/contracts/HashtagSimpleDeal.sol

[matthewcarano]

I think this is very clear.

[QueenBeeSC]

Indeed. I agree this reads nicely.

[xardass]

NAMING THINGS hashtagItem = 1 word to rule them all

hashtagItem is the term we use to describe an item (that can be a request or a deal) on the hashtag. In the backend a hashtagItem can have different states.

Open = request Selected = request Accepted = deal Paid = deal Conflict = deal Resolved = deal

On the front-end, for the users, we will never use the word hashtagItem, but talk about a request or a deal.

A hashtagItem begins as a request and becomes a deal when:

• the seeker selected a provider’s offer = item: open -> selected and
• the provider accepted that he was selected = item: selected -> accepted

From this point onwards both parties are bound to execution of their agreement (= deal).

[xardass]

The above comments is how we discussed naming the deal items in the past. I propose we edit the epic in this way.

The user will read request or deal according to the above logic, on back-end side we use hashtagItem with a certain state as property.

In the Epic we need to change the naming accordingly, and add a 'state' property that can be open (0 or more providers have answered), selected (seeker accepted a provider), accepted (provider has funded the request, thus request is now a deal), paid, conflict and resolved.

[xardass]

I also propose we rename the page new-request-progress to new-request-processing, so this is consistent with transaction-processing

[kingflurkel]

@xardass I updated the epic changing "new-request-processing". The naming for dealstates is perfect! We'll check if every epic is consistent with it.

[xardass]

Can we rename ipfsMetaData to itemDataHash? (Same way we renamed ipfsHash for avatar to avatarHash).

[eduadiez]

Maybe the variables repBalance, balance,value, hashtagFee are not necessary, since they can create inconsistencies with the existing data on the smartcontracts

[xardass]

We can also remove dateTime, address and hashtag since those variables can be found by the API on the blockchain directly.

We might want to try to minimize our dependence on IPFS storage, and think about solution for default data when IPFS data retrieval fails.

With the above suggestions, we would only store the avatar, name and description on IPFS. If we fail getting those, we can use default avatar, address (public key) and a generic/empty message as description string.

[kikipluche]

• [x] the API has to check the hashtagcontract for the metadata (check latest hashtagfee), before making the deal.
• [x] change "hashtagcommission" in smart contract to "hashtagfee"
• [x] change some things on the smart contract (flurkel and edu)
• [x] the dealobject needs to be an immutable object
• [x] use same ownable contract (Zeppelin) everywhere
• [x] update the Rinkeby SWT to at least Minime

all checks have been turned into an issue or into text in the epic above.

[kikipluche]

• [x] kiki matt xardas change the naming as proposed

[xardass]

After reviewing future Epics, we probably don't need to add a 'state' property to a hashtagItem, since every transaction on a hashtagItem (accepted provider, conflict, payout...) will add to the hashtagItem the corresponding counterparty information anyway which we can filter on.