Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: add missing signed peer record to identify spec #630

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 16 additions & 2 deletions identify/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@

| Lifecycle Stage | Maturity Level | Status | Latest Revision |
|-----------------|----------------|--------|-----------------|
| 3A | Recommendation | Active | r1, 2021-08-09 |
| 3A | Recommendation | Active | r3, 2024-09-11 |

Authors: [@vyzo]

Expand Down Expand Up @@ -37,7 +37,7 @@ and spec status.
- [listenAddrs](#listenaddrs)
- [observedAddr](#observedaddr)
- [protocols](#protocols)

- [signedPeerRecord](#signedpeerrecord)

## Overview

Expand Down Expand Up @@ -81,6 +81,7 @@ message Identify {
repeated bytes listenAddrs = 2;
optional bytes observedAddr = 4;
repeated string protocols = 3;
optional bytes signedPeerRecord = 8;
achingbrain marked this conversation as resolved.
Show resolved Hide resolved
}
```

Expand Down Expand Up @@ -133,3 +134,16 @@ clients only support initiating requests while some servers (only) support
responding to requests. To prevent clients from initiating requests to other
clients, which given them being clients they fail to respond, clients should not
advertise `foo` in their `protocols` list.

### signedPeerRecord

This is a serialized [SignedEnvelope][envelope-rfc] containing a [PeerRecord][peer-record-rfc],
signed by the sending node. It contains the same addresses as the `listenAddrs` field, but in a form that lets us share authenticated addrs with other peers.

This field was introduced in a backwards compatible manner (meaning that it is sent along with the `listenAddrs` field), therefore it is optional.

If the `signedPeerRecord` is present the implementation MUST use the data contained within it and ignore duplicated fields present in the main identify message


[envelope-rfc]: ../RFC/0002-signed-envelopes.md#wire-format
[peer-record-rfc]: ../RFC/0003-routing-records.md#address-record-format