This repository has been archived by the owner on May 14, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Meeting_notes_2021-04-29-arj-mix
193 lines (148 loc) · 4.55 KB
/
Meeting_notes_2021-04-29-arj-mix
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
<!--
SPDX-FileCopyrightText: 2021 Anders Rune Jensen
SPDX-License-Identifier: CC-BY-4.0
-->
# Fusion dance spec | 2021-04-29
## Last time
the dance:
- init
- invite
- consent
- entrust
- proof of key
### Questions from last time
- consent
- proof-of-key
- redirects
- attestation
- confirming / denying tombstones (adding meta data)
- confirming / denying redirects
- how we do authorship?
- how does it work
- is this a core part of the spec?
- signing?
- checking list of authors?
- e.g. @fusionA is an admin of this wiki article
- when I publish can I published "AS @fusionA"
## Agenda
- proof-of-key?
- redirects
homework reading!
- multi-device secure instant messaging
https://eprint.iacr.org/2021/498.pdf
## Dance step 5 : Proof of key?
Pro:
- publicly auditable that fusion successfully happened - can this peer decrypt messages
- makes it clear at what point a person for sure has access (to the identity)
- calms mix's paranoia
Con
- another step - complex
Could be optional
- one version of the dance is a "full dance" which has proof of key
- short dance could just not do it
Are there going to be 2 keys (one for signing, one for encrypting)
- arj: this paper references this
- one key for signing mutations (adding members)
- one key for reading DMs
- in paper this allowed for read-only accounts vs writing accounts (admin)
- mix: if we have 2 keys, how do you prove you have them
- signing : easy
- encrypting : .... zero knowledge proof
- arj: what even needs signing?
- mix: at the moment only the proof-of-key`
- mix: fuck it, lets use the same key, no-one else is doing any better
DECISION: we will use one key
arj: sounds good to me, lets keep it simple
mix: phew
message:
```js
{
type: fusion/proof-of-key,
entrustId: ConsentMsgId,
proof: sign(ConsentMsgId + 'fusion/proof-of-key')
tangles: {
identity: { root, previous }
}
}
```
NOTE: we use the consent message because:
- it's unique, and unique to the person consenting
- it's public content
- replay proof
Question:
- if we do signing this way, does this mean we need to sign in this same way if we ever use key for signing again?
## TBD list
- proof-of-key dance step?
- ~~seperate signing/ encrypting keys?~~
- ~~do we support add a fusion to a fusion identity?~~
- probably not in v1
## mix's keyboard layer misteps
count: 1
## Questions
1. if we do signing this way, does this mean we need to sign in this same way if we ever use key for signing again?
- (see proof of key)
2. what's the format of a fusion id
- @sdfasldkrf;skjdf;laksjdf=.fusion1 (proposed)
- @sdfasldkrf;skjdf;laksjdf=.ed25519 (current identities)
- %sdfasldkrf;skjdf;laksjdf=.cloaked (private group)
TFK - type, format, key
- identity: @
- "classic", goLang
- key
## Redirects
context:
- after a tombstone
- someone wants to say "new one over here"
```
{
type: 'fusion/redirect',
old: @sdfasldkrf;skjdf;laksjdf=.fusion1, // FusionId
new: @ldkrf;skssjdfjdf;laksdfa=.fusion1,
tombstoneMsg: MsgId // allows easy lookup of reason for redirect
// tombstone is a protected prop - we may want to tombstone a redirect!
// tangle?
}
```
Question: tangles?
- no identity tangle, this could be a standalone message
- make it all one mega tangle!
- or could be the root of the new tangle
```
{
type: 'fusion/tombstone',
reason: String // optional
}
```
arj: do we need the tombstone referenced?
- mix: I don't think so
Story:
- @fusionA is mentioned in a post
- I click through to their profile which is loaded by:
1. find the init with that FusionId
2. resolve the profile (tangle)
3. see it's tombstoned
4. go looking for redirects
5. attestation checks?
6. resolve new profile(s)
scenarios
- you've already done attestation and just follow your past decision
- no attestation exists, you're forced to decide ?
Story2:
- there's a disagreement with between devices
- one person tombstones, makes a new record and redirect
- another person disagrees, makes a new record and redirects somewhere else
- all new subrecord could be valid
Question: is it valid for there to be multiple continuations?
- we could force people to chose only one
- pro:
- easier
- consistent with the group be some coherance...
- maybe a split should be represented differently
_very_ rough final discussion
- multiple redirects??!!
- happy path vs pirate devices
- should we allow them
- different type: fusion/split
- for when you have an amicable fission
- how does a redirect message tangle
- how do we ensure "invalidated" redirects don't get used