A short time ago I proposed a reward share app based on an idea by @ocrdu. I've set the working title Team Work for the project, but I'm not set on that 😉

I got some great feedback, especially from @primerz, @natureofbeing and @stellabelle. I'm mentioning you guys again because I could use a little bit more on the revised plan 😄

I've developed the idea down to the technical idea of how it works, and then back up to how this would operation and the idea in general. These planning documents are on this GitHub repository, publicly available.

I will reproduce some of it here. The main thing to have changed is that all communication now much be done through the blockchain. My original idea is that there'd be a lot of informal communication but this doesn't leverage the benefits of the system, for full group transparency and ease of synchronization. The revised proposal shows how this is used to standardize communication and simplify group management.

Help!

I'm asking for the following help if anyone can spare it:

Technical - review the idea and look for problems
Design - mock up designs based on Photon components
Writing - someone to take the idea out of jargon speak and into normal speak!

I think I'm looking at another full review and then design mock ups, leading to development. I'm planning on using Node.js backend with Electron + Photon frontend. This will allow for deployment on the big 3 operating systems.

Anyway, here's the proposal, newly tweaked.

Proposal

Originally proposed in this project-tracker ticket, and in this Steemit post.

Use cases

Collectives / cooperatives
Companies
Old-style guilds
Friends with benefits 😂

The project would suit a company structure or a group with various degrees of "shares". This is the main calculation example above.

As in @ ocrdu 's original idea, it would also be suitable for likeminded cooperatives or similar, where everyone get's an equal share.

Only on Steemit

With the push to make Steemit more attractive to businesses, this would be an interesting app for them, especially for groups who do not formally exist outside the blockchain here. In other words, you could use this to form a kind of company on Steemit without the use of any other kind of agreement. If someone in the group does not follow the pre-agreed payouts, they are automatically ejected, thus ensuring cooperation or revision of terms.

Overview

Several users all run an app (which would technically be a bot) individually as a client which an independently verify "transactions" (things that happen with the group) on the blockchain. This decentralization also protects them from key theft as private keys never leave their machine, except as transmitted when access Steem.

The app automatically distributes rewards (after post payment pre-HF17, or when posting after HF17) and verifies correct distribution. It also automatically manages group membership and facilitates changes to the group, such as adding / removing members, and updating group settings.

The group dynamics are based on consent which is sought for any proposal, from creating the group to begin with, to changing memberships and reward shares. Depending on context, either a quorum (default 75%) or unanimous approval is required for any proposal.

Additionally members which do not follow the terms set out in the founding settings are automatically removed, keeping membership fair and up front for all members. To avoid group splits or complete disintegration, good faith and cooperation is required.

Process

The group is proposed by one founding member, tagging all other founding members, who must all agree actively and unanimously to join.
Each client app syncs with the blockchain and observes posts tagged with the group hashtag. Anything with this hashtag is considered a group transaction (see process overview doc for info on what these are).
1. When a user in the group makes a post, they must use the group hashtag, and share rewards with the other users according to their allotted reward share.
  1. If payment is received, no action is taken as this is correctly as it should be.
  2. If no payment is received, the user is removed from the group
2. A user can propose a group change, such as changing the general group settings, adding / removing a user, dissolving the group, etc. These all require some high level of agreement (quorum or unanimous)
  1. If proposal is met with minimum agreement, it is passed and all client apply the change
  2. If proposal does not met minimum agreement, nothing happens, it is discarded
3. A user can voluntarily leave the group, and is encouraged to post a courtesy Leave Group transaction

Notes

Note that group members are not required to tag all their posts as group posts. Only posts with the group tag are considered group posts. However there may be a minimum level of activity set for the group as a condition of membership, and members should be aware of this. See the process detail doc for more info on this.

Also note that Group Posts do no necessarily have to involve the users in the group in any thematic and content context, just in rewards.

Calculating rewards

The reward distribution is set by way of reward shares. This is a simple way of determining a proportion in an intuitive way.

Importantly, this makes it scaleable. That means that when a new member is added, they are given certain reward shares and all other shares remain the same. However since there are now more rewards shares in total, the pre-existing members proportion goes down of course.

For example:

User A has 50
User B has 10
User C has 75

So here the total reward shares at 135, resulting in

User A has approx 37%
User B has approx 7.4%
User C has approx 55.6%

If we add a new user with 20 shares, the new total will be 155, and thus

User A has 50, approx 32.3%
User B has 10, approx 6.4%
User C has 75, approx 48.4%
User D has 20, approx 12.9%

If instead the group wants users are to be equal, they should simply have the same reward share, say 10, and this is scalable also in the same way.

UI overview

Team Work - UI

A rough-and-ready summary of the various UI sections required in the app

