-
Notifications
You must be signed in to change notification settings - Fork 1
/
Meeting_notes_2021-05-06-arj-mix
176 lines (131 loc) · 4.62 KB
/
Meeting_notes_2021-05-06-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
<!--
SPDX-FileCopyrightText: 2021 Anders Rune Jensen
SPDX-License-Identifier: CC-BY-4.0
-->
# Fusion Identity spec | 2021-06-05
## Last time closing points
_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
## Agenda?
- redirects (again!)
- attestation?
## Redirect
different possible valid states for redirect to be in:
1. there's no redirect
2. there's one redirect
a) you do agree
b) you don't agree
3. there are multiple redirects
a) there's one you agree with
b) you don't agree with any
Proposal: everyone who agrees with a redirect must attest it publicly
- if you're planning to use a redirect, you MUST attest the redirect you are following
- mix and arj YES!
Reasons:
- we think requiring attestation makes reasoning a lot easier (we're not guessing what redirect algorithm others are using)
- pins you decision for apps so it doesn't need to decide/ ask you again
- this is all about public fusion profiles....
arj: I'd like attestation to be required before you can invite new people to a new identity
- mix: why?
- arj: this makes it easier to follow, I think it would be confusing if it goes init, redirect, invite, attest...
- mix: I think that's based on some assumptions about how this is going to be tangled
```
A init
A
A
X
B init
B
B
```
Proposal: the old and the new identities are not tangled, they could be considered standalone
- mix: yes
- arj: yes, but is the redirect part of the old or new identity?
- mix: neither, redirecting is a different domain/ function than the identity
```
A init
A
A
X
B init
B
B
redirect
old: A-init
new: B-init
tangle: {
redirect: {
root: null,
previous: null
}
}
```
mix:
- A is tombstoned, you cannot extend a tombstoned record
- We need to have clarity on authorship permissions on this redirect?
- who is allowed to tombstone a redirect?
arj:
- having it independant means we don't introduce 2 sorts of identity
- "original identity"
- "redirected identity"
Proposal: redirect will be an independant tangle (from all identities)
- AGREE
arj: because there should be no causality between A + B, it shouldn't matter when you attest
Proposal: you can start using B before redirect/attest is "resolved"
- AGREE
Question: Should there only ever be a single redirect from A to something else?
## Attestation?
Redirect case:
A feed that was part of A attests that the redirect is good, or not?
Question: does all members of B attest the redirect?
- ONLY if you're planning on using the redirect
Question: can people outside of A and B attest a redirect?
- the state of a redirect has a interesting time dimension
- mix: I'd like to be able to do this because then I don't have to worry so much about assessing all redirects myself
Proposals:
- you can mention a tombstoned identity (but you might get a warning)
- you MUST NOT dm a tombstoned identity
- use the public key to encrypt to A
- ???
Question: what are we using redirects for?
- click a mention > profile (you want to see their current posts, maybe DM them)
- if you followed a redirect, then take an action like DM, what should the requirements be on that redirect?
- e.g. should all member feeds have to have attested?
- should you just get a warning
- you're in a private thread with someone, and one recp explodes.
- should you swap a recps, or trash the thread?
attestastion requirements
- state: confirm / reject / null
- want null because if you undo a confirm because you're "not sure" anymore, that's a different thing to "reject"
- be able to remove
- reason
Affirm attestastion
```
{
type: 'fusion/attestation',
target: %redirectId,
position: confirm|reject|null,
reason: String, // optional
tombstone: Tombstone // optional
tangle: {
attestation: { root: null, previous: null }
}
}
```
```
A ----- R ------- B
a1
a2
```
mix: I would tangle this so that it becomes a record for a particular autho-target pair
- allows mutation on:
- position
- reason
- tombstone
Attenstation togehter with redirect could be general concepts? Meaning the type is not fusion/.