nurupo/groupchat-permissions.txt

## groupchat-permissions.txt
1. Founder has all permissions.

2. Everyone in the chatroom can verify that public key X is indeed founder's key, it's a property of the chatroom and no peer stores it i.e. the chatroom itself contains that information somewhere, presumably in its ID (we don't rely on chatroom peers storing that data because they can came up with whatever they want i.e. say that the key X is not founder's key; we want that verification to be 100% exact and to work with even 1 peer in the chatroom).

3. To give permissions to user A, founder gives user A data which tells what permission level does A have (if we are going to have permission levels in tox at all). The data is signed by founder's private key.

4. Now A can show anyone that signed by founder data from the step (3) as a proof of her having permissions (anyone can verify that it was indeed signed by founder by (2)), so A can exercise her rights over everyone in the chatroom.

5. If A gives permissions to B, 1) A sends her founder-signed data to B to show that she is eligible to give someone permissions and 2) A gives B a private-key signed proof that A was indeed the one who gave B those permissions. For the simplicity, this tuple of 1) and 2) will be called "cookie" next. Note that (3) is a special case of cookie where 1) is missing, since founder doesn't have to verify that he has permissions, it is so by design, see (1) and (2).

6. If B gives permissions to C, 1) B sends his cookie to C to show that he is eligible to give someone permissions and 2) B gives C a private-key signed proof that B was indeed the one who gave C those permissions.

7. If C gives permissions to D, 1) C sends her cookie to D to show that she is eligible to give someone permissions and 2) C gives D a private-key signed proof that C was indeed the one who gave D those permissions.

8. And so on.

9. D's cookie contains information that 1) founder gave permissions to A, 2) A gave permissions to B, 3) B gave permissions to C, 4) C gave permissions to D. So it's just like a chain from a leaf (the permission holder) to the root (the founder) of a permission tree. We could even try enforcing that permission holders can't exercise their permissions on anyone above them in that permission tree (by "above" i mean the tree level, i.e. even considering people above that are on other tree branches/leaf-root chains too), since we store a permission chain anyway.

10. It doesn't really have to go in a chain as described in (5) - (9) (Founder -> A -> B -> C -> D), it can be any form of a tree, for example Founder -> {A, B -> {D}, C}:
  Founder
   / | \
  A  B  C
     |
     D
i.e. in that case Founder gave permissions to A, B and C, and B gave them to D. So D would have Founder -> B -> D cookie, while C would have Founder -> C. It can be any kind of a tree and a chain in (5) - (9) was selected for easier understanding.

11. Regular chatroom peers don't have to store permission information (the cookie), only permissions holders need to store it. They can show their cookie to anyone and anyone can confirm that it's legit by verifying the permission chain starting from founder.

12. Bad things happen when users don't follow what permission holders do, as in permission holder kicking user Y from the chatroom, but Y just ignores that.
UPDATE: I initially thought that if X kicks user Y, then Y should disconnect himself from everyone, which Y can get around by disabling the disconnect on kick functionality in his toxcore, but if we make everyone in the chatroom disconnect from Y when X kicks Y, then it has higher chance of working. Also, if X bans Y, then all users in the chat would store X's signed data that X banned Y (i.e. a rule that you shouldn't connect to Y) and X's cookie, to verify that X was eligible to ban someone. Though that throws us in the whole issue of that ban data being synced with all groupchat users, which was the problem in hentoba's initial groupchat design, which I tried to avoid (I tried to avoid any need for data to be synced at all). Though it should be relatively easy compared to hentoba's design to handle the sync since we don't have notion of a fake permission holder because of (4).

13. The other bad thing is that if one permission holder X takes away permission rights from another permission holder Y, Y might not comply with this (modified toxcore, for example) and keep his cookie, just like what (12) describes. As long as Y has a valid cookie, Y is said to have permissions. So you can't take away permissions that easily.
UPDATE: This can also be solved the same way bans are described to work in (12)'s update, i.e. everyone would store information that X took away permission rights of Y at time T, so if Y exercises his rights after time T, those things should be ignored.

