@derec-alliance/nodejs 0.0.5 → 0.0.6
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +31 -11
- package/derec_descriptor.bin +0 -0
- package/derec_library.d.ts +112 -118
- package/derec_library.js +173 -160
- package/derec_library_bg.wasm +0 -0
- package/derec_library_bg.wasm.d.ts +39 -38
- package/index.d.ts +372 -164
- package/index.js +33 -3
- package/package.json +1 -1
- package/proto/contact.proto +15 -48
- package/proto/getshare.proto +4 -14
- package/proto/pair.proto +5 -29
- package/proto/prepair.proto +14 -39
- package/proto/secretidsversions.proto +4 -14
- package/proto/storeshare.proto +8 -39
- package/proto/unpair.proto +4 -14
- package/proto/updatechannelinfo.proto +16 -45
- package/proto/verify.proto +4 -14
package/index.js
CHANGED
|
@@ -6,12 +6,30 @@ const wasm = require("./derec_library.js");
|
|
|
6
6
|
const DeRecProtocol = wasm.DeRecProtocolWasm;
|
|
7
7
|
const DeRecProtocolBuilder = wasm.DeRecProtocolBuilder;
|
|
8
8
|
|
|
9
|
+
// A second `free()`, or one after `build()` consumed the builder, finds the
|
|
10
|
+
// handle already released; it returns instead of passing a null handle to the
|
|
11
|
+
// library, the same as .NET `Dispose` and Go `Close`.
|
|
12
|
+
function releaseOnce(Class) {
|
|
13
|
+
const release = Class.prototype.free;
|
|
14
|
+
Class.prototype.free = function free() {
|
|
15
|
+
if (this.__wbg_ptr !== 0) release.call(this);
|
|
16
|
+
};
|
|
17
|
+
Class.prototype[Symbol.dispose] = function dispose() {
|
|
18
|
+
this.free();
|
|
19
|
+
};
|
|
20
|
+
}
|
|
21
|
+
|
|
22
|
+
releaseOnce(DeRecProtocol);
|
|
23
|
+
releaseOnce(DeRecProtocolBuilder);
|
|
24
|
+
|
|
9
25
|
const SenderKind = Object.freeze({ Owner: 0, Helper: 1, ReplicaSource: 3, ReplicaDestination: 4 });
|
|
10
26
|
|
|
11
27
|
const ContactMode = Object.freeze({ InlineKeys: 0, HashedKeys: 1, NoKeys: 2 });
|
|
12
28
|
|
|
13
29
|
const FlowKind = Object.freeze({ Pairing: 0, Discovery: 1, ProtectSecret: 2, VerifyShares: 3, RecoverSecret: 4, Unpair: 5, UpdateChannelInfo: 6, ReplicaDiscovery: 7, UnpairReplica: 8 });
|
|
14
30
|
|
|
31
|
+
const StatusEnum = Object.freeze({ Ok: 0, Partial: 1, Fail: 2, SizeLimitExceeded: 3, TooFrequent: 4, UnknownSecretId: 5, UnknownShareVersion: 6, DecryptionFailed: 7, VerificationFailed: 8, FormatError: 9, Rejected: 10, IncompatibleParameterRange: 11, UnsupportedTransportProtocol: 12, VersionConflict: 13, ReplicaIdConflict: 14, RequestToClose: 99 });
|
|
32
|
+
|
|
15
33
|
const primitives = {
|
|
16
34
|
discovery: {
|
|
17
35
|
request: {
|
|
@@ -41,7 +59,10 @@ const primitives = {
|
|
|
41
59
|
produce_pre_pair: wasm.pairing_response_produce_pre_pair,
|
|
42
60
|
extract_pre_pair: wasm.pairing_response_extract_pre_pair,
|
|
43
61
|
process_pre_pair: wasm.pairing_response_process_pre_pair,
|
|
62
|
+
produce_pre_pair_no_keys: wasm.pairing_response_produce_pre_pair_no_keys,
|
|
63
|
+
process_pre_pair_no_keys: wasm.pairing_response_process_pre_pair_no_keys,
|
|
44
64
|
},
|
|
65
|
+
fingerprint: wasm.pairing_fingerprint,
|
|
45
66
|
},
|
|
46
67
|
recovery: {
|
|
47
68
|
request: {
|
|
@@ -121,9 +142,15 @@ function channelFilterMatches(filter, id, status, role) {
|
|
|
121
142
|
|
|
122
143
|
function advertisedEndpoints(message) {
|
|
123
144
|
if (!message) return [];
|
|
124
|
-
|
|
125
|
-
|
|
126
|
-
|
|
145
|
+
return message.supported_transports ?? [];
|
|
146
|
+
}
|
|
147
|
+
|
|
148
|
+
function protocol_version() {
|
|
149
|
+
return wasm.protocol_version();
|
|
150
|
+
}
|
|
151
|
+
|
|
152
|
+
function generate_replica_id() {
|
|
153
|
+
return wasm.generate_replica_id();
|
|
127
154
|
}
|
|
128
155
|
|
|
129
156
|
function sequentialFailover(dialer) {
|
|
@@ -161,6 +188,8 @@ module.exports = {
|
|
|
161
188
|
primitives,
|
|
162
189
|
channelFilterMatches,
|
|
163
190
|
advertisedEndpoints,
|
|
191
|
+
protocol_version,
|
|
192
|
+
generate_replica_id,
|
|
164
193
|
sequentialFailover,
|
|
165
194
|
singleEndpointTransport,
|
|
166
195
|
envelope,
|
|
@@ -169,4 +198,5 @@ module.exports = {
|
|
|
169
198
|
SenderKind,
|
|
170
199
|
ContactMode,
|
|
171
200
|
FlowKind,
|
|
201
|
+
StatusEnum,
|
|
172
202
|
};
|
package/package.json
CHANGED
package/proto/contact.proto
CHANGED
|
@@ -68,13 +68,13 @@ package org.derecalliance.derec.protobuf;
|
|
|
68
68
|
// against the hash before sending `PairRequestMessage`. The hash binding
|
|
69
69
|
// gives the OOB-shared contact the same MITM resistance as inline-keys
|
|
70
70
|
// mode despite the keys traveling over the (unauthenticated) transport.
|
|
71
|
-
// Because the `PrePair*` messages are plaintext, the `
|
|
71
|
+
// Because the `PrePair*` messages are plaintext, the `supportedTransports`
|
|
72
72
|
// carried in this mode MUST be ephemeral — see the security note on
|
|
73
73
|
// `PrePairRequestMessage` for the required ephemeral-then-swap discipline.
|
|
74
74
|
//
|
|
75
75
|
// - `NO_KEYS`: all of `mlkemEncapsulationKey`, `eciesPublicKey`, and
|
|
76
76
|
// `contactBindingHash` are absent. The contact carries only
|
|
77
|
-
// `channelId`, `nonce`, and `
|
|
77
|
+
// `channelId`, `nonce`, and `supportedTransports` — small enough to be
|
|
78
78
|
// hand-typed or dictated over the phone. There is no cryptographic
|
|
79
79
|
// binding: the recipient's `PrePairRequest` triggers on-the-fly key
|
|
80
80
|
// generation on the contact creator, and the returned keys are used
|
|
@@ -112,7 +112,7 @@ enum ContactMode {
|
|
|
112
112
|
// `PrePairRequest` / `PrePairResponse` and verified against the hash.
|
|
113
113
|
HASHED_KEYS = 1;
|
|
114
114
|
// No key material and no hash are inlined. The contact carries only
|
|
115
|
-
// `channelId`, `nonce`, and `
|
|
115
|
+
// `channelId`, `nonce`, and `supportedTransports`; the contact creator
|
|
116
116
|
// generates key material on the fly when the corresponding
|
|
117
117
|
// `PrePairRequest` arrives. Only appropriate when the out-of-band
|
|
118
118
|
// delivery channel is fully trusted, and the channel stays unusable
|
|
@@ -190,37 +190,9 @@ message ContactMessage {
|
|
|
190
190
|
// out-of-band authentication has taken place.
|
|
191
191
|
uint64 nonce = 6;
|
|
192
192
|
|
|
193
|
-
//
|
|
194
|
-
|
|
195
|
-
|
|
196
|
-
//
|
|
197
|
-
// - the endpoint to which the first protocol message should be sent
|
|
198
|
-
// - the transport protocol that determines how that endpoint is interpreted
|
|
199
|
-
// and used
|
|
200
|
-
//
|
|
201
|
-
// The initiating party uses this field to deliver the initial pairing
|
|
202
|
-
// request. Subsequent protocol exchanges may continue using the same
|
|
203
|
-
// transport information or updated transport details, depending on the
|
|
204
|
-
// protocol and application behavior.
|
|
205
|
-
//
|
|
206
|
-
// Deprecated: superseded by `supportedTransports`, which carries every
|
|
207
|
-
// endpoint rather than one.
|
|
208
|
-
//
|
|
209
|
-
// **Reading this field directly is now incorrect.** Its meaning narrowed
|
|
210
|
-
// from "the endpoint" to "one entry of a list, and possibly absent": a
|
|
211
|
-
// creator that has moved past this field advertises only
|
|
212
|
-
// `supportedTransports`. A reader that was correct before this release is
|
|
213
|
-
// a bug now — it rejects, or fails to reach, a peer that is offering it a
|
|
214
|
-
// perfectly good endpoint. Resolve both spellings instead of reading
|
|
215
|
-
// either: `advertised_endpoints()` (Rust and TypeScript),
|
|
216
|
-
// `AdvertisedEndpoints()` (Go), `AdvertisedEndpoints()` (.NET).
|
|
217
|
-
//
|
|
218
|
-
// Senders still populate it: a sender that sets `supportedTransports`
|
|
219
|
-
// MUST also set this to a single best-compatibility choice, so
|
|
220
|
-
// implementations predating the list still pair.
|
|
221
|
-
//
|
|
222
|
-
// **Scheduled for removal in v0.0.5.**
|
|
223
|
-
TransportProtocol transportProtocol = 7 [deprecated = true];
|
|
193
|
+
// Formerly the singular `transportProtocol`, superseded by `supportedTransports`.
|
|
194
|
+
reserved 7;
|
|
195
|
+
reserved "transportProtocol";
|
|
224
196
|
|
|
225
197
|
// Timestamp indicating when the sender created this message.
|
|
226
198
|
//
|
|
@@ -243,22 +215,17 @@ message ContactMessage {
|
|
|
243
215
|
// preference rather than the sender's. The order here expresses
|
|
244
216
|
// availability, not a ranking the recipient must honor.
|
|
245
217
|
//
|
|
246
|
-
//
|
|
247
|
-
//
|
|
248
|
-
// Absent means "only `transportProtocol` is offered", which is how every
|
|
249
|
-
// implementation predating this field behaves. A sender populating this
|
|
250
|
-
// list MUST also set `transportProtocol` to a single best-compatibility
|
|
251
|
-
// choice so those implementations still pair.
|
|
218
|
+
// A contact MUST carry at least one entry: it is the only way the
|
|
219
|
+
// recipient learns where to send its first message.
|
|
252
220
|
//
|
|
253
221
|
// # Security
|
|
254
222
|
//
|
|
255
|
-
// `contactBindingHash` does not cover this field
|
|
256
|
-
//
|
|
257
|
-
//
|
|
258
|
-
//
|
|
259
|
-
//
|
|
260
|
-
//
|
|
261
|
-
//
|
|
262
|
-
// confidentiality or authenticity.
|
|
223
|
+
// `contactBindingHash` does not cover this field. An attacker able to
|
|
224
|
+
// rewrite an out-of-band contact can therefore remove entries. Removing
|
|
225
|
+
// the secure ones leaves only plaintext, which the recipient's transport
|
|
226
|
+
// policy refuses unless plaintext has been explicitly opted into. DeRec
|
|
227
|
+
// messages are signed and encrypted at the application layer on every
|
|
228
|
+
// transport, so substituting one secure transport for another is not a
|
|
229
|
+
// loss of confidentiality or authenticity.
|
|
263
230
|
repeated TransportProtocol supportedTransports = 9;
|
|
264
231
|
}
|
package/proto/getshare.proto
CHANGED
|
@@ -70,24 +70,14 @@ message GetShareRequestMessage {
|
|
|
70
70
|
// - timeout handling
|
|
71
71
|
google.protobuf.Timestamp timestamp = 3;
|
|
72
72
|
|
|
73
|
-
//
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
//
|
|
77
|
-
// See `StoreShareRequestMessage.replyTo` for full semantics.
|
|
78
|
-
//
|
|
79
|
-
// Superseded by `replyToTransports`, which carries every endpoint rather
|
|
80
|
-
// than one. Kept, and still populated with the list's first entry, so
|
|
81
|
-
// implementations predating that field still receive a reply.
|
|
82
|
-
// **Scheduled for removal in v0.0.5.** Reading this field directly is now
|
|
83
|
-
// incorrect — resolve it against `replyToTransports`.
|
|
84
|
-
optional TransportProtocol replyTo = 4 [deprecated = true];
|
|
73
|
+
// Formerly the singular `replyTo`, superseded by `replyToTransports`.
|
|
74
|
+
reserved 4;
|
|
75
|
+
reserved "replyTo";
|
|
85
76
|
|
|
86
77
|
// Every ephemeral endpoint the requester wants this exchange's response
|
|
87
78
|
// delivered to, in its own preference order.
|
|
88
79
|
//
|
|
89
|
-
// See `StoreShareRequestMessage.replyToTransports` for full semantics
|
|
90
|
-
// including why this is a new tag rather than a widened `replyTo`.
|
|
80
|
+
// See `StoreShareRequestMessage.replyToTransports` for full semantics.
|
|
91
81
|
repeated TransportProtocol replyToTransports = 6;
|
|
92
82
|
|
|
93
83
|
// Identity of the replica-group member this message concerns.
|
package/proto/pair.proto
CHANGED
|
@@ -139,33 +139,9 @@ message PairRequestMessage {
|
|
|
139
139
|
// whether pairing is possible and which parameters to use.
|
|
140
140
|
ParameterRange parameterRange = 7;
|
|
141
141
|
|
|
142
|
-
//
|
|
143
|
-
|
|
144
|
-
|
|
145
|
-
//
|
|
146
|
-
// - the endpoint where the initiator can receive messages
|
|
147
|
-
// - the protocol required to deliver those messages
|
|
148
|
-
//
|
|
149
|
-
// After pairing, the responder uses this information to send responses
|
|
150
|
-
// and all subsequent protocol messages to the initiator.
|
|
151
|
-
// Deprecated: superseded by `supportedTransports`, which carries every
|
|
152
|
-
// endpoint rather than one.
|
|
153
|
-
//
|
|
154
|
-
// **Reading this field directly is now incorrect.** Its meaning narrowed
|
|
155
|
-
// from "the endpoint" to "one entry of a list, and possibly absent": an
|
|
156
|
-
// initiator that has moved past this field advertises only
|
|
157
|
-
// `supportedTransports`. A reader that was correct before this release is
|
|
158
|
-
// a bug now — it rejects, or fails to reach, a peer that is offering it a
|
|
159
|
-
// perfectly good endpoint. Resolve both spellings instead of reading
|
|
160
|
-
// either: `advertised_endpoints()` (Rust and TypeScript),
|
|
161
|
-
// `AdvertisedEndpoints()` (Go), `AdvertisedEndpoints()` (.NET).
|
|
162
|
-
//
|
|
163
|
-
// Senders still populate it: a sender that sets `supportedTransports`
|
|
164
|
-
// MUST also set this to a single best-compatibility choice, so
|
|
165
|
-
// implementations predating the list still pair.
|
|
166
|
-
//
|
|
167
|
-
// **Scheduled for removal in v0.0.5.**
|
|
168
|
-
TransportProtocol transportProtocol = 8 [deprecated = true];
|
|
142
|
+
// Formerly the singular `transportProtocol`, superseded by `supportedTransports`.
|
|
143
|
+
reserved 8;
|
|
144
|
+
reserved "transportProtocol";
|
|
169
145
|
|
|
170
146
|
// Timestamp indicating when this message was created.
|
|
171
147
|
//
|
|
@@ -177,8 +153,8 @@ message PairRequestMessage {
|
|
|
177
153
|
// initiator's own preference order.
|
|
178
154
|
//
|
|
179
155
|
// Same semantics as `ContactMessage.supportedTransports`: the responder
|
|
180
|
-
// selects by its own preference, and
|
|
181
|
-
//
|
|
156
|
+
// selects by its own preference, and the list MUST carry at least one
|
|
157
|
+
// entry.
|
|
182
158
|
repeated TransportProtocol supportedTransports = 10;
|
|
183
159
|
}
|
|
184
160
|
|
package/proto/prepair.proto
CHANGED
|
@@ -41,17 +41,17 @@ package org.derecalliance.derec.protobuf;
|
|
|
41
41
|
//
|
|
42
42
|
// # Security: transport endpoint is observable
|
|
43
43
|
//
|
|
44
|
-
// Because the envelope is plaintext, the
|
|
45
|
-
// `PrePairRequestMessage`
|
|
46
|
-
//
|
|
47
|
-
//
|
|
48
|
-
//
|
|
44
|
+
// Because the envelope is plaintext, the endpoints carried in
|
|
45
|
+
// `PrePairRequestMessage` are visible to any passive observer on the
|
|
46
|
+
// network path. The same applies to the `supportedTransports` carried in
|
|
47
|
+
// the `HASHED_KEYS`-mode `ContactMessage` itself if its out-of-band channel
|
|
48
|
+
// can be observed.
|
|
49
49
|
//
|
|
50
50
|
// The protocol relies on this contract from the application to preserve
|
|
51
51
|
// the security guarantees of `HASHED_KEYS` mode:
|
|
52
52
|
//
|
|
53
|
-
// - The
|
|
54
|
-
// `ContactMessage` and
|
|
53
|
+
// - The endpoints used during pairing (those advertised in the
|
|
54
|
+
// `ContactMessage` and in `PrePairRequestMessage`) MUST be
|
|
55
55
|
// ephemeral and short-lived — bound to the pairing attempt, not to the
|
|
56
56
|
// long-term identity of either peer.
|
|
57
57
|
// - Once pairing completes, the application MUST swap to a long-term
|
|
@@ -70,27 +70,9 @@ message PrePairRequestMessage {
|
|
|
70
70
|
// and the receiver MUST refuse to serve the keys.
|
|
71
71
|
uint64 nonce = 1;
|
|
72
72
|
|
|
73
|
-
//
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
// Deprecated: superseded by `supportedTransports`, which carries every
|
|
77
|
-
// endpoint rather than one.
|
|
78
|
-
//
|
|
79
|
-
// **Reading this field directly is now incorrect.** Its meaning narrowed
|
|
80
|
-
// from "the endpoint" to "one entry of a list, and possibly absent": a
|
|
81
|
-
// sender that has moved past this field advertises only
|
|
82
|
-
// `supportedTransports`. A reader that was correct before this release is
|
|
83
|
-
// a bug now — it rejects, or fails to reply to, a peer that is offering it
|
|
84
|
-
// a perfectly good endpoint. Resolve both spellings instead of reading
|
|
85
|
-
// either: `advertised_endpoints()` (Rust and TypeScript),
|
|
86
|
-
// `AdvertisedEndpoints()` (Go), `AdvertisedEndpoints()` (.NET).
|
|
87
|
-
//
|
|
88
|
-
// Senders still populate it: a sender that sets `supportedTransports`
|
|
89
|
-
// MUST also set this to a single best-compatibility choice, so
|
|
90
|
-
// implementations predating the list still receive a reply.
|
|
91
|
-
//
|
|
92
|
-
// **Scheduled for removal in v0.0.5.**
|
|
93
|
-
TransportProtocol transportProtocol = 2 [deprecated = true];
|
|
73
|
+
// Formerly the singular `transportProtocol`, superseded by `supportedTransports`.
|
|
74
|
+
reserved 2;
|
|
75
|
+
reserved "transportProtocol";
|
|
94
76
|
|
|
95
77
|
// Timestamp indicating when this message was created.
|
|
96
78
|
//
|
|
@@ -111,22 +93,15 @@ message PrePairRequestMessage {
|
|
|
111
93
|
// preference rather than the sender's. The order here expresses
|
|
112
94
|
// availability, not a ranking the recipient must honor.
|
|
113
95
|
//
|
|
114
|
-
//
|
|
115
|
-
//
|
|
116
|
-
// Absent means "only `transportProtocol` is offered", which is how every
|
|
117
|
-
// implementation predating this field behaves. A sender populating this
|
|
118
|
-
// list MUST also set `transportProtocol` to a single best-compatibility
|
|
119
|
-
// choice so those implementations still reply.
|
|
120
|
-
//
|
|
121
|
-
// At least one of the two MUST be present: a request naming no endpoint
|
|
96
|
+
// The list MUST carry at least one entry: a request naming no endpoint
|
|
122
97
|
// gives the recipient nowhere to send the response.
|
|
123
98
|
//
|
|
124
99
|
// # Security
|
|
125
100
|
//
|
|
126
101
|
// PrePair traffic is plaintext — no shared key exists yet — so these
|
|
127
|
-
// endpoints are visible to a passive observer
|
|
128
|
-
//
|
|
129
|
-
//
|
|
102
|
+
// endpoints are visible to a passive observer. The recipient's transport
|
|
103
|
+
// policy still refuses plaintext entries unless plaintext has been opted
|
|
104
|
+
// into.
|
|
130
105
|
repeated TransportProtocol supportedTransports = 4;
|
|
131
106
|
}
|
|
132
107
|
|
|
@@ -68,24 +68,14 @@ message GetSecretIdsVersionsRequestMessage {
|
|
|
68
68
|
// - timeout handling
|
|
69
69
|
google.protobuf.Timestamp timestamp = 1;
|
|
70
70
|
|
|
71
|
-
//
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
//
|
|
75
|
-
// See `StoreShareRequestMessage.replyTo` for full semantics.
|
|
76
|
-
//
|
|
77
|
-
// Superseded by `replyToTransports`, which carries every endpoint rather
|
|
78
|
-
// than one. Kept, and still populated with the list's first entry, so
|
|
79
|
-
// implementations predating that field still receive a reply.
|
|
80
|
-
// **Scheduled for removal in v0.0.5.** Reading this field directly is now
|
|
81
|
-
// incorrect — resolve it against `replyToTransports`.
|
|
82
|
-
optional TransportProtocol replyTo = 2 [deprecated = true];
|
|
71
|
+
// Formerly the singular `replyTo`, superseded by `replyToTransports`.
|
|
72
|
+
reserved 2;
|
|
73
|
+
reserved "replyTo";
|
|
83
74
|
|
|
84
75
|
// Every ephemeral endpoint the requester wants this exchange's response
|
|
85
76
|
// delivered to, in its own preference order.
|
|
86
77
|
//
|
|
87
|
-
// See `StoreShareRequestMessage.replyToTransports` for full semantics
|
|
88
|
-
// including why this is a new tag rather than a widened `replyTo`.
|
|
78
|
+
// See `StoreShareRequestMessage.replyToTransports` for full semantics.
|
|
89
79
|
repeated TransportProtocol replyToTransports = 4;
|
|
90
80
|
|
|
91
81
|
// Identity of the replica-group member this message concerns.
|
package/proto/storeshare.proto
CHANGED
|
@@ -131,10 +131,13 @@ message StoreShareRequestMessage {
|
|
|
131
131
|
// Used for observability, replay detection, and timeout handling.
|
|
132
132
|
google.protobuf.Timestamp timestamp = 7;
|
|
133
133
|
|
|
134
|
-
//
|
|
135
|
-
|
|
136
|
-
|
|
137
|
-
|
|
134
|
+
// Formerly the singular `replyTo`, superseded by `replyToTransports`.
|
|
135
|
+
reserved 8;
|
|
136
|
+
reserved "replyTo";
|
|
137
|
+
|
|
138
|
+
// Every ephemeral endpoint the requester wants this exchange's response
|
|
139
|
+
// delivered to, in its own preference order, overriding the channel's
|
|
140
|
+
// stored peer endpoints for this round-trip only.
|
|
138
141
|
//
|
|
139
142
|
// # When to use
|
|
140
143
|
//
|
|
@@ -146,45 +149,11 @@ message StoreShareRequestMessage {
|
|
|
146
149
|
//
|
|
147
150
|
// # Semantics
|
|
148
151
|
//
|
|
149
|
-
// -
|
|
152
|
+
// - Empty (the default): the responder routes to the endpoints stored on
|
|
150
153
|
// its `Channel` record for this `channelId`.
|
|
151
|
-
// - Present: the responder routes this exchange's response here, and
|
|
152
|
-
// leaves the stored endpoints unchanged.
|
|
153
|
-
//
|
|
154
|
-
// Superseded by `replyToTransports`, which carries every endpoint rather
|
|
155
|
-
// than one. Kept, and still populated with the list's first entry, so
|
|
156
|
-
// implementations predating that field still receive a reply.
|
|
157
|
-
// **Scheduled for removal in v0.0.5.**
|
|
158
|
-
//
|
|
159
|
-
// **Reading this field directly is now incorrect** for the same reason it
|
|
160
|
-
// is on `transportProtocol`: it is one entry of a list and may be absent.
|
|
161
|
-
// Resolve it against `replyToTransports` instead.
|
|
162
|
-
optional TransportProtocol replyTo = 8 [deprecated = true];
|
|
163
|
-
|
|
164
|
-
// Every ephemeral endpoint the requester wants this exchange's response
|
|
165
|
-
// delivered to, in its own preference order.
|
|
166
|
-
//
|
|
167
|
-
// # Semantics
|
|
168
|
-
//
|
|
169
|
-
// - Empty, and `replyTo` absent: the responder routes to the endpoints
|
|
170
|
-
// stored on its `Channel` record for this `channelId`.
|
|
171
|
-
// - Empty, `replyTo` present: that one endpoint, which is how every
|
|
172
|
-
// implementation predating this field asks.
|
|
173
154
|
// - Non-empty: the responder routes the response to any one of these, in
|
|
174
155
|
// the order given, and leaves the stored endpoints unchanged. Delivery
|
|
175
156
|
// to any one is success.
|
|
176
|
-
//
|
|
177
|
-
// # Why this is a new field rather than a wider `replyTo`
|
|
178
|
-
//
|
|
179
|
-
// `replyTo` was singular through 0.0.2. Re-tagging it `repeated` would
|
|
180
|
-
// have been wire-compatible in the read direction only: protobuf merges a
|
|
181
|
-
// repeated submessage into a singular reader field-by-field, so a 0.0.2
|
|
182
|
-
// peer decoding a multi-entry list sees the **last** entry, while the
|
|
183
|
-
// first entry is what every other compatibility rule in this release
|
|
184
|
-
// designates as the legacy-readable one. One list cannot be ordered to
|
|
185
|
-
// satisfy both. A new tag lets the singular field keep meaning exactly
|
|
186
|
-
// what it did — the same shape `supportedTransports` (contact.proto tag 9)
|
|
187
|
-
// uses beside `transportProtocol` (tag 7).
|
|
188
157
|
repeated TransportProtocol replyToTransports = 10;
|
|
189
158
|
|
|
190
159
|
// Identity of the replica that authored this update.
|
package/proto/unpair.proto
CHANGED
|
@@ -68,24 +68,14 @@ message UnpairRequestMessage {
|
|
|
68
68
|
// - timeout handling
|
|
69
69
|
google.protobuf.Timestamp timestamp = 2;
|
|
70
70
|
|
|
71
|
-
//
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
//
|
|
75
|
-
// See `StoreShareRequestMessage.replyTo` for full semantics.
|
|
76
|
-
//
|
|
77
|
-
// Superseded by `replyToTransports`, which carries every endpoint rather
|
|
78
|
-
// than one. Kept, and still populated with the list's first entry, so
|
|
79
|
-
// implementations predating that field still receive a reply.
|
|
80
|
-
// **Scheduled for removal in v0.0.5.** Reading this field directly is now
|
|
81
|
-
// incorrect — resolve it against `replyToTransports`.
|
|
82
|
-
optional TransportProtocol replyTo = 3 [deprecated = true];
|
|
71
|
+
// Formerly the singular `replyTo`, superseded by `replyToTransports`.
|
|
72
|
+
reserved 3;
|
|
73
|
+
reserved "replyTo";
|
|
83
74
|
|
|
84
75
|
// Every ephemeral endpoint the requester wants this exchange's response
|
|
85
76
|
// delivered to, in its own preference order.
|
|
86
77
|
//
|
|
87
|
-
// See `StoreShareRequestMessage.replyToTransports` for full semantics
|
|
88
|
-
// including why this is a new tag rather than a widened `replyTo`.
|
|
78
|
+
// See `StoreShareRequestMessage.replyToTransports` for full semantics.
|
|
89
79
|
repeated TransportProtocol replyToTransports = 5;
|
|
90
80
|
|
|
91
81
|
// Identity of the replica-group member that initiated this unpair.
|
|
@@ -17,7 +17,7 @@ package org.derecalliance.derec.protobuf;
|
|
|
17
17
|
//
|
|
18
18
|
// # Context
|
|
19
19
|
//
|
|
20
|
-
// Both `communication_info` and
|
|
20
|
+
// Both `communication_info` and the transport endpoints are exchanged at pairing
|
|
21
21
|
// time only. This message lets either party (Owner or Helper) propagate
|
|
22
22
|
// post-pairing changes without re-pairing.
|
|
23
23
|
//
|
|
@@ -31,16 +31,16 @@ package org.derecalliance.derec.protobuf;
|
|
|
31
31
|
// stored map with the supplied one." Updates, additions, and deletions
|
|
32
32
|
// are all expressed by the difference between the receiver's current map
|
|
33
33
|
// and the supplied one.
|
|
34
|
-
// - `
|
|
35
|
-
// stored for the sender."
|
|
36
|
-
//
|
|
37
|
-
// channel to the new
|
|
34
|
+
// - `supported_transports` empty means "do not modify the transport
|
|
35
|
+
// endpoints stored for the sender." Non-empty means "the sender's transport
|
|
36
|
+
// endpoints are now these." The receiver MUST route subsequent messages on
|
|
37
|
+
// this channel to the new endpoints, including the
|
|
38
38
|
// UpdateChannelInfoResponseMessage for this request.
|
|
39
39
|
//
|
|
40
40
|
// # Endpoint changeover
|
|
41
41
|
//
|
|
42
|
-
// When `
|
|
43
|
-
// the new
|
|
42
|
+
// When `supported_transports` is updated, the receiver sends its response to
|
|
43
|
+
// the new endpoints. The sender's application is therefore responsible for
|
|
44
44
|
// ensuring the new endpoint is reachable BEFORE this request is issued, and
|
|
45
45
|
// for keeping the old endpoint operational long enough for in-flight
|
|
46
46
|
// messages from other peers (and any concurrent operations) to drain.
|
|
@@ -52,49 +52,20 @@ message UpdateChannelInfoRequestMessage {
|
|
|
52
52
|
// stored map for this channel. Absence leaves it untouched.
|
|
53
53
|
optional CommunicationInfo communicationInfo = 1;
|
|
54
54
|
|
|
55
|
-
//
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
// the response to this new endpoint.
|
|
59
|
-
//
|
|
60
|
-
// Deprecated: superseded by `supportedTransports`, which carries every
|
|
61
|
-
// endpoint rather than one.
|
|
62
|
-
//
|
|
63
|
-
// **Reading this field directly is now incorrect.** Its meaning narrowed
|
|
64
|
-
// from "the endpoint" to "one entry of a list, and possibly absent": a
|
|
65
|
-
// sender that has moved past this field announces only
|
|
66
|
-
// `supportedTransports`. A reader that was correct before this release is
|
|
67
|
-
// a bug now — it records the wrong address, or none, for a peer that
|
|
68
|
-
// announced a perfectly good one. Resolve both spellings instead of
|
|
69
|
-
// reading either: `advertised_endpoints()` (Rust and TypeScript),
|
|
70
|
-
// `AdvertisedEndpoints()` (Go), `AdvertisedEndpoints()` (.NET).
|
|
71
|
-
//
|
|
72
|
-
// Senders still populate it: a sender that sets `supportedTransports`
|
|
73
|
-
// MUST also set this to a single best-compatibility choice, so
|
|
74
|
-
// implementations predating the list still learn the new address.
|
|
75
|
-
//
|
|
76
|
-
// **Scheduled for removal in v0.0.5.**
|
|
77
|
-
optional TransportProtocol transportProtocol = 2 [deprecated = true];
|
|
55
|
+
// Formerly the singular `transportProtocol`, superseded by `supportedTransports`.
|
|
56
|
+
reserved 2;
|
|
57
|
+
reserved "transportProtocol";
|
|
78
58
|
|
|
79
59
|
// Every transport endpoint the sender can now be reached on, in its own
|
|
80
60
|
// preference order, replacing the receiver's stored set for this channel.
|
|
81
61
|
//
|
|
82
62
|
// # Semantics
|
|
83
63
|
//
|
|
84
|
-
// - Empty
|
|
85
|
-
//
|
|
86
|
-
// nothing about transports.
|
|
64
|
+
// - Empty: the sender's endpoints are left unchanged. An update that
|
|
65
|
+
// changes only `communicationInfo` says nothing about transports.
|
|
87
66
|
// - Non-empty: replaces the stored set outright. Unlike a request's
|
|
88
|
-
// `
|
|
89
|
-
// moved.
|
|
90
|
-
//
|
|
91
|
-
// # Compatibility
|
|
92
|
-
//
|
|
93
|
-
// Empty with `transportProtocol` present means "only that one endpoint is
|
|
94
|
-
// offered", which is how every implementation predating this field
|
|
95
|
-
// behaves. A sender populating this list MUST also set
|
|
96
|
-
// `transportProtocol` to a single best-compatibility choice so those
|
|
97
|
-
// implementations still learn the new address.
|
|
67
|
+
// `replyToTransports`, this **is** persisted — it is how a peer
|
|
68
|
+
// announces it has moved.
|
|
98
69
|
repeated TransportProtocol supportedTransports = 4;
|
|
99
70
|
|
|
100
71
|
// Timestamp indicating when this message was created.
|
|
@@ -112,8 +83,8 @@ message UpdateChannelInfoRequestMessage {
|
|
|
112
83
|
// On success (`result.status == OK`):
|
|
113
84
|
//
|
|
114
85
|
// - the receiver has persisted the supplied updates
|
|
115
|
-
// - subsequent messages from the receiver MUST use the new
|
|
116
|
-
// `
|
|
86
|
+
// - subsequent messages from the receiver MUST use the new endpoints, if
|
|
87
|
+
// `supported_transports` was updated
|
|
117
88
|
//
|
|
118
89
|
// On failure:
|
|
119
90
|
//
|
package/proto/verify.proto
CHANGED
|
@@ -74,24 +74,14 @@ message VerifyShareRequestMessage {
|
|
|
74
74
|
// - timeout handling
|
|
75
75
|
google.protobuf.Timestamp timestamp = 4;
|
|
76
76
|
|
|
77
|
-
//
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
//
|
|
81
|
-
// See `StoreShareRequestMessage.replyTo` for full semantics.
|
|
82
|
-
//
|
|
83
|
-
// Superseded by `replyToTransports`, which carries every endpoint rather
|
|
84
|
-
// than one. Kept, and still populated with the list's first entry, so
|
|
85
|
-
// implementations predating that field still receive a reply.
|
|
86
|
-
// **Scheduled for removal in v0.0.5.** Reading this field directly is now
|
|
87
|
-
// incorrect — resolve it against `replyToTransports`.
|
|
88
|
-
optional TransportProtocol replyTo = 5 [deprecated = true];
|
|
77
|
+
// Formerly the singular `replyTo`, superseded by `replyToTransports`.
|
|
78
|
+
reserved 5;
|
|
79
|
+
reserved "replyTo";
|
|
89
80
|
|
|
90
81
|
// Every ephemeral endpoint the requester wants this exchange's response
|
|
91
82
|
// delivered to, in its own preference order.
|
|
92
83
|
//
|
|
93
|
-
// See `StoreShareRequestMessage.replyToTransports` for full semantics
|
|
94
|
-
// including why this is a new tag rather than a widened `replyTo`.
|
|
84
|
+
// See `StoreShareRequestMessage.replyToTransports` for full semantics.
|
|
95
85
|
repeated TransportProtocol replyToTransports = 6;
|
|
96
86
|
}
|
|
97
87
|
|