On First Launch

User is required only to enter their Steem username.

Perhaps some on-boarding is shown. We could nicely ask @ stellabelle to do it, as she said in a comment on the launch post:

[...] I'd like to use art and words to communicate some technically challenging thing for regular people. [...]

Normal operation

This is a pretty messy list that was condensed from a pretty messy but easier to read ui overview document).

Stats
1. Overall combined rewards for group (perhaps over time?)
2. Contributions by each user in last time period (week / month / all time)
3. Current balances (accuracy of rewards, should only be a pre-HF17 feature)
Post
Settings
1. Group Settings
  1. Link to group formation post
  2. Group hashtag (goes on all group posts), e.g. #group-awesome-writers
  3. Members list, with reward share (int)
  4. Quorum percentage (default: 75%), used for most agreements
  5. Percentage for group dissolution (default: quorum), can be quorum or 100%
  6. Dead member time (default: inf), time of inactivity* after which any member is automatically removed from group
2. Personal Settings
  1. Edit private posting key
3. Notification settings
  1. Show normal rewards received notification
  2. Show personal inactivity warnings (only visible of dead member time is not infinite)
  3. Disable all (not recommended)
4. Advanced settings
  1. Steem WebSockets server list (connections to steem API)
  2. Auto sync on / off
    1. Auto sync frequency (default: once an hour)
Transactions - view all as list
Broadcast
1. Open New Transaction - note that each broadcast has an optional text content field within which normal messages can be added. This is in plain text but can be HTML or Markdown styled (or any other encoding for that matter, but these are generally recognized).
  1. Form Group
    1. Group hashtag (note, this is kind of a replacement of the group name as formally there is no separate name, though one can be informally agreed)
    2. List of founding members, and their reward shares
    3. Quorum percentage (default: 75%), used for agreements
    4. Percentage for group dissolution (default: quorum), can be quorum or 100%
    5. Dead member time (default: inf), time of inactivity after which any member is automatically removed from group
  2. Update Group Settings
    1. As above
  3. Add Group Member
    1. User's account name (will be added with @ as mention)
    2. Proposed reward share (as integer)
  4. Remove Group Member
    1. User's account name
    2. Proposed reward share (as integer)
  5. Leave Group
    1. No fields except always present additional text box. When activating, the user will be prompted with a severe looking "Are you sure?!" pop up or similar, to confirm destructive action.
  6. Dissolve Group
    1. As above
Notifications
1. Broadcasts by group members
  1. Broadcast update group settings petition
  2. Broadcast add user petition
  3. Broadcast remove user petition
  4. Broadcast dissolve group petition
  5. Broadcast leave group statement
2. A group member has posted
3. A group member's rewards have been recognised
  1. (optional as set in settings) As correct
  2. As incorrect, serving as notification of their removal from group
4. (optional as set in settings) A member has not posted group post in time period (week / month)

More detail

Also see the UI design brainstorm I did, showing what is possible with the UI frame work Photon.

Technical overview

The process outlined here is in fact a general process template for any app built on the Steem blockchain which requires consent based synchronisation and a deterministically defined methodology for some app business logic.

In the case of Team Work, the business logic is basically group membership management and reward share accounting.

There are two main components: state and transactions.

There will also be the addition of custom internal data which is application specific. In the case of Team Work this will be the group configuration (member list, reward shares, etc.), the current "accounts" of the group and any other relevant data.

State

Each client app is a finite state machine (FSM) which means that the app can be in only one state at any particular time, there is no overlapping of states, and there is a known number of states.

Particular to Team Work, we have the following states:

Inactive: has not joined a group
Pending: group proposal recognized and formation is pending
Active: group has been formed, this user is a member

State transitions are governed by transaction events. The state cannot be changed by direct user input, which are read from the Steem blockchain.

Transactions

This is the main work of the app. A transaction is a complete operation pertaining to the group. It can be opened, provided with supplementary information depending on type, and closed by some event.

Opening, supplementing and closing events are called sub-transactions. All events are carried out on the blockchain so there is no direct app to app communication.

They can be Steem posts, comments, or in the case of reward shares, the transaction of receiving payment. They can also be time based, and all transactions will have a closing clause based on a time out.

Note that these are distinct from Steem blockchain transactions, they could be considered meta-transactions, or transactions within Steem posts.

Transaction types for Team Work

Form Group proposal (initial action)
Update Group Settings proposal
Group post (main action, post rewards are shared)
Add Group Member proposal
Remove Group Member proposal
Leave Group statement
Dissolve Group proposal

QUESTION: should there be a transaction to request updating one's own or another group members share?

Special conditions

Dead member, optionally defined in group settings, to remove inactive members after certain length of time.