14. Referring to the original chain of permissions (3) - (7), we might not want D to be able to take away permissions from A. That brings the hierarchy idea from (9), so that all permissions holders have some level that is defined by how further away they are from the founder, and permission holders with lower level can't exercise their powers over permission holders with higher level.
	1. Founder has all permissions.

	2. Everyone in the chatroom can verify that public key X is indeed founder's key, it's a property of the chatroom and no peer stores it i.e. the chatroom itself contains that information somewhere, presumably in its ID (we don't rely on chatroom peers storing that data because they can came up with whatever they want i.e. say that the key X is not founder's key; we want that verification to be 100% exact and to work with even 1 peer in the chatroom).

	3. To give permissions to user A, founder gives user A data which tells what permission level does A have (if we are going to have permission levels in tox at all). The data is signed by founder's private key.

	4. Now A can show anyone that signed by founder data from the step (3) as a proof of her having permissions (anyone can verify that it was indeed signed by founder by (2)), so A can exercise her rights over everyone in the chatroom.

	5. If A gives permissions to B, 1) A sends her founder-signed data to B to show that she is eligible to give someone permissions and 2) A gives B a private-key signed proof that A was indeed the one who gave B those permissions. For the simplicity, this tuple of 1) and 2) will be called "cookie" next. Note that (3) is a special case of cookie where 1) is missing, since founder doesn't have to verify that he has permissions, it is so by design, see (1) and (2).

	6. If B gives permissions to C, 1) B sends his cookie to C to show that he is eligible to give someone permissions and 2) B gives C a private-key signed proof that B was indeed the one who gave C those permissions.

	7. If C gives permissions to D, 1) C sends her cookie to D to show that she is eligible to give someone permissions and 2) C gives D a private-key signed proof that C was indeed the one who gave D those permissions.

	8. And so on.

	9. D's cookie contains information that 1) founder gave permissions to A, 2) A gave permissions to B, 3) B gave permissions to C, 4) C gave permissions to D. So it's just like a chain from a leaf (the permission holder) to the root (the founder) of a permission tree. We could even try enforcing that permission holders can't exercise their permissions on anyone above them in that permission tree (by "above" i mean the tree level, i.e. even considering people above that are on other tree branches/leaf-root chains too), since we store a permission chain anyway.

	10. It doesn't really have to go in a chain as described in (5) - (9) (Founder -> A -> B -> C -> D), it can be any form of a tree, for example Founder -> {A, B -> {D}, C}:
	Founder
	/ \| \
	A B C
	\|
	D
	i.e. in that case Founder gave permissions to A, B and C, and B gave them to D. So D would have Founder -> B -> D cookie, while C would have Founder -> C. It can be any kind of a tree and a chain in (5) - (9) was selected for easier understanding.

	11. Regular chatroom peers don't have to store permission information (the cookie), only permissions holders need to store it. They can show their cookie to anyone and anyone can confirm that it's legit by verifying the permission chain starting from founder.

	12. Bad things happen when users don't follow what permission holders do, as in permission holder kicking user Y from the chatroom, but Y just ignores that.
	UPDATE: I initially thought that if X kicks user Y, then Y should disconnect himself from everyone, which Y can get around by disabling the disconnect on kick functionality in his toxcore, but if we make everyone in the chatroom disconnect from Y when X kicks Y, then it has higher chance of working. Also, if X bans Y, then all users in the chat would store X's signed data that X banned Y (i.e. a rule that you shouldn't connect to Y) and X's cookie, to verify that X was eligible to ban someone. Though that throws us in the whole issue of that ban data being synced with all groupchat users, which was the problem in hentoba's initial groupchat design, which I tried to avoid (I tried to avoid any need for data to be synced at all). Though it should be relatively easy compared to hentoba's design to handle the sync since we don't have notion of a fake permission holder because of (4).

	13. The other bad thing is that if one permission holder X takes away permission rights from another permission holder Y, Y might not comply with this (modified toxcore, for example) and keep his cookie, just like what (12) describes. As long as Y has a valid cookie, Y is said to have permissions. So you can't take away permissions that easily.
	UPDATE: This can also be solved the same way bans are described to work in (12)'s update, i.e. everyone would store information that X took away permission rights of Y at time T, so if Y exercises his rights after time T, those things should be ignored.

	14. Referring to the original chain of permissions (3) - (7), we might not want D to be able to take away permissions from A. That brings the hierarchy idea from (9), so that all permissions holders have some level that is defined by how further away they are from the founder, and permission holders with lower level can't exercise their powers over permission holders with higher level.