Ti	=	Managing Privileges / Synchronization
Intro: This would be a lot better if I knew more about git. Please help fill gaps.	=
0.sec	=	Thinking from first principles in the context of our Deal_Room use case.
1.Ti	=	Deal_Room is a Repo
1.0.sec	=	The Deal_Room is a "repo", which is the basic unit of P2P, a peer.
1.1.sec	=	A repo may be the world view of a Thing in the IoT.
1.2.sec	=	A repo may be a picture of me, or of one of my roles or of some part of me.
1.3.sec	=	I may carry a repo of some of me on my phone and keep most of me in repos in safer places (like I do with money).
1.4.sec	=	Parts of my repo are synchronized with repos belonging to others. A pretty good paradigm is email.
1.5.sec	=	The Deal_Room is a peer that is not associate with a Thing.
1.	=	[G/Z/ol/s5]
2.Ti	=	As a repo, the Deal_Room:
2.1.sec	=	has a creator, who will initially be the owner (right?).
2.2.sec	=	The owner may change by transfer. Or perhaps we will understand "transfer" as copy and delete of the constituent files. There are multiple levels of "ownership" and both notions probably need to be supported.
2.	=	[G/Z/ol/s2]
3.Ti	=	Sync/Access
3.1.sec	=	to receive information from other peers/repos. This could be understood as a pull-request.
3.2.sec	=	to transmit information to other peers/repos. This could be understood as a push. Access permission management could be understood as handling push-requests (pull-request-requests).
3.3.sec	=	a way to handle some requests automatically.
3.4.sec	=	a record of every action, including every modification of a rule regarding handling requests.
3.5.sec	=	a way to express DRM-ish rules on the materials that have been accessed. Review and delete within X seconds. Delete the content but you may keep the file name (if already hashed) or hash then delete the content. Perhaps this can be handled (or partially handled) by programmed pull-requests. After making a pull-request, the Resource Server makes an additional pull-request that involves deleting the file or making the file be empty.
3.	=	[G/Z/ol/s5]
4.Ti	=	Specification of Materials
(There is probably some inconsistent simplification in the prior discussion.)	=
4.0.sec	=	An access (pull-request) can concern a folder, the raw content of a number of specified files, or a Parse.
4.1.sec	=	The "Parse" request might be the most systematic way of handling requests. A Parse request is described - [here]. It is three components - a File name, a Key name, and a View name.
4.	=	[G/Z/ol/s1]
5.Ti	=	Distribution Lists
5.1.sec	=	In configuring the automation of handling of pull-request-requests, one will need something like a distribution list. Who is allowed to request what, subject to what conditions, and keep/destroy/redistribute on what terms.
5.2.sec	=	Prototype inheritance may be an appropriate way to handle those lists.
5.3.sec	=	There will need to be a record of each change.
5.4.sec	=	There will need to be a way to pass along all or parts of the distribution list as part of a pull-request.
5.	=	[G/Z/ol/s4]
	=	[G/Z/ol/5]