You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have to document legacy signature, because it is the only reason for
copying 'data' fields into the main protobuf.
Added section about backward compatibility so our approach is more clear.
// deserialized copies of data[validityType] and data[validity]
@@ -216,6 +217,24 @@ Records over the limit MAY be ignored. Handling records larger than the
216
217
limit is not recommended so as to keep compatibility with implementations and
217
218
transports that follow this specification.
218
219
220
+
### Backward Compatibility
221
+
222
+
Implementations that want to interop with the public IPFS swarm MUST maintain
223
+
backward compatibility for legacy consumers of IPNS records:
224
+
225
+
226
+
- A legacy publisher MUST always be able to update to the latest implementation
227
+
of this specification without breaking record resolution for legacy consumers.
228
+
- A legacy consumer MUST always be able to resolve IPNS name, even when publisher
229
+
updated to the latest implementation of this specification.
230
+
231
+
This means, for example, that changes made to the `IpnsEntry` protobuf, or
232
+
validation logic should always be additive.
233
+
234
+
Future changes to this spec should include design decisions that allow legacy
235
+
nodes to gracefully ignore new fields and verify compatible records using
236
+
legacy logic.
237
+
219
238
## Protocol
220
239
221
240
### Overview
@@ -243,8 +262,7 @@ Finally, the network nodes may also republish their records, so that the records
243
262
244
263
### Record Creation
245
264
246
-
IPNS record MUST be serialized as `IpnsEntry` protobuf and `IpfsEntry.data` MUST be signed using the private key.
247
-
265
+
IPNS record MUST be serialized as `IpnsEntry` protobuf, and `IpfsEntry.data` MUST be signed using the private key.
248
266
Creating a new IPNS record MUST follow the below steps:
249
267
250
268
1. Create `IpnsEntry` and set `value`, `validity`, `validityType`, `sequence`, and `ttl`
@@ -256,9 +274,13 @@ Creating a new IPNS record MUST follow the below steps:
256
274
- The order of fields impacts signature verification. If you are using an alternative CBOR implementation, make sure the CBOR field order follows [RFC7049](https://www.rfc-editor.org/rfc/rfc7049) sorting rules: length and then bytewise. The order of fields impacts signature verification.
257
275
4. If your public key can't be inlined inside the IPNS Name, include a serialized copy in `IpnsEntry.pubKey`
258
276
- This step SHOULD be skipped for Ed25519, and any other key types that are inlined inside of [IPNS Name](#ipns-name) itself.
259
-
6. Create bytes for signing by concatenating `ipns-signature:` prefix (bytes in hex: `69706e732d7369676e61747572653a`) with raw CBOR bytes from `IpnsEntry.data`
260
-
7. Sign concatenated bytes from the previous step using the private key, and store the signature in `IpnsEntry.signatureV2`
261
-
8. Confirm that the serialized `IpnsEntry` bytes sum to less than or equal to [the size limit](#record-size-limit).
277
+
5. Create `IpnsEntry.signatureV2`
278
+
- Create bytes for signing by concatenating `ipns-signature:` prefix (bytes in hex: `69706e732d7369676e61747572653a`) with raw CBOR bytes from `IpnsEntry.data`
279
+
- Sign concatenated bytes from the previous step using the private key, and store the signature in `IpnsEntry.signatureV2`
280
+
6. Create `IpnsEntry.signatureV1` (backward compatibility, for legacy software)
281
+
- Create bytes for signing by concatenating `IpnsEntry.value` + `IpnsEntry.validity` + `string(IpnsEntry.validityType)`
282
+
- Sign concatenated bytes from the previous step using the private key, and store the legacy signature in `IpnsEntry.signatureV1`
283
+
7. Confirm that the serialized `IpnsEntry` bytes sum to less than or equal to [the size limit](#record-size-limit).
0 commit comments