About Group: generate,update

[streetycat]

The Group object is mutable; we will update it regularly. So, we must use blockchain to update it to ensure version synchronization and verifiability.

Now, there is my solution, anyone can suggest for me.

1. There are 2 role in Group:

• Member: They are almost readonly except to update the self infomation.
• Admin: They can update the infomations according to authorization.

2. Configure permissions

• Assign each information a category.
• Define the weight threshold required for each information updates
• Grant each administrator a voting weight for each category
• Update the latest version when the update collect enough votes

3. Information classification

Category resume	Category	Field	Notes
Member list	admin	admins	add/remove
	member	members	add/remove
Display information of various scope	display-group	name	update
		icon
		description
	display-${self/member/admin}	Member.title	update the member
Asset information	asset	total_equity	shareholding capacity
		Member.shares	shares hold by each member
		token_contract	update the token contract
Conclusion rules	conclusion	conclusion	add/remove the conclusion category list
	conclusion-${category}	conclusion_category	update the rule for each category
The IT configure	it	ood_list	update the ood list running for group
		history_block_max	max count of reserved blocks
		history_block_lifespan	max milliseconds to reserved blocks
		consensus_interval	max period for consensus established
Custom permissions	custom-${any}		defined by the DecAPP

For example:

We require that more than 2 admins agree to modify the member title, or the member can modify it himself.

We can set the rules:

display-member=3
display-self=7

And assign the permissions:

display-member=2 // set to every admins, less than the rule, and greater than rule/2
display-self=9 // set to every member, greater than the rule

And, we can define the configure for each DecAPP on `Conclusion`, `IT`, `Custom`.

4. Group generate

   • Generate the group object
   • Send to every members and admins
   • Collect all signature from each member and admin, So, no one can join another to a group without notify
   • Push the object to MetaChain

   And we can push the object to MetaChain first, and all the admins/members post the signature to MetaChain. Of course, that would cost more commission.

5. Update the Group

   • Someone generate a new Group object, and send to others
   • Collect the signatures from members and admins in old version, and new members/admins from new version, ensure the new one has been notified.
   • Check all updated fields collected enough signatures.
     • Yes: update the latest version
     • No: Collect signatures continue

   We can collect the signatures off-chain to reduce the commission.

6. Cost

   There is commission for every on-chain operation, so we must reduce the frequency, I think there are some suggestion:

   • Save information on the chain as little as possible.
   • Delay submit the request, and wait more updates to submit together.
   • Don't submit updates from anotherone, to avoid someone high-frequency submission irresponsibly.

[waterflier]

The Group used in the real scene is really not simple, very deep thinking!

I have two suggestions:

1. Is there an easier way? Is it really necessary to put so much functionality in a standard Group? Should we implement these functions through an extensible design
2. About on-chain cost , I support the "initiator" do on-chain, which is simple and easy to understand.

[streetycat]

The Group used in the real scene is really not simple, very deep thinking!

I have two suggestions:

1. Is there an easier way? Is it really necessary to put so much functionality in a standard Group? Should we implement these functions through an extensible design
2. About on-chain cost , I support the "initiator" do on-chain, which is simple and easy to understand.

Good idea, There are only some base infomation and used in Stack should be implement in the standard Group, I think only the fields related to Members will be reserved, It seems like below:

Category resume	Category	Field	Notes
Member list	admin	admins	add/remove
	member	members	add/remove
Display information of various scope	display-group	name	update
		icon
		description
	display-${self/member/admin}	Member.title	update the member
OOD list	ood	ood_list	add/remove

And the others are also common functions, They can implement in another way:

Asset information	MetaChain as other Tx
Conclusion
Permissions
it	config with interface of `cyfs-group`

And, the details will be designed in future.