Changes for page Networks
Last modified by Zenna Elfen on 2025/11/24 12:07
From version 14.1
edited by Zenna Elfen
on 2025/11/24 11:48
on 2025/11/24 11:48
Change comment:
There is no comment for this version
To version 12.1
edited by Zenna Elfen
on 2025/11/24 11:46
on 2025/11/24 11:46
Change comment:
There is no comment for this version
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -10,10 +10,6 @@ 10 10 11 11 12 12 13 - 14 - 15 - 16 - 17 17 == Building Blocks of P4P Networks == 18 18 19 19 ... ... @@ -25,60 +25,12 @@ 25 25 To fully assemble a P4P network one needs a few different building blocks. The following is an overview of the building blocks needed for P4P networks. 26 26 27 27 28 -==== **Data Synchronization** ==== 29 29 30 -> 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. 31 31 32 -- _How do peers detect differences and synchronize state?_ 33 -- Examples: Range-Based Set Reconciliation, RIBLT, Gossip-based sync, State-based vs op-based sync, Lamport/Vector/HLC clocks, Braid Protocol 34 34 35 -*Relevant links or documentation:* 36 36 37 37 38 -==== **Collaborative Data Structures & Conflict Resolution** ==== 39 39 40 -> 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. 41 - 42 -- _How do peers collaboratively change shared data and merge conflicts?_ 43 -- Examples: CRDTs (Yjs, Automerge), OT, Event Sourcing, Stream Processing, Version Vectors, Peritext 44 - 45 -*Relevant links or documentation:* 46 - 47 - 48 -==== **Data Storage & Replication** ==== 49 - 50 -> 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. 51 - 52 -- _How is data persisted locally and replicated between peers?_ 53 -- Examples: SQLite, IndexedDB, LMDB, Hypercore (append-only logs), WALs, Merkle-DAGs (IPFS/IPLD), Blob/media storage 54 - 55 -*Relevant links or documentation:* 56 - 57 -==== **Peer & Content Discovery** ==== 58 - 59 -> Discovery occurs in two phases: 60 -> 1. **Peer Discovery** → finding _any_ nodes 61 -> 2. **Topic Discovery** → finding _relevant_ nodes or resources 62 -> These mechanisms enable decentralized bootstrapping and interest-based overlays. 63 - 64 - 65 -- _How do peers find each other, and how do they discover content in the network?_ 66 -- Examples: DHTs (Kademlia, Pastry), mDNS, DNS-SD, Bluetooth scanning, QR bootstrapping, static peer lists, Interest-based routing, PubSub discovery (libp2p), Rendezvous protocols 67 - 68 -*Relevant links or documentation:* 69 - 70 -# **Identity & Trust** 71 - 72 -> Identity systems ensure reliable mapping between peers and cryptographic keys. They underpin authorization, federated trust, and secure overlays. 73 - 74 -- _How peers identify themselves, authenticate, and establish trustworthy relationships?_ 75 -- Examples: PKI, Distributed Identities (DIDs), Web-of-Trust, TOFU (SSH-style), Verifiable Credentials (VCs), Peer key fingerprints (libp2p PeerIDs), Key transparency logs 76 - 77 - 78 - 79 - 80 - 81 - 82 82 == Distributed Network Types == 83 83 84 84