In the first hashtags on Swarm City Boardwalk, a request becomes a deal when both parties agree to the deal, and are equally invested in it.
Both Seeker and Provider can put the deal in a state of conflict. This means the funds are locked, and only the Hashtagmaintainer can decide how the funds will be paid out.
How it could work:
When a deal is in state "Disputed", the Hashtagmaintainer will see the deal on top of the hashtaglist. On the detail view, the Hashtagmaintainer now can enter the chat to figure out what went wrong.
The Hashtagmaintainer can resolve the disputed deal. The Hashtagmaintainer chooses what portion of the pledged funds get returned to Provider and Seeker. The Hashtagmaintainer then pays out those amounts by triggering function resolve in the hastagcontract.
The Hashtagmaintainer signs the transaction on the client and sends it to the API.
How the API could work:
Re-use sendSignedTx:
The api receives the signed transaction and returns a transaction hash.
When a deal is in conflict (1), directly below the shareable link, the hashtag maintainer of that specific hashtag sees:
a horizontal divider line
the reply of the Provider, consisting of:
reply description
Datetime
black checkmark (small) and (amount) and 'SWT'
avatar
name an "•" and ProviderRep and "SWR" (blue)
visually presented simple as "SWR"
a horizontal divider line
a chat-button
copy "This deal is in conflict."
smaller copy "You were added to the chat."
big button, copy "resolve"
a red border
When the maintainer taps the resolve-button, the detailview of the item changes to show the resolve-view (2). This view consists of:
a horizontal divider line
the reply of the Provider, consisting of:
reply description
Datetime
black checkmark (small) and (amount) and 'SWT'
avatar
name an "•" and ProviderRep and "SWR" (blue)
visually presented simple as "SWR"
a horizontal divider line
percentage the Seeker will receive
amount of tokens the Seeker will receive
Seeker avatar
Seeker name an "•" and SeekerRep and "SWR" (blue)
visually presented simple as "SWR"
a slider with green dragpoint
percentage the Provider will receive
amount of tokens the Provider will receive
Provider avatar
Provider name an "•" and ProviderRep and "SWR" (blue)
visually presented simple as "SWR"
black Xmark (cancelbutton)
Big white iconbutton with blue V-mark (confirmbutton)
On this view, the maintainer can decide how to divide the funds among Seeker and Provider by:
dragging the slider (which makes the percentages and amount changes instantly on release)
tapping on a percentage, which turns into an input field (slider and amount change when new value is input here)
tapping on an amount, which turns into an input field (slider and percentage change when new value is input here)
When the maintainer wants to confirm this division and carry it out, he/she taps the white iconbutton with blue Vmark. This will change the view to confirm-resolve-page (3).
The copy on confirm-resolve-page (3) is "Send [Seekeramount] SWT to [Seeker] and [Provideramount] SWT to [Provider]?". The small copy is "This can not be undone."
When the maintainer taps the big white button with blue V-mark, he triggers the password-unlock (3b) for signing the transaction.
When the white button of password-unlock (3b) is enabled and tapped by the user, the page changes to resolve-processing-page (4).
resolve-processing-page (4) is a processing page (swarmcity/SwarmCityPM#26), in this case the copy on succes is "[Seeker] and [Provider] have been paid."
In the chatview it will also be visible that the conflict is now in resolved.
timestamp of when deal was put in conflict
a “servicemessage” with copy: “The conflict is resolved by the hashtag maintainer. [Seeker] has been paid [Resolve-seeker-amount] SWT and [Provider] has been paid [Resolve-provider-amount] SWT.”
Abstract:
In the first hashtags on Swarm City Boardwalk, a request becomes a deal when both parties agree to the deal, and are equally invested in it.
Both Seeker and Provider can put the deal in a state of conflict. This means the funds are locked, and only the Hashtagmaintainer can decide how the funds will be paid out.
How it could work:
When a deal is in state "Disputed", the Hashtagmaintainer will see the deal on top of the hashtaglist. On the detail view, the Hashtagmaintainer now can enter the chat to figure out what went wrong.
The Hashtagmaintainer can resolve the disputed deal. The Hashtagmaintainer chooses what portion of the pledged funds get returned to Provider and Seeker. The Hashtagmaintainer then pays out those amounts by triggering function
resolvein the hastagcontract.The Hashtagmaintainer signs the transaction on the client and sends it to the API.
How the API could work:
Re-use sendSignedTx: The api receives the signed transaction and returns a transaction hash.
The API emits
hashtagItemChangedevent.What it looks like:
Userflow: https://invis.io/ABGM89SX3V5#/299316514_-Hashtag--contractadress---dealhash-_RESOLVE_I ( > in Invision, hold shift to see clickable areas)
route: /hashtag/[contractadress]/[dealhash]
When a deal is in conflict (1), directly below the shareable link, the hashtag maintainer of that specific hashtag sees:
When the maintainer taps the resolve-button, the detailview of the item changes to show the resolve-view (2). This view consists of:
On this view, the maintainer can decide how to divide the funds among Seeker and Provider by:
When the maintainer wants to confirm this division and carry it out, he/she taps the white iconbutton with blue Vmark. This will change the view to confirm-resolve-page (3).
The copy on confirm-resolve-page (3) is "Send [Seekeramount] SWT to [Seeker] and [Provideramount] SWT to [Provider]?". The small copy is "This can not be undone."
When the maintainer taps the big white button with blue V-mark, he triggers the password-unlock (3b) for signing the transaction.
When the white button of password-unlock (3b) is enabled and tapped by the user, the page changes to resolve-processing-page (4).
resolve-processing-page (4) is a processing page (swarmcity/SwarmCityPM#26), in this case the copy on succes is "[Seeker] and [Provider] have been paid."
In the chatview it will also be visible that the conflict is now in resolved.
Desktop view:
Invisionlinks with login (for inspect mode!): mobile: https://projects.invisionapp.com/d/main#/console/13838256/299316514/inspect desktop: https://projects.invisionapp.com/d/main#/console/14147648/299114362/inspect
Documentation / references
With ♡ from Swarm City