Wiki source code of Networks
Version 55.1 by Zenna Elfen on 2026/01/05 20:27
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
 |
51.1 | 1 | (% class="jumbotron" %) |
| 2 | ((( | ||
| 3 | (% class="container" %) | ||
| 4 | ((( | ||
| 5 | = Building Blocks of P4P Networks = | ||
| |
52.1 | 6 | |
| |
51.1 | 7 | Making a P4P network is a bit different than traditional communication networks, namely because we side-step the traditional confinement of the internet layers and connect in a variety of means, from bluetooth to sneakernet and beyond. This is of course very nice in a variety of circumstances and to read more about the principles and capabilities of P4P networks, see the about page. |
| |
19.1 | 8 | |
| |
55.1 | 9 | To fully assemble a P4P network one needs a few different building blocks, below is an overview of 15 of those building blocks. This outline of 15 building blocks has been collaboratively developed. If you see something missing or would like to give feedback, please reach out to Zenna. Now, let's dive into the building-blocks which make P4P protocols. |
| |
51.1 | 10 | ))) |
| 11 | ))) | ||
| |
27.1 | 12 | |
| |
51.1 | 13 | |
| |
27.1 | 14 | |
| 15 | |||
| |
47.1 | 16 | (% class="row" %) |
| 17 | ((( | ||
| |
43.1 | 18 | (% class="col-xs-12 col-sm-8" %) |
| |
37.1 | 19 | ((( |
| |
52.1 | 20 | == 15 Building Blocks of P4P Networks == |
| 21 | |||
| |
53.1 | 22 | |
| |
15.1 | 23 | ==== **1. Data Synchronization** ==== |
| |
11.1 | 24 | |
| |
13.1 | 25 | > Synchronization answers **how updates flow between peers** and how they determine what data to exchange. This layer is about **diffing, reconciliation, order, causality tracking, and efficient exchange**, not persistence or user-facing collaboration semantics. |
| |
11.1 | 26 | |
| |
15.1 | 27 | * //How do peers detect differences and synchronize state?// |
| 28 | * Examples: Range-Based Set Reconciliation, RIBLT, Gossip-based sync, State-based vs op-based sync, Lamport/Vector/HLC clocks, Braid Protocol | ||
| |
11.1 | 29 | |
| 30 | |||
| 31 | |||
| |
15.1 | 32 | ==== **2. Collaborative Data Structures & Conflict Resolution** ==== |
| |
11.1 | 33 | |
| |
13.1 | 34 | > This layer defines **how shared data evolves** when multiple peers edit concurrently. It focuses on **conflict-free merging, causality, and consistency of meaning**, not transport or storage. CRDTs ensure deterministic convergence, while event-sourced or stream-driven models maintain a history of all changes and derive consistent state from it. |
| 35 | |||
| |
15.1 | 36 | * //How do peers collaboratively change shared data and merge conflicts?// |
| 37 | * Examples: CRDTs (Yjs, Automerge), OT, Event Sourcing, Stream Processing, Version Vectors, Peritext | ||
| |
13.1 | 38 | |
| 39 | |||
| 40 | |||
| |
15.1 | 41 | ==== **3. Data Storage & Replication** ==== |
| |
13.1 | 42 | |
| 43 | > This layer focuses on **durability, consistency, and redundancy**. It handles write-paths, crash-resilience, and replication semantics across nodes. It is the “database/storage engine” layer where **data lives and survives over time**, independent of sync or merging logic. | ||
| 44 | |||
| |
15.1 | 45 | * //How is data persisted locally and replicated between peers?// |
| 46 | * Examples: SQLite, IndexedDB, LMDB, Hypercore (append-only logs), WALs, Merkle-DAGs (IPFS/IPLD), Blob/media storage | ||
| |
13.1 | 47 | |
| 48 | |||
| 49 | |||
| |
15.1 | 50 | ==== **4. Peer & Content Discovery** ==== |
| 51 | |||
| |
13.1 | 52 | > Discovery occurs in two phases: |
| 53 | > 1. **Peer Discovery** → finding _any_ nodes | ||
| 54 | > 2. **Topic Discovery** → finding _relevant_ nodes or resources | ||
| 55 | > These mechanisms enable decentralized bootstrapping and interest-based overlays. | ||
| 56 | |||
| |
15.1 | 57 | * //How do peers find each other, and how do they discover content in the network?// |
| 58 | * Examples: DHTs (Kademlia, Pastry), mDNS, DNS-SD, Bluetooth scanning, QR bootstrapping, static peer lists, Interest-based routing, PubSub discovery (libp2p), Rendezvous protocols | ||
| |
13.1 | 59 | |
| 60 | |||
| 61 | |||
| |
15.1 | 62 | ==== **5. Identity & Trust** ==== |
| |
13.1 | 63 | |
| 64 | > Identity systems ensure reliable mapping between peers and cryptographic keys. They underpin authorization, federated trust, and secure overlays. | ||
| 65 | |||
| |
15.1 | 66 | * //How peers identify themselves, authenticate, and establish trustworthy relationships?// |
| 67 | * Examples: PKI, Distributed Identities (DIDs), Web-of-Trust, TOFU (SSH-style), Verifiable Credentials (VCs), Peer key fingerprints (libp2p PeerIDs), Key transparency logs | ||
| |
13.1 | 68 | |
| 69 | |||
| |
16.1 | 70 | |
| |
15.1 | 71 | ==== **6. Transport Layer** ==== |
| |
13.1 | 72 | |
| |
15.1 | 73 | > This layer provides logical connections and flow control. QUIC and WebRTC bring modern congestion control and encryption defaults; Interpeer explores transport beyond IP assumptions. |
| |
13.1 | 74 | |
| |
16.1 | 75 | * //How do peers establish end-to-end byte streams and reliable delivery?// |
| |
15.1 | 76 | * Examples: TCP, UDP, QUIC, SCTP, WebRTC DataChannels, Interpeer transport stack |
| |
13.1 | 77 | |
| 78 | |||
| |
16.1 | 79 | |
| |
15.1 | 80 | ==== **7. Underlying Transport (Physical/Link Layer)** ==== |
| 81 | |||
| 82 | > Highly relevant for **offline-first / edge networks**, device-to-device communication, and mesh networks and relates to the hardware which facilitates connections. | ||
| 83 | |||
| |
16.1 | 84 | * //How does data move across the medium?// |
| |
15.1 | 85 | * Examples: Ethernet, Wi-Fi Direct / Wi-Fi Aware (post-AWDL), Bluetooth Mesh, LoRa, NFC, Cellular, CSMA/CA, TDMA, FHSS |
| 86 | |||
| |
16.1 | 87 | |
| 88 | |||
| |
15.1 | 89 | ==== **8. Session & Connection Management** ==== |
| 90 | |||
| 91 | > Manages **connection lifecycle**, including authentication handshakes, reconnection after drops, and session continuation—especially important in lossy or mobile networks. | ||
| 92 | |||
| |
16.1 | 93 | * //How are connections initiated, authenticated, resumed, and kept alive?// |
| |
15.1 | 94 | * Examples: TLS handshake semantics, Noise IK/XX patterns, session tokens, keep-alive heartbeats, reconnection strategies, session resumption tickets |
| 95 | |||
| 96 | |||
| |
16.1 | 97 | |
| |
15.1 | 98 | ==== **9. Content Addressing** ==== |
| 99 | |||
| 100 | > Content addressing ensures **immutability, verifiability, and deduplication**. Identity of data = cryptographic hash, enabling offline-first and tamper-evident systems. | ||
| 101 | |||
| |
16.1 | 102 | * //How is data addressed and verified by content, not location?// |
| |
15.1 | 103 | * Examples: IPFS CIDs, BitTorrent infohashes, Git hashes, SHA-256 addressing, Named Data Networking (NDN) |
| 104 | |||
| |
16.1 | 105 | |
| 106 | |||
| |
15.1 | 107 | ==== **10. P2P Connectivity** ==== |
| 108 | |||
| |
16.1 | 109 | > Connectivity ensures peers bypass NATs/firewalls to reach each other. |
| |
15.1 | 110 | |
| |
16.1 | 111 | * //How can two peers connect directly across networks, firewalls, and NATs?// |
| |
15.1 | 112 | * Examples: IPv6 direct, NAT Traversal, STUN, TURN, ICE (used in WebRTC), UDP hole punching, UPnP |
| 113 | |||
| |
16.1 | 114 | |
| 115 | |||
| |
15.1 | 116 | ==== **11. Session & Connection Management** ==== |
| 117 | |||
| 118 | > Manages **connection lifecycle**, including authentication handshakes, reconnection after drops, and session continuation. | ||
| 119 | |||
| |
16.1 | 120 | * //How are connections initiated, authenticated, resumed, and kept alive?// |
| |
15.1 | 121 | * Examples: TLS handshake semantics, Noise IK/XX patterns, session tokens, keep-alive heartbeats, reconnection strategies, session resumption tickets |
| 122 | |||
| |
16.1 | 123 | |
| 124 | |||
| |
15.1 | 125 | ==== **12. Message Format & Serialization** ==== |
| 126 | |||
| 127 | > Serialization ensures **portable data representation**, forward-compatible schemas, and efficient messaging. IPLD provides content-addressed structuring for P2P graph data. | ||
| 128 | |||
| |
16.1 | 129 | * //How is data encoded, structured, and made interoperable between peers?// |
| |
15.1 | 130 | * Examples: CBOR, Protocol Buffers, Cap’n Proto, JSON, ASN.1, IPLD schemas, Flatbuffers |
| 131 | |||
| |
16.1 | 132 | |
| 133 | |||
| |
15.1 | 134 | ==== **13. File / Blob Synchronization** ==== |
| 135 | |||
| 136 | > Bulk data syncing has **different trade-offs** than small collaborative state (chunking, deduplication, partial transfer, resume logic). Critical for media and archival P2P use-cases. | ||
| 137 | |||
| |
16.1 | 138 | //How are large objects transferred and deduplicated efficiently across peers?// |
| |
15.1 | 139 | Examples: BitTorrent chunking, IPFS block-store, NDN segments, rsync-style delta sync, ZFS send-receive, streaming blob transfers |
| 140 | |||
| |
16.1 | 141 | |
| |
15.1 | 142 | ==== **14. Local Storage & Processing Primitives** ==== |
| 143 | |||
| 144 | > Provides durable on-device state and local computation (event sourcing, materialization, compaction). Enables offline-first writes and deterministic replay. | ||
| 145 | |||
| |
16.1 | 146 | * //How do nodes persist, index, and process data locally—without external servers?// |
| |
15.1 | 147 | * Examples: RocksDB, LevelDB, SQLite, LMDB, local WALs/append-only logs, embedded stream processors (NATS Core JetStream mode, Actyx-like edge runtimes), Kafka-like libraries |
| 148 | |||
| 149 | |||
| |
16.1 | 150 | |
| |
15.1 | 151 | ==== **15. Crash Resilience & Abortability** ==== |
| 152 | |||
| 153 | > Ensures P2P apps don’t corrupt state on crashes. Tied to **local storage & stream-processing**, and critical in offline-first and distributed update pipelines. Abortability is the updated term for Atomicity as part of the ACID abbreviation. | ||
| 154 | |||
| |
16.1 | 155 | * //How do nodes recover and maintain correctness under failure?// |
| |
15.1 | 156 | * Examples: WALs, idempotent ops, partial log replay, transactional journaling, write fences |
| 157 | |||
| 158 | |||
| 159 | |||
| |
49.1 | 160 | |
| |
48.1 | 161 | ))) |
| |
15.1 | 162 | |
| |
11.1 | 163 | |
| |
49.1 | 164 | |
| |
55.1 | 165 | |
| |
46.1 | 166 | (% class="col-xs-12 col-sm-4" %) |
| 167 | ((( | ||
| 168 | {{box title=" **Contents**"}} | ||
| 169 | {{toc depth="5"/}} | ||
| 170 | {{/box}} | ||
| 171 | ))) | ||
| 172 | |||
| |
48.1 | 173 | |
| |
47.1 | 174 | (% class="col-xs-12 col-sm-12" %) |
| 175 | ((( | ||
| |
48.1 | 176 | == Distributed Network Types == |
| 177 | |||
| 178 | |||
| 179 | [[Flowchart depicting distributed network variants, under development. Building on work from Z. Elfen, 2024: ~[~[https:~~~~/~~~~/doi.org/10.17613/naj7d-6g984~>~>https://doi.org/10.17613/naj7d-6g984~]~]>>image:P4P_Typology.png||alt="Flowchart depicting typologies of distributed networks, such as Friend-2-Friend, Grassroots Networks, Federated Networks, Local-First, P2P and P4P Networks" data-xwiki-image-style-alignment="center" height="649" width="639"]] | ||
| 180 | |||
| 181 | |||
| |
49.1 | 182 | |
| |
35.1 | 183 | == Overview of P4P Networks == |
| 184 | |||
| 185 | {{include reference="Projects.WebHome"/}} | ||
| |
47.1 | 186 | ))) |
| |
11.1 | 187 | |
| 188 | |||
| |
32.1 | 189 | |
| |
33.1 | 190 | |
| |
34.1 | 191 | |
| |
48.1 | 192 | |
| |
47.1 | 193 | |
| 194 | ))) |