{"id":835554,"date":"2026-02-18T21:20:26","date_gmt":"2026-02-18T21:20:26","guid":{"rendered":"https:\/\/gridnet.org\/wpp\/?p=835554"},"modified":"2026-02-20T07:57:40","modified_gmt":"2026-02-20T07:57:40","slug":"building-real-things-files-messages-and-webrtc-swarms","status":"publish","type":"post","link":"https:\/\/mag.gridnet.org\/index.php\/2026\/02\/18\/building-real-things-files-messages-and-webrtc-swarms\/","title":{"rendered":"Building Real Things \u2014 Files, Messages, and WebRTC Swarms"},"content":{"rendered":"
Introduction: What “Building Real Things” Means on a Decentralized OS<\/h2>\n
In the previous articles of this series, you learned the fundamentals: how GRIDNET OS UI dApps are structured, how CWindow<\/code> gives you an isolated Shadow DOM sandbox, how CVMContext<\/code> connects your JavaScript to a blockchain-backed virtual machine, and how GridScript commands drive state transitions on the decentralized ledger. You built a “Hello Blockchain” dApp. You explored the CVMContext API in depth.<\/p>\n
Now comes the question that separates toy demos from real software: what can you actually build?<\/strong><\/p>\n
The answer is: quite a lot. GRIDNET OS provides three foundational capabilities that, combined, enable an entire class of applications that would traditionally require servers, databases, cloud storage, and messaging infrastructure:<\/p>\n
\n
A Decentralized File System<\/strong> \u2014 create directories, read and write files, navigate paths, commit changes to the blockchain. No Amazon S3. No Firebase. Your files live on the chain.<\/li>\n
Peer-to-Peer Messaging<\/strong> \u2014 the built-in Messenger dApp demonstrates direct, encrypted, zero-server communication between browsers using WebRTC data channels. No WhatsApp backend. No Signal server.<\/li>\n
WebRTC Swarms<\/strong> \u2014 create multi-peer mesh networks where browsers connect directly to each other for real-time data exchange, audio, video, and screen sharing. The signaling server (a GRIDNET full node) brokers the initial connection; after that, traffic flows peer-to-peer.<\/li>\n<\/ol>\n
This article is your comprehensive reference for all three. Every method signature is taken directly from the source code. Every example is tested against the actual implementation. By the end, you will be able to build a file manager, a messenger, or a collaborative real-time application \u2014 from scratch, on a decentralized OS, with no server of your own.<\/p>\n
Part I: The Decentralized File System<\/h2>\nThe request flow: your dApp calls CFileSystem methods, which construct CDFSMsg datagrams, which CVMContext sends over WebSocket to the full node, which reads\/writes the blockchain state.<\/figcaption><\/figure>\n
Architecture Overview<\/h3>\n
The decentralized file system in GRIDNET OS is not a POSIX file system. It is a blockchain-backed hierarchical data store<\/strong> with directory navigation, file creation, file reading, and atomic commits. Think of it as a version-controlled file system where every commit is a blockchain transaction \u2014 immutable, timestamped, and cryptographically secured.<\/p>\n
The file system is accessed through the CFileSystem<\/code> singleton class, defined in \/lib\/FileSystem.js<\/code>. You obtain it via:<\/p>\n
Every file system operation follows the same pattern:<\/p>\n
\n
You call a method on CFileSystem<\/code> (e.g., doCD()<\/code>, doLS()<\/code>, doNewFile()<\/code>).<\/li>\n
The method constructs a CDFSMsg<\/code> \u2014 a DFS (Decentralized File System) message with the appropriate command type.<\/li>\n
CVMContext.sendDFSMsg()<\/code> serializes and sends the message over the WebSocket connection to the full node.<\/li>\n
The full node processes the command against the blockchain state.<\/li>\n
A response arrives asynchronously via the DFS message listener system.<\/li>\n
You receive results in your registered callback.<\/li>\n<\/ol>\n
The return value of every CFileSystem<\/code> method is a COperationStatus<\/code> object \u2014 not the file data itself. The actual data arrives asynchronously through listeners. This is the critical mental model: all DFS operations are fire-and-forget commands with async responses.<\/strong><\/p>\n
Thread IDs: The Routing Key<\/h3>\n
Every file system operation takes an optional threadID<\/code> parameter. This parameter determines which decentralized thread<\/strong> processes the command. GRIDNET OS uses two primary threads:<\/p>\n
\n
'data'<\/code> \u2014 The data thread<\/strong>, used for file read\/write operations. This is the default for most CFileSystem<\/code> methods.<\/li>\n
'system'<\/code> \u2014 The system thread<\/strong>, used for commit operations and state-changing transactions.<\/li>\n<\/ul>\n
The symbolic thread names ('data'<\/code>, 'system'<\/code>) are resolved to actual ArrayBuffer<\/code> thread identifiers by CTools.getInstance().genericThreadNameToID(threadID)<\/code>. You can also pass the raw ArrayBuffer<\/code> thread ID directly \u2014 for example, from this.getThreadID<\/code> in your CWindow<\/code> subclass, which returns the thread ID assigned to your dApp’s window.<\/p>\n
The File Manager dApp demonstrates this pattern throughout: it consistently passes this.getThreadID<\/code> as the thread ID parameter, ensuring all operations are scoped to that window’s thread context:<\/p>\n
Navigates to a directory path on the decentralized file system.<\/p>\n
\n\/**\n * @param {string} path \u2014 Directory path to navigate to (e.g., '\/', '\/myApp\/data')\n * @param {boolean} doLS \u2014 If true, performs an atomic LS after CD (default: true)\n * @param {boolean} breakCommit \u2014 If true, breaks any pending commit lock (default: false)\n * @param {boolean} dontThrow \u2014 If true, suppresses fatal errors for missing dirs (default: false)\n * @param {string|ArrayBuffer} threadID \u2014 Thread to process on (default: 'data')\n * @returns {COperationStatus} \u2014 Contains getReqID and getIsSuccess\n *\/\nconst fs = CVMContext.getInstance().getFileSystem;\nconst result = fs.doCD('\/myApp\/data', true, false, false, this.getThreadID);\n\nif (result.getIsSuccess) {\n \/\/ Request sent successfully \u2014 await async response via DFS listener\n this.addNetworkRequestID(result.getReqID);\n}\n<\/pre>\n
The doLS<\/code> parameter is a powerful optimization: when true<\/code>, the full node performs the directory change and listing as a single atomic operation<\/strong>, saving a round trip. The File Manager uses doCD(path, true, ...)<\/code> almost exclusively \u2014 navigating and listing in one shot.<\/p>\n
The dontThrow<\/code> parameter is important for defensive programming: normally, attempting to cd<\/code> into a non-existent directory causes a fatal error on the VM. Setting dontThrow = true<\/code> converts this into a soft error returned via COperationResult<\/code>.<\/p>\n
Internally, doCD<\/code> constructs a CDFSMsg<\/code> with command type eDFSCmdType.enterDirLS<\/code> (or eDFSCmdType.enterDir<\/code> if doLS<\/code> is false), sets the path as UTF-8 encoded data, and sends it via CVMContext.sendDFSMsg()<\/code>.<\/p>\n
doLS(threadID, breakCommit)<\/code> \u2014 List Directory<\/h4>\n
Lists the contents of the current directory.<\/p>\n
\n\/**\n * @param {string|ArrayBuffer} threadID \u2014 Thread to process on (default: 'data')\n * @param {boolean} breakCommit \u2014 Break pending commit lock (default: false)\n * @returns {COperationStatus}\n *\/\nconst result = fs.doLS(this.getThreadID);\nthis.addNetworkRequestID(result.getReqID);\n<\/pre>\n
The directory listing arrives as a CDFSMsg<\/code> response through your registered DFS message listener. The response contains a serialized representation of the directory’s files and subdirectories.<\/p>\n
doNewFile(path, content, breakCommit, threadID)<\/code> \u2014 Create\/Write a File<\/h4>\n
Creates a new file or overwrites an existing one at the specified path.<\/p>\n
Important:<\/strong> The file path is automatically quoted by the method if not already wrapped in quotes. The content can be either a JavaScript string (which will be UTF-8 encoded) or a raw ArrayBuffer<\/code> for binary data. On success, a CConsensusTask<\/code> is created with description “New File” \u2014 this appears in the Magic Button’s pending operations display, informing the user that uncommitted changes exist.<\/p>\n
updateFile(path, content, breakCommit, threadID)<\/code> \u2014 Update an Existing File<\/h4>\n
Updates a file’s content. Unlike doNewFile()<\/code>, this method checks whether a consensus task for the same file already exists, avoiding duplicate entries in the pending operations list.<\/p>\n
doCommit(breakCommit, threadID)<\/code> \u2014 Commit Changes to Blockchain<\/h4>\n
This is where the magic happens. All file operations (create, update, delete) are initially made in a local staging area<\/strong> \u2014 like a Git index. Nothing is permanent until you commit. The doCommit()<\/code> method proposes all staged changes as a blockchain transaction.<\/p>\n
Critical detail:<\/strong> Note the default thread ID is 'system'<\/code> for commits, not 'data'<\/code>. Commits are state-changing operations that must run on the system thread. The commit process involves:<\/p>\n\n
A commit lock is acquired (preventing other dApps from committing simultaneously).<\/li>\n
Staged changes are bundled into a transaction proposal.<\/li>\n
The full node submits the transaction to the blockchain network.<\/li>\n
Network consensus validates the transaction.<\/li>\n
On success, the changes become permanent and immutable.<\/li>\n<\/ol>\n
The commit state machine has several states tracked by CVMContext<\/code>: eCommitState.none<\/code>, eCommitState.prePending<\/code>, eCommitState.pending<\/code>, eCommitState.success<\/code>, eCommitState.aborted<\/code>. You can listen for commit state changes via CVMContext.getInstance().addVMCommitStateChangedListener()<\/code>.<\/p>\nThe lifecycle of a file operation: write to cache \u2192 navigate and verify \u2192 commit to blockchain \u2192 immutable storage.<\/figcaption><\/figure>\n
doSync(breakCommit, threadID)<\/code> \u2014 Synchronize from Blockchain<\/h4>\n
Pulls the latest committed state from the blockchain, ensuring your local view reflects the most recent on-chain data.<\/p>\n
Call doSync()<\/code> when you need to see the freshest on-chain data \u2014 for example, after another user has committed changes, or when your dApp starts up and needs the latest state.<\/p>\n
Listening for Responses: The DFS Message Listener Pattern<\/h3>\n
Since all file system operations are asynchronous, you need to register listeners to receive results. There are two listener mechanisms:<\/p>\n
1. DFS Message Listener \u2014 Low-Level<\/h4>\n
\n\/\/ Register a DFS message listener\nCVMContext.getInstance().addNewDFSMsgListener(\n function(msg) {\n \/\/ msg is a CDFSMsg containing the response\n \/\/ Process directory listings, file contents, error codes, etc.\n console.log('DFS Response received:', msg);\n },\n this.getProcessID \/\/ appID \u2014 for cleanup when your dApp closes\n);\n<\/pre>\n
The File Manager dApp registers its listener in the constructor and uses it to process all file system responses \u2014 updating the UI with directory listings, displaying file contents, and handling errors.<\/p>\n
\nCVMContext.getInstance().addDFSRequestCompletedListener(\n function(result) {\n \/\/ result contains the operation status and any response data\n },\n this.getProcessID\n);\n<\/pre>\n
3. Network Request ID Tracking<\/h4>\n
The CWindow<\/code> base class provides addNetworkRequestID(reqID)<\/code>, which the File Manager uses extensively to track which requests belong to this window. When a response arrives, the window can check if the response’s request ID matches one it’s tracking:<\/p>\n
\n\/\/ Pattern from FileManager.js \u2014 fire request and track its ID\nconst result = CVMContext.getInstance().getFileSystem.doCD(\n path, true, false, false, this.getThreadID\n);\nthis.addNetworkRequestID(result.getReqID);\n\n\/\/ Later, in DFS listener callback:\n\/\/ Check if msg.getRequestID matches one of our tracked request IDs\n<\/pre>\n
Complete Worked Example: A Simple File Manager<\/h3>\n
Here is a complete, runnable dApp that creates a directory, writes a file, reads it back, and commits everything to the blockchain:<\/p>\n
Part II: Peer-to-Peer Messaging<\/h2>\nThe Messenger creates a direct, encrypted peer-to-peer channel between browsers. The signaling node is only needed for the initial handshake \u2014 after that, messages flow directly.<\/figcaption><\/figure>\n
How the Messenger Works<\/h3>\n
The GRIDNET OS Messenger (CMessenger<\/code>, defined in \/dApps\/Messenger.js<\/code>) is a fully-featured peer-to-peer chat application built on WebRTC. It does not<\/strong> use GRIDNET’s full-node-mediated swarm system for message delivery \u2014 instead, it creates a direct RTCPeerConnection<\/strong> between two browsers, with a named DataChannel<\/code> labelled \"P2P_CHAT_CHANNEL_LABEL\"<\/code>.<\/p>\n
The signaling mechanism uses the GRIDNET full node as a relay for the initial SDP (Session Description Protocol) offer\/answer exchange and ICE candidate negotiation. Once the peer-to-peer connection is established, messages flow directly between browsers \u2014 encrypted with DTLS \u2014 and the signaling node is no longer involved.<\/p>\n
Connection Flow<\/h3>\n\n
User A initiates.<\/strong> The Messenger creates a new RTCPeerConnection<\/code> and a DataChannel named \"P2P_CHAT_CHANNEL_LABEL\"<\/code>.<\/li>\n
SDP Offer.<\/strong> An SDP offer is generated via peerConnection.createOffer()<\/code> and sent through the GRIDNET signaling node to User B.<\/li>\n
User B responds.<\/strong> User B receives the offer, creates their own RTCPeerConnection<\/code>, sets the remote description, generates an SDP answer, and sends it back.<\/li>\n
ICE Exchange.<\/strong> Both peers exchange ICE candidates through the signaling node via onicecandidate<\/code> callbacks. These candidates contain network path information for NAT traversal.<\/li>\n
Direct Connection.<\/strong> Once ICE negotiation succeeds, the DataChannel<\/code> opens. The onopen<\/code> callback fires, and messages can now be sent directly peer-to-peer.<\/li>\n
Message Exchange.<\/strong> Text messages are sent through the DataChannel.send()<\/code> method and received via DataChannel.onmessage<\/code>.<\/li>\n<\/ol>\n
The Peer Code Pattern<\/h3>\n
The Messenger uses a peer code<\/strong> system for connection establishment. When User A wants to connect to User B:<\/p>\n
\n
User B generates or shares a peer code (typically derived from their identity or session).<\/li>\n
User A enters this code in the Messenger UI.<\/li>\n
The signaling node routes the SDP exchange based on this code.<\/li>\n<\/ul>\n
This is fundamentally different from centralized messaging where a server stores and forwards messages. Here, the “server” (GRIDNET node) is only a matchmaker \u2014 it introduces peers and then steps aside.<\/p>\n
Building Your Own P2P Messaging<\/h3>\n
While the Messenger dApp is a React-based bundled application, you can build your own P2P messaging using the same underlying WebRTC infrastructure. The key components from the GRIDNET OS library are:<\/p>\n
\n\/\/ 1. Access the Swarm Manager (which handles WebRTC signaling)\nconst swarmManager = CVMContext.getInstance().getSwarmsManager;\n\n\/\/ 2. Join a swarm (creates a named communication room)\nconst swarmID = CTools.getInstance().convertToArrayBuffer('my-chat-room');\nswarmManager.joinSwarm(\n swarmID, \/\/ swarm identifier\n new ArrayBuffer(), \/\/ userID (empty = use session identity)\n new ArrayBuffer(), \/\/ privKey (empty = use session key)\n eConnCapabilities.data, \/\/ we only need data channels, not audio\/video\n this \/\/ app instance (CWindow subclass)\n);\n\n\/\/ 3. Register event listeners on the swarm\nconst swarm = swarmManager.findSwarmByID(swarmID);\nif (swarm) {\n \/\/ Listen for incoming messages\n swarm.addMessageEventListener(function(event) {\n console.log('Message from peer:', event);\n }, this.getProcessID);\n\n \/\/ Listen for data channel messages (lower level)\n swarm.addDataChannelMessageEventListener(function(event) {\n console.log('DataChannel message:', event);\n }, this.getProcessID);\n\n \/\/ Listen for peer connection state changes\n swarm.addSwarmConnectionStateChangeEventListener(function(event) {\n console.log('Connection state:', event);\n }, this.getProcessID);\n\n \/\/ Listen for new peer tracks (audio\/video)\n swarm.addTrackEventListener(function(event) {\n console.log('New track from peer:', event);\n }, this.getProcessID);\n\n \/\/ Send data to all peers in the swarm\n swarm.sendData(\n CTools.getInstance().convertToArrayBuffer('Hello, swarm!'),\n null, \/\/ null = broadcast to all peers\n true \/\/ only send to authenticated peers\n );\n\n \/\/ Send a structured swarm message\n swarm.sendSwarmMessage(\n messageData, \/\/ CSwarmMsg or raw data\n protocolID, \/\/ application-defined protocol identifier\n true \/\/ only to authenticated peers\n );\n}\n<\/pre>\n
Message Authentication and Privacy<\/h3>\n
Swarms support two security modes:<\/p>\n
\n
Open Swarms<\/strong> (eSwarmAuthRequirement.open<\/code>) \u2014 Any peer can join and participate. Data channels are still encrypted by WebRTC’s built-in DTLS, but there is no application-level authentication.<\/li>\n
Private Swarms<\/strong> (eSwarmAuthRequirement.PSK_ZK<\/code>) \u2014 A pre-shared key is required. Peers must prove knowledge of the key using a zero-knowledge proof (the key image is a SHA3-256 hash with a time-based nonce). Unauthenticated peers receive only dummy tracks (silent audio, black video) until they authenticate.<\/li>\n<\/ul>\n
\n\/\/ Make a swarm private with a shared password\nawait swarm.setPreSharedKey('my-secret-password');\n\/\/ This triggers: swarm.authRequirement = eSwarmAuthRequirement.PSK_ZK\n\/\/ All current peers are required to re-authenticate\n\n\/\/ Or via command processor:\nawait swarm.processCommand('\/setkey my-secret-password');\n<\/pre>\n
Part III: WebRTC Swarms<\/h2>\nA WebRTC Swarm: each browser connects directly to every other browser. The signaling node (GRIDNET full node) brokers initial connections; after that, all traffic is peer-to-peer.<\/figcaption><\/figure>\n
What is a Swarm?<\/h3>\n
A WebRTC Swarm<\/strong> in GRIDNET OS is a managed mesh network of browser-to-browser connections. Each “swarm” is identified by a unique ID, and all participants who join the same swarm ID are connected to each other in a full-mesh topology \u2014 every peer has a direct RTCPeerConnection<\/code> to every other peer.<\/p>\n
The architecture involves three layers:<\/p>\n
\n
CSwarmsManager<\/code><\/strong> (\/lib\/SwarmManager.js<\/code>) \u2014 The singleton manager that handles swarm lifecycle, media device management, and signaling routing. Accessed via CVMContext.getInstance().getSwarmsManager<\/code>.<\/li>\n
CSwarm<\/code><\/strong> (\/lib\/swarm.js<\/code>) \u2014 Represents a single swarm instance. Manages the collection of peer connections, event dispatching, authentication, and data broadcasting.<\/li>\n
CSwarmConnection<\/code><\/strong> (\/lib\/swarmconnection.js<\/code>) \u2014 Represents a single peer-to-peer connection within a swarm. Wraps an RTCPeerConnection<\/code> with data channel management, track management, and authentication.<\/li>\n<\/ol>\n
Swarm Lifecycle<\/h3>\n
Creating \/ Joining a Swarm<\/h4>\n
\n\/**\n * CSwarmsManager.joinSwarm()\n * @param {ArrayBuffer} trueSwarmID \u2014 Human-readable swarm ID (hashed internally)\n * @param {ArrayBuffer} userID \u2014 User identity (empty = session identity)\n * @param {ArrayBuffer} privKey \u2014 Private key for auth (empty = session key)\n * @param {number} capabilities \u2014 eConnCapabilities flags\n * @param {CWindow} appInstance \u2014 Your dApp window instance\n * @returns {COperationStatus|false}\n *\/\nconst mgr = CVMContext.getInstance().getSwarmsManager;\nconst tools = CTools.getInstance();\n\nconst result = mgr.joinSwarm(\n tools.convertToArrayBuffer('my-collab-room'),\n new ArrayBuffer(),\n new ArrayBuffer(),\n eConnCapabilities.data, \/\/ or eConnCapabilities.audioVideo for video calls\n this \/\/ your CWindow instance \u2014 auto-cleaned up when window closes\n);\n<\/pre>\n
How it works internally:<\/strong><\/p>\n\n
The true swarm ID is hashed with SHA3-256 and Base58Check-encoded to produce the network swarm ID.<\/li>\n
A new CSwarm<\/code> instance is created (or an existing one is reused) and added to the manager.<\/li>\n
An SDP “joining” entity (eSDPEntityType.joining<\/code>) is constructed, optionally authenticated with a Transmission Token, and sent to the full node via CNetMsg<\/code>.<\/li>\n
The full node registers the peer and begins brokering connections with other swarm members.<\/li>\n
Your dApp instance is registered as a client process of the swarm \u2014 when your window closes, the swarm automatically cleans up.<\/li>\n<\/ol>\n
This sends an SDP “bye” entity to the signaling node, closes all peer connections in the swarm, and releases resources. Swarms also auto-terminate<\/strong> when all client dApp processes have been unregistered (controlled by the killWhenNoProcesses<\/code> flag, which defaults to true<\/code>).<\/p>\n
Sending Data in a Swarm<\/h4>\n
\nconst swarm = mgr.findSwarmByID(tools.convertToArrayBuffer('my-collab-room'));\n\n\/\/ Broadcast to all peers\nswarm.sendData(\n tools.convertToArrayBuffer(JSON.stringify({ type: 'update', data: myPayload })),\n null, \/\/ null target = broadcast\n true \/\/ only to authenticated peers (relevant for private swarms)\n);\n\n\/\/ Send to a specific peer\nswarm.sendData(\n tools.convertToArrayBuffer(myData),\n peerID \/\/ ArrayBuffer \u2014 the specific peer's ID\n);\n\n\/\/ Send a structured swarm message with protocol ID\nswarm.sendSwarmMessage(messageData, myProtocolID, true);\n<\/pre>\n
Receiving Data<\/h4>\n
\n\/\/ Level 1: Raw DataChannel messages (lowest level)\nswarm.addDataChannelMessageEventListener(function(event) {\n \/\/ event contains raw DataChannel message event\n}, this.getProcessID);\n\n\/\/ Level 2: Parsed messages (CNetMsg encapsulated)\nswarm.addMessageEventListener(function(event) {\n \/\/ event is parsed and includes connection\/peer metadata\n}, this.getProcessID);\n\n\/\/ Level 3: Swarm-level messages (highest level, includes protocol ID)\nswarm.addSwarmMessageEventListener(function(event) {\n \/\/ event includes protocolID for application-level routing\n}, this.getProcessID);\n<\/pre>\n
\nswarm.addPeerAuthResultListener(function(event) {\n \/\/ event contains authentication result for a specific peer\n \/\/ In private swarms, unauthenticated peers only see dummy tracks\n console.log('Peer authentication result:', event);\n}, this.getProcessID);\n<\/pre>\n
Part IV: Building a Real Feature \u2014 Collaborative Notes dApp<\/h2>\n
Let’s combine all three capabilities \u2014 files, messaging, and swarms \u2014 into a single, practical application: a Collaborative Notes dApp<\/strong> where multiple users can edit shared notes in real-time, with changes persisted to the blockchain.<\/p>\n
This dApp demonstrates the three pillars working together:<\/p>\n
\n
File System:<\/strong> Notes are saved to \/collab\/collab-notes.txt<\/code> on the decentralized file system and committed to the blockchain.<\/li>\n
WebRTC Swarm:<\/strong> When users join the same room name, they connect via a WebRTC swarm and receive real-time content updates from peers.<\/li>\n
Blockchain Persistence:<\/strong> The “Commit to Chain” button permanently stores the current note content on the blockchain \u2014 a timestamped, immutable snapshot.<\/li>\n<\/ul>\n
Part V: Error Handling and Edge Cases<\/h2>\n
Connection Drops<\/h3>\n
GRIDNET OS handles disconnections at multiple levels:<\/p>\n
\n
WebSocket disconnection:<\/strong> The CVMContext<\/code> connection controller automatically attempts reconnection. The commit lock is broken on disconnect, and all swarms are dissociated. Listen for eConnectionState.disconnected<\/code> via addConnectionStatusChangedListener()<\/code>.<\/li>\n
WebRTC peer disconnection:<\/strong> Individual CSwarmConnection<\/code> instances detect ICE disconnections and clean up. The swarm remains active and will re-establish connections when the peer returns.<\/li>\n
Commit during disconnect:<\/strong> If a commit is in progress when the connection drops, the commit state transitions to eCommitState.aborted<\/code> and the commit lock is forcefully broken.<\/li>\n<\/ul>\n
![\"Decentralized](\"https:\/\/gridnet.org\/wpp\/wp-content\/uploads\/2026\/02\/building-real-things-filesystem-arch.svg\")
![\"File](\"https:\/\/gridnet.org\/wpp\/wp-content\/uploads\/2026\/02\/building-real-things-commit-lifecycle.svg\")
![\"P2P](\"https:\/\/gridnet.org\/wpp\/wp-content\/uploads\/2026\/02\/building-real-things-messaging-flow.svg\")
![\"WebRTC](\"https:\/\/gridnet.org\/wpp\/wp-content\/uploads\/2026\/02\/building-real-things-swarm-mesh.svg\")