git ssb - First sketch data structures · kieran/horcrux-schemas-and-thoughts@77cc88e9

Commit 77cc88e93406723a3e5a75c81ec5ed4225471eee

First sketch data structures

Kieran committed on 3/22/2018, 12:27:49 PM
Parent: 927451e856b500986bc948d2c13b10925d06bf4e

Files changed

README.md	changed
schemas/invite.json	changed
schemas/response.json	changed
schemas/root.json	changed
schemas/secret.json	changed
schemas/request.json	deleted
schemas/trustees.json	added

README.mdView
		@@ -3,8 +3,9 @@
3	3 …	![Abaddon the Despoiler](./assets/abaddon.jpg)
4	4 …
5	5 …	## Important
6	6 …	* Abaddon's soul is never committed to the database. It is sharded, and discarded. At no stage is it compromised.
	7 …	+* All messages are private and encrypted either between the individuals involved or between the group.
7	8 …
8	9 …	## Event Flow
9	10 …
10	11 …	\| Invitee \| Response \| Secret Shard \|
		@@ -34,16 +35,18 @@
34	35 …	- Abaddon can still send out more invitations if he likes.
35	36 …
36	37 …	All of Abaddon's different secret sharing `root` events can be summoned using:
37	38 …
	39 …	+```javascript
	40 …	+api.secrets.root.get()
	41 …	+api.secrets.root.stream(callback)
38	42 …	```
39		-api.secrets.all.get(callback)
40		-```
41	43 …
42	44 …	Invites can be viewed through the API and a FlumeView... something along the lines of:
43	45 …
44	46 …	```
45		-api.secrets.invites.get(rootId, callback)
	47 …	+api.secrets.invites.get(rootId)
	48 …	+api.secrets.invites.stream(rootId, callback)
46	49 …	```
47	50 …
48	51 …	### 2. Responses
49	52 …
		@@ -54,12 +57,13 @@
54	57 …	- A response writes a [`secret_response`](./schemas/response.json) that indicates whether they accepted the invite or not
55	58 …	- References the rootId so can be easily filtered through the API / a FlumeView
56	59 …
57	60 …	```
58		-api.secrets.responses.get(rootId, callback)
	61 …	+api.secrets.responses.get(rootId)
	62 …	+api.secrets.responses.stream(rootId, callback)
59	63 …	```
60	64 …
61		-### 3. Participants
	65 …	+### 3. Trustees
62	66 …
63	67 …	Abaddon decides its time to proceed with his super evil plan and shard his soul...
64	68 …
65	69 …	> I now have enough super evil allies.
		@@ -76,33 +80,35 @@
76	80 …	- Abaddon can now select the ones he _really trusts_, his inner circle.
77	81 …	- Abaddon can now set a `quorum` of cosigners required to combine his sharded soul and make him mortal again.
78	82 …	- Abaddon can now select whether he wants the final cosigners to know who eachother are. Does he trust them enough not to conspire against his evil plans for immortality?
79	83 …	- Abaddon then hits send, his soul is sharded as he screams into the abyss.
80		-- Generates a [`secret_participants`](./schemas/participants.json) event which includes:
	84 …	+- Generates a [`secret_trustees`](./schemas/trustees.json) event which includes:
81	85 …	- IDs of the _final_ cosigners
82	86 …	- The required number of cosigners to release his secret
83	87 …
84	88 …	- If Abaddon enabled it, those within that group of final cosigners can now see who eachother are.
85	89 …	- Immediately triggers the [Secrets event](#4-secrets)
86	90 …
87		- ```
88		- api.secrets.participants.get(rootId, callback)
89		- ```
	91 …	+```
	92 …	+api.secrets.trustees.get(rootId)
	93 …	+api.secrets.trustees.stream(rootId, callback)
	94 …	+```
90	95 …
91	96 …	Questions
92	97 …	* Does having a secretive or non-secretive sharding require two different types of event? Or is it just a boolean flag? Needs clarification as it depends how the data is scuttled...
93	98 …
94	99 …	### 4. Secrets
95		-Immediately after Abaddon has confirmed the sharding of his soul, and the participants log has been created, each member of the participants will be gossiped a private message detailing their own shard.
	100 …	+Immediately after Abaddon has confirmed the sharding of his soul, and the trustees log has been created, each member of the trustees will be gossiped a private message detailing their own shard. The author is Abaddon and the recipient
96	101 …
97	102 …	What does this do?
98	103 …	- Each trustee receives a shard of Abaddon's soul.
99	104 …
100	105 …	```
101		-api.secrets.pieces.get(callback)
	106 …	+api.secrets.pieces.get(rootId)
	107 …	+api.secrets.pieces.stream(rootId, callback)
