Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

As a Hashtagmaintainer I can resolve conflicts, so users have a safe and fair marketplace. #24

Open
kikipluche opened this issue May 31, 2018 · 0 comments

Comments

@kikipluche
Copy link
Contributor

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 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.

The API emits hashtagItemChanged event.


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:

  • 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.”


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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant