Relationship-centric communication

Participant Relationship Protocol

PRP is a communication architecture in which communication becomes possible because a relationship already exists, not because a participant can be located through a globally coordinated address.

Comparison between address-centric and relationship-centric communication

Communication becomes possible because a relationship already exists.

Watch & explore

PRP videos

Explore identities, autonomy, and relationships through film.

Browse the videos

Architectural position

Relationships are the primary communication object.

PRP separates communication continuity from address continuity. A relationship defines permissions, trust material, identity constraints, authorization boundaries, and the continuity needed for communication over time.

Routes, transports, and carriers are replaceable realization mechanisms. A relationship may survive changes in topology, carrier technology, governance participation, and participant location.

Primary objects

PRP shifts the architectural center.

Comparison of primary communication objects in TCP/IP, Tor, NDN, SCION, and PRP

Architecture

Core layers preserve the relationship-centric model.

Relationship Layer

Defines communication contexts, continuity, identity constraints, trust material, and authorization.

Routing Layer

Defines communication trajectories used to realize a relationship without becoming participant identity.

Transport Layer

Defines authenticated information exchange between participants inside a relationship context.

Carrier Layer

Moves communication data through packet networks, streams, intermittent media, logistics, or future carriers.

Relationship-centric architectural layers from service layer through carrier layer

Design goals

Built for continuity across changing infrastructure.

Roadmap

From candidate architecture to open interoperability.

The roadmap records technical gates, not promised dates. Work controlled by the project is distinguished from assignments and standards decisions made by external communities.

01 Active

PRP core

Stabilize the architecture, wire protocol, registries, security model, and version migration rules.

  1. Candidate architecture and working drafts
  2. Normative vectors and conformance suite
  3. Independent implementation interoperability
02 Active

IETF standardization

Develop Internet-Drafts and take the work through open technical and community review.

  1. Architecture Internet-Draft -00 published
  2. IPR, contribution, and registry governance
  3. Community discussion and draft revisions
  4. Working Group, DISPATCH, or sponsored path
  5. Possible RFC following IETF consensus
  6. Proposed PRP DNS resource record — revision pending
03 Conditional

Carrier assignments

Request globally scarce identifiers only after each carrier binding is stable and independently justified.

  1. IANA service name and UDP user port
  2. IEEE EtherType for PRP over Ethernet
  3. Bluetooth assignment only if a future profile requires it
04 Independent

Ethernet discovery

Discovery is a carrier-side protocol, not part of the PRP wire protocol or a prerequisite for every deployment.

  1. Stabilize its own framing and lifecycle
  2. Preserve independent versioning and security
  3. Request its own EtherType if publicly deployed

Sponsors & contributors

Support from architecture to deployment.

PRP is supported through engineering, funding, PRP access, and access gateway infrastructure. Organizations are recognized by their current contribution to the project.