Transaction management

Transactions are simply marked by usage of the group hashtag.

Recognized group posts and comments

The first transaction, group formation proposal, must be manually supplied to the app when it is in the inactive state. This will be in the form of a recognized Steem post, as detailed above.

From this point on, the app will track transactions automatically based on what is available on the blockchain, as all are tagged with the group hashtag. When the app syncs with the blockchain it will look for posts with the group hashtag, and attempt to identify them based on recognizable format.

Once recognized, it is interpreted as a transaction event (also termed sub-transaction here) and is applied to the internal state, causing some deterministic change, such as change in membership, accounting, etc.

In some cases this will result in a state change, such as when the group is formed (pending -> active), or this user is removed from the group by consensus (active -> inactive).

In other cases this will result in a Steem transaction, as in the case where the reward is shared after payout. Note however that this is pre-HF17 only, post-HF17 this is automatic by the blockchain.

Unrecognized group posts

If a group post cannot be recognized then it is assumed to be a normal group post and the rewards on this post must be paid to group members correctly.

Sync and local storage

Because we use meta-transactions, which are somewhat similar to how the blockchain works anyway, we can use the same idea of syncing by replaying transactions.

Any post with the group hashtag which is created after the formation transaction is a transaction. We can get the current state by replaying these transactions in the client app one after the other, until reaching the latest transaction we have available. As long as this transaction is the same as the others in the group.

The main thing we need to persist between app sessions is the state and local data of the app, i.e. the result of all transactions, "played" one after the other, to the present moment. Local data consists of information about open transactions and settings.

We can optionally keep closed transaction information, perhaps up to an age limit (a month?) or keep all transaction history locally.

Note however that we don't really have to persist anything, it's only a convenience. The entire group history can be replayed at any time if required to verify the current state's integrity.

Even more technical details

I've worked out what each transaction will entail, and it required a bit of shorthand jargon, but please check it out if you're interested in the process detail doc.

Some potential issues and questions

Some of the implications of the system, quirks and things to watch out for and discuss.

Time critical sync issues

Some transactions are time critical and require precise syncing. This means that before any operation is performed, the client app must make sure it's up to date by checking for new transactions before posting a new transaction.

This goes especially for the most basic function, posting a group post, as the member list could have changed since last sync. The downside of this is that makes it unsafe to create a group post outside the app. But of course it would be at the discretion of the user to unsafely assume there would be no change in membership, or safely post their group post through the app, which will automatically check for membership change by syncing with the Steem blockchain.

Optional "strikes" for incorrect reward setting

Removing a user automatically because of incorrect reward distribution may be too strict for some group configurations, as it does not give any leeway for human error.

I do think however that in some groups a one-strike-and-you're-out policy would work best, for example in groups, especially larger groups, where members do not know each other well.

Perhaps there should be an optional "strikes" setting for each user to allow for this to be handled, still automatically, but with more tolerance if desired. Don't forget that automatic systems lend a kind of useful impartiality and up-front-ness in operations that informal, ad hoc agreements can lack.

I suggest perhaps the following options:

Strict, one-strike removal
Benefit of the doubt, two-strike removal
Tolerant, three-strike removal
Voluntary, no automatic removal

Calculations Cavet for pre-HF17

Before HF17, only liquid Steem can be transferred instantly. This should be taken into account for calculations. The payout of liquid Steem seems to be 62% of vested Steem (i.e. Steam Power) payout. Calculation should not be a problem even in this case as the algorithm will be deterministic (always the same) and as long as everyone has access to the same blockchain (of course a basic requirement).

This would make some distribution configurations impossible to do directly but could be applied like rolling ledger keeping track of who has been "overpaid" by themselves due to automatic investment of reward by the system. As long as all members are similarly active and paid (probably unlikely!) it would work out. Otherwise it will be a "best effort" system.

After HF17 this will not be a problem unless there are similar restrictions on reward proportions.

Calculation Post-HF17

From Steemit Roadmap 2017:

A general solution [to reward splitting] is allowing for arbitrary splitting of a post’s rewards to a list of parties—such as author, hosting provider, blog site, or referrers—to provide for different business models and applications.

This takes the manual work out of the process and simplifies the idea. We have yet to see how this will happen, but no matter how (whether it is percentage based, with minimums, etc.) it can be applied to this project.

The main idea stays the same, but tagging is no longer required because post reward beneficiaries will be publicly available to read from the blockchain.

That's all for now!

Thanks for taking the time to read this if you did. I know it's a lot of stuff but that's planning for you 😅

All feedback, questions and help offered welcome! 😆

Image used

Creative Commons license; Thinking Please Wait by The Bullethead

Team Work - reward share groups - new app for Steem - updated proposal