Participant Relationship Protocol

Back to matrix

C01-I2: Yes

Rationale

An I2P client can retain its Destination while its co-located router changes its external NTCP2 attachment. Replacement inbound tunnels are advertised in an updated LeaseSet for that same Destination; a sender with the known destination key can obtain usable tunnel entry points without adopting another destination identity. Pinned Java source separates external-address/RouterInfo updates from the client session and requests new LeaseSets as tunnel membership changes.

Assessment method

Primary documentation and pinned source review; no runtime experiment

Source context

I2P LeaseSets and GNUnet CADET identity/path separation

Outstanding qualification

The witness retains destination keys and uses reachable numeric NTCP2 peers at the replacement access, valid clocks and successful multi-hop tunnel construction. The signed LeaseSet and its lookup must become usable before delivery; stale leases, failed tunnel construction or isolation can prevent recovery. A fresh application session is permitted by C01. No preservation of the old TCP connection, automatic recovery from arbitrary partitions or bounded handover time is claimed. The selected netDb lookup is native location resolution, not an external naming service that substitutes the destination. This does not depend on MetaLeaseSets or multiple interchangeable destination identities. No runtime experiment; the cited Java implementation corroborates the routing mechanism, not the separate i2pd post-quantum configuration.

Public sources

Editorial evidence references

The following identifiers refer to research records not included in this public package; they are not public links.