102	108 …	```
103	109 …
104		-// Needs more thought... Should the participants know the rootId? Do they need to?
	110 …	+// Needs more thought... Should the trustees know the rootId? Do they need to?
105	111 …
106	112 …
107	113 …	## Note:
108	114 …	- `secret_invite` and `secret_response` looks a lot like Patchbay's `ssb-chess`: `chess_invite` and `chess_accept`.

schemas/invite.jsonView
		@@ -1,21 +1,26 @@
1	1 …	{
2		- "type": "secret_invite",
3		- "text": "[@Kieran](@MpDd66GPXgN1+eMNrZInHkWq1THMurWwLdMx8BZ1ncw=.ed25519) invites you to secure his secret...",
4		- "recipients": [
5		- {
6		- "link": "@ye+QM09iPcDJD6YvQYjoQc7sLF/IFhmNbEqgdzQo3lQ=.ed25519",
7		- "name": "mix"
8		- },
9		- {
10		- "link": "@NeB4q4Hy9IiMxs5L08oevEhivxW+/aDu/s/0SkNayi0=.ed25519",
11		- "name": "Dan Hassan"
	2 …	+ "key": "%kQL0FcDYPJYVfT6qxV0H7d5ChiCJbdIkdv1yGYKYd8E=.sha256",
	3 …	+ "value": {
	4 …	+ "previous": "...",
	5 …	+ "author": "@MpDd66GPXgN1+eMNrZInHkWq1THMurWwLdMx8BZ1ncw=.ed25519",
	6 …	+ "sequence": "...",
	7 …	+ "timestamp": "...",
	8 …	+ "hash": "sha256",
	9 …	+ "content": {
	10 …	+ "type": "secret_invite",
	11 …	+ "root": "%qHZCXd0spsGVlEvMrvkZHVtndgYNOHxZFiVZm1+tplA=.sha256",
	12 …	+ "text": "[@Kieran](@MpDd66GPXgN1+eMNrZInHkWq1THMurWwLdMx8BZ1ncw=.ed25519) invites you to secure his secret...",
	13 …	+ "recipient": {
	14 …	+ "link": "@NeB4q4Hy9IiMxs5L08oevEhivxW+/aDu/s/0SkNayi0=.ed25519",
	15 …	+ "name": "Dan Hassan"
	16 …	+ },
	17 …	+ "mentions": [
	18 …	+ {
	19 …	+ "link": "@MpDd66GPXgN1+eMNrZInHkWq1THMurWwLdMx8BZ1ncw=.ed25519",
	20 …	+ "name": "Kieran"
	21 …	+ }
	22 …	+ ]
12	23 …	}
13		- ],
14		- "mentions": [
15		- {
16		- "link": "@MpDd66GPXgN1+eMNrZInHkWq1THMurWwLdMx8BZ1ncw=.ed25519",
17		- "name": "Kieran"
18		- }
19		- ],
20		- "private": true
	24 …	+
	25 …	+ }
21	26 …	}

schemas/response.jsonView
		@@ -1,14 +1,26 @@
1	1 …	{
2		- "type": "accept_secret",
3		- "text": "[@Kieran](@MpDd66GPXgN1+eMNrZInHkWq1THMurWwLdMx8BZ1ncw=.ed25519) wants to share a secret with you...",
4		- "mentions": [
5		- {
6		- "link": "@ye+QM09iPcDJD6YvQYjoQc7sLF/IFhmNbEqgdzQo3lQ=.ed25519",
7		- "name": "mix"
8		- },
9		- {
10		- "link": "@NeB4q4Hy9IiMxs5L08oevEhivxW+/aDu/s/0SkNayi0=.ed25519",
11		- "name": "Dan Hassan"
	2 …	+ "key": "%rBpGhzSwvhToQJU7cTJfK+qQlMqT//GmLMaAQi0xGKc=.sha256",
	3 …	+ "value": {
	4 …	+ "previous": "...",
	5 …	+ "author": "@NeB4q4Hy9IiMxs5L08oevEhivxW+/aDu/s/0SkNayi0=.ed25519",
	6 …	+ "sequence": "...",
	7 …	+ "timestamp": "...",
	8 …	+ "hash": "sha256",
	9 …	+ "content": {
	10 …	+ "type": "secret_response",
	11 …	+ "root": "%qHZCXd0spsGVlEvMrvkZHVtndgYNOHxZFiVZm1+tplA=.sha256",
	12 …	+ "invite": "%kQL0FcDYPJYVfT6qxV0H7d5ChiCJbdIkdv1yGYKYd8E=.sha256",
	13 …	+ "accept": true,
	14 …	+ "text": "I am the soul harvester ... I will harvest your soul [@Kieran](@MpDd66GPXgN1+eMNrZInHkWq1THMurWwLdMx8BZ1ncw=.ed25519)",
	15 …	+ "mentions": [
	16 …	+ {
	17 …	+ "link": "@MpDd66GPXgN1+eMNrZInHkWq1THMurWwLdMx8BZ1ncw=.ed25519",
	18 …	+ "name": "Kieran"
	19 …	+ }
	20 …	+ ]
12	21 …	}
13		- ]
	22 …	+ }
14	23 …	}
	24 …	+
	25 …	+// Should it include the id of the secret splitter?
	26 …	+// Rather than having to stream through to search for the invite based on the inviteId?

schemas/root.jsonView
		@@ -1,0 +1,24 @@
	1 …	+{
	2 …	+ "key": "%qHZCXd0spsGVlEvMrvkZHVtndgYNOHxZFiVZm1+tplA=.sha256",
	3 …	+ "value": {
	4 …	+ "previous": "...",
	5 …	+ "author": "@MpDd66GPXgN1+eMNrZInHkWq1THMurWwLdMx8BZ1ncw=.ed25519",
	6 …	+ "sequence": "...",
	7 …	+ "timestamp": "...",
	8 …	+ "hash": "sha256",
	9 …	+ "content": {
	10 …	+ "type": "secret_root"
	11 …	+ }
	12 …	+ }
	13 …	+}
	14 …	+
	15 …	+// Root needs contain little to no information about events after it exists
	16 …	+
	17 …	+// Exists purely as a means to allow for a many to many relationship
	18 …	+// for an "author" to it's secrets.
	19 …	+
	20 …	+// If we were to have an secret sharding stream of events tied to their id / key, it
	21 …	+// would permit only one per person
	22 …	+
	23 …	+// Invites, Responses, Trustees and Secrets can all
	24 …	+// be queried and found using this root

schemas/secret.jsonView
		@@ -1,11 +1,37 @@
1	1 …	{
2		- "type": "secret",
3		- "text": "80171f51d1f9cf6f6a8f3b08dee2ca5575cec57f32d02ed9f4435e940f1888637e1005e43232048fee13dd8804628",
4		- "mentions": [
5		- {
6		- "link": "@MpDd66GPXgN1+eMNrZInHkWq1THMurWwLdMx8BZ1ncw=.ed25519",
7		- "name": "Kieran"
	2 …	+ "key": "",
	3 …	+ "value": {
	4 …	+ "previous": "...",
	5 …	+ "author": "@MpDd66GPXgN1+eMNrZInHkWq1THMurWwLdMx8BZ1ncw=.ed25519",
	6 …	+ "sequence": "...",
	7 …	+ "timestamp": "...",
	8 …	+ "hash": "sha256",
	9 …	+ "content": {
	10 …	+ "type": "secret",
	11 …	+ "root": "%qHZCXd0spsGVlEvMrvkZHVtndgYNOHxZFiVZm1+tplA=.sha256",
	12 …	+ "response": "%rBpGhzSwvhToQJU7cTJfK+qQlMqT//GmLMaAQi0xGKc=.sha256",
	13 …	+ "secret": "80171f51d1f9cf6f6a8f3b08dee2ca5575cec57f32d02ed9f4435e940f1888637e1005e43232048fee13dd8804628",
	14 …	+ "trustee": {
	15 …	+ "link": "@NeB4q4Hy9IiMxs5L08oevEhivxW+/aDu/s/0SkNayi0=.ed25519",
	16 …	+ "name": "Dan Hassan"
	17 …	+ }
8	18 …	}
9		- ],
10		- "private": true
	19 …	+ }
11	20 …	}
	21 …	+
	22 …	+// Perhaps "response" is unnecessary?
	23 …	+
	24 …	+// A secret is in effect a private message between:
	25 …	+// - the author (the holder of the secret)
	26 …	+// - the trustee (the holder of the secret shard)
	27 …	+
	28 …	+// From the perspective of the person who has sharded their key,
	29 …	+// They're the sender of the secret, they can see this message...
	30 …	+// Makes sense.. can't be gotten around.. should it be anyway?
	31 …	+// Not sure if this is a problem... An issue for a compromised computer...?
	32 …	+
	33 …	+// Private messages can be decrypted and therefore the secret can be revealed
	34 …	+// at any point because the sharer still has the shards...
	35 …	+
	36 …	+// Encrypt with the public key of the trustee, they become the only one to can decrypt it
	37 …	+// Secret shard is no longer compromised to the author of the secret sharing process...

schemas/request.jsonView

schemas/trustees.jsonView
		@@ -1,0 +1,39 @@
	1 …	+{
	2 …	+ "key": "...",
	3 …	+ "value": {
	4 …	+ "previous": "...",
	5 …	+ "author": "@MpDd66GPXgN1+eMNrZInHkWq1THMurWwLdMx8BZ1ncw=.ed25519",
	6 …	+ "sequence": "...",
	7 …	+ "timestamp": "...",
	8 …	+ "hash": "sha256",
	9 …	+ "content": {
	10 …	+ "type": "secret_trustees",
	11 …	+ "root": "%qHZCXd0spsGVlEvMrvkZHVtndgYNOHxZFiVZm1+tplA=.sha256",
	12 …	+ "shared": true,
	13 …	+ "quorum": "2",
	14 …	+ "trustees": [
	15 …	+ {
	16 …	+ "link": "@NeB4q4Hy9IiMxs5L08oevEhivxW+/aDu/s/0SkNayi0=.ed25519",
	17 …	+ "name": "Dan Hassan"
	18 …	+ },
	19 …	+ {
	20 …	+ "link": "@ye+QM09iPcDJD6YvQYjoQc7sLF/IFhmNbEqgdzQo3lQ=.ed25519",
	21 …	+ "name": "mix"
	22 …	+ },
	23 …	+ {
	24 …	+ "link": "@DQ1HPdrTi6iUUlU22CRqZlEnbxWm6XjjdFQs+4fy+HY=.ed25519",
	25 …	+ "name": "Nikolai"
	26 …	+ }
	27 …	+ ]
	28 …	+ }
	29 …	+
	30 …	+ }
	31 …	+}
	32 …	+
	33 …	+// The original idea for this being here was to ensure a cutoff point from which to distinguish
	34 …	+// the real participants who received a secret and those who replied late.
	35 …	+// Also acts as a contract of sorts - contains the details for the @author who was included in the
	36 …	+// final secret sharing and how to reassemble
	37 …	+
	38 …	+// { shared: true } indicates whether other participants and quorum is visible to trustees.
	39 …	+// If it is, this information gets copied over into the secret

Built with git-ssb-web

kieran / horcrux-schemas-and-thoughts

Commit 77cc88e93406723a3e5a75c81ec5ed4225471eee

First sketch data structures

Files changed