DP22 – Civic Memory & Sensemaking Continuity
Patches are passage-level only – each one is tied to selected text in the reader. There are no document-wide patches. Use comments for general feedback on the whole document.
These are the fast layers, and their speed is a feature rather than a defect.
Daveed
These are the fast layers, and their speed is a feature rather than a defect. ### 10.1 Reference implementation example: PDP-Connect (PDPP) This subsection is non-normative. It names a concrete standards-track effort that demonstrates how the mechanisms in §10 and the related DP1, DP4, and DP7 clauses can be realized in practice. Whether PDPP is adopted for a given Meta-Layer system is an Overweb architecture decision, not a DP7 requirement. PDPP (Personal Data Portability Protocol) is an open specification for moving personal data with the consent of the person it belongs to. It is developed by PDP-Connect, a lab at Linux Foundation Decentralized Trust. Source: [web:pdpp.dev]. **Mechanism mapping:** - OAuth 2.0 plus RFC 9396 (Rich Authorization Requests) in PDPP is one realization of the consent stack and scope binding described in DP4 §5.3. - Source, Accessor, and Operator roles with declared purpose and expiration correspond to DP4's purpose binding and DP1's accountable action binding. - Agreed terms visible to both parties correspond to DP4's durable record and DP7's transfer receipt logging. - Range-limited queries (such as fields and date windows in selection requests) realize DP4's minimization by design. **Conformance posture:** PDPP exposes two verification rungs. A Conformant mark is produced by an automated check. A Verified mark requires human review by a technical committee, with identity anchored in a recognised trust registry. Source: [web:pdpp.dev]. **Layering pattern:** The interface contract under DP7 §10 separates the operations a system must expose (read scopes, grant permissions, expire access, produce receipts, revoke) from the connector that adapts those operations to a specific standard. PDPP is one connector target against that interface; another standard can be added as a second connector without changing what the system itself does.
Why it fits: - §10 Implementation Patterns already calls out conformance suites, object envelopes, and receipt logs; a reference example subsection sits cleanly at §10.1 and demonstrates each pattern in one concrete protocol. - The auth/consent stack (OAuth 2.0 + RFC 9396), role-binding, durable record, and range-limited selection requests map one-to-one onto clauses already named in DP1 and DP4, so the subsection is illustrative rather than introducing new requirements. - Splitting the interface contract from a PDPP connector aligns with the earlier clarification that PDPP is one downstream target, not the only one, preserving multi-standard portability. Pre-flight checks against the graph: - DP7 §10.1, §10.2, and §10.4 already provide the conformance, envelope, and receipt anchors this subsection references, so no new §10 numbering is needed beyond §10.1. - DP23 (Universal Participation & Linguistic Interoperability) is in active development and is not invoked here; the patch stays inside the inscribed DP1/DP4/DP7 cross-walk. - The mechanism-mapping bullets cite only DP1, DP4, and DP7 clauses that exist in the draft, so no forward references are introduced. Filed from Canopi book insert 4340a7d1-7d1d-4968-83ec-38c0064064f9 (insert below the anchor, encoded as replace); posted on the DP7 page but anchored in DP22.
Compression removes uncertainty, dissent, historical nuance, or scope conditions.
Daveed
Compression removes uncertainty, dissent, historical nuance, or scope conditions. ### 5.3 Reference implementation example: PDP-Connect (PDPP) This subsection is non-normative. It names a concrete standards-track effort that demonstrates how DP4's consent, purpose, minimization, and durable-record mechanisms can be realized in practice. Adoption of PDPP for any given Meta-Layer system is an Overweb ADR decision, not a DP4 requirement. PDPP (Personal Data Portability Protocol) is an open specification for moving personal data with the consent of the person it belongs to. It is developed by PDP-Connect, a lab at Linux Foundation Decentralized Trust. Source: [web:pdpp.dev]. **Mechanism mapping:** - OAuth 2.0 plus RFC 9396 (Rich Authorization Requests) in PDPP is one realization of the consent stack and scope binding described in DP4 §5.1. - Source, Accessor, and Operator roles with declared purpose and expiration correspond to DP4's purpose binding under §5.2. - Agreed terms visible to both parties satisfy the durable record requirement in DP4 §5.4. - Range-limited selection requests (specific fields, specific date windows) correspond to DP4's minimization by design under §5.5. **Conformance posture:** PDPP exposes two verification rungs. A Conformant mark is produced by an automated check. A Verified mark requires human review by a technical committee, with identity anchored in a recognised trust registry. Source: [web:pdpp.dev]. **Cross-references:** DP1 §9, DP7 §10.x, DP14 §9.
Why it fits: - §5 already covers purpose binding and consent; §5.3 (renumbered if needed after the recent additions) as a reference example keeps the DP4 narrative flowing without disrupting §5.1, §5.2, §5.4, or §5.5. - Each mechanism in PDPP is mapped to an existing DP4 clause, so the patch deepens, not expands, the inscribed body of DP4. - Dropping DP22 from this patch's cross-references, per the latest decision, tightens the citation to DP1, DP7, and DP14 so readers are not pulled to a still-incubating DP. Pre-flight checks against the graph: - The patch cites only DP4 clauses that exist in the draft and the inscribed DPs (DP1, DP7, DP14), so no forward references are introduced. - DP23 (Universal Participation & Linguistic Interoperability) is left untouched and not invoked, keeping the patch inside the inscribed cross-walk. - Removing DP22 from this patch's cross-references matches the graph state (DP22 is inscribed but the call to drop it here is an editorial choice) and avoids double-listing where DP1 §13.x and DP7 §10.x carry their own DP22 references. Filed from Canopi book insert e9353cd3-6238-4d20-ad2e-bc7aa483dc66 (insert below the anchor, encoded as replace); posted on the DP4 page but anchored in DP22.
Knowing that ideas may become part of humanity's enduring memory encourages stewardship, responsibility, and intentionality in what is created now.
Daveed
Knowing that ideas may become part of humanity's enduring memory encourages stewardship, responsibility, and intentionality in what is created now. ### 13.4 Reference implementation example: PDP-Connect (PDPP) This subsection is non-normative. It names a concrete standards-track effort that demonstrates how DP1's accountability and identity mechanisms can be realized in practice. Adoption of PDPP for any given Meta-Layer system is an Overweb ADR decision, not a DP1 requirement. PDPP (Personal Data Portability Protocol) is an open specification for moving personal data with the consent of the person it belongs to. It is developed by PDP-Connect, a lab at Linux Foundation Decentralized Trust. Source: [web:pdpp.dev]. **Mechanism mapping:** - The Source, Accessor, and Operator roles bind each transfer to identifiable parties with declared purpose. This is one realization of action-bound accountability under DP1 §9.1. - Agreed terms are recorded in a form visible to both parties, so subsequent actions can be checked against the original grant. This addresses persistence of attribution under DP1 §9.2 and supports pseudonymity with responsibility. - Identity for the Verified conformance rung is anchored in a recognised trust registry, providing one workable form of cross-zone identity signalling under DP1 §8.5. Source: [web:pdpp.dev]. - Range-limited selection requests (specific fields, specific date windows) correspond to DP1's resistance to sybil and coordinated overreach by bounding what a single grant can extract.
Why it fits: - §13 already covers governance, accountability, and agency surfaces; a reference example placed at §13.4 demonstrates DP1's accountability and identity clauses on a working standards-track protocol. - Each PDPP feature is mapped to an existing DP1 clause (§8.5, §9.1, §9.2), so the patch deepens the inscribed body rather than introducing new obligations. - Labelling the subsection non-normative preserves the boundary that DP1 does not mandate PDPP; the Overweb ADR decides which connector a given system ships. Pre-flight checks against the graph: - The clauses referenced (§8.5, §9.1, §9.2) are inscribed DP1 clauses, so no cross-zone signalling or attribution reference is invented. - The patch remains inside the inscribed DPs and does not invoke DP23 (Universal Participation & Linguistic Interoperability), which is still in active development. - Keeping DP22 in this subsection's cross-walk (implicitly, via its own DP1 cross-reference) avoids the conflicting edit the user just removed from the DP4 patch. Filed from Canopi book insert 106fc5a3-f997-4c11-9945-6afbc1b305d8 (insert below the anchor, encoded as replace); posted on the DP1 page but anchored in DP22.
Open the reader, select the sentence(s) you want to change, and submit a patch.
Open ReaderTitle: DP22 – Civic Memory & Sensemaking Continuity
Authors: The Meta-Layer Initiative
Status: approved
Last Updated: 2026-05-26