Building on DChat, DChat Guides

Building on DChat

The DChatSDK is the .NET library DChat's own Android client is built on: identity and key management, the message envelope and its transport over swarmchat's gRPC interface, groups and sender-key handling, media encryption and the IPFS upload flow, wallet and staking operations, and device provisioning through linked-device pairing and ConfigSync. What it does not include is the WebRTC media pipeline itself - the SIPSorcery integration, camera capture and encoder work described in the calls guide lives in the client application, not the SDK.

The SDK targets net10.0 plus Android, iOS, Mac Catalyst and Windows, using gRPC natively on native platforms and gRPC-Web when running under WebAssembly - the same protocol-level split that shows up elsewhere in this codebase wherever a browser client has to reach the swarmchat gRPC front door. Every piece of it - identity derivation, the ECDH-and-ChaCha20-Poly1305 message pipeline, sender-key distribution for groups, key rotation policy, and the at-rest wrapping of key material - is written up at parameter level in the cryptographic specification linked throughout this page, which exists specifically so an integrator does not have to reverse-engineer behavior from a binary.

What the SDK deliberately leaves to the app layer, beyond the media pipeline already noted: the chat and contact database is a local SQLCipher-encrypted SQLite file the app owns and manages, not something the SDK persists on an integrator's behalf, and the WebRTC signalling glue that turns SDK-level ephemeral messages into an actual live call is application code.

Here is the statement that matters most to anyone evaluating whether to build on it, said once and without hedging: the protocol is fully documented, but the SDK is not currently published as open source. There is no public repository and no published package. A third-party integrator today should expect documentation - this site, the specification, and separate SDK reference material - without source access or an installable package; building a client compatible with the network means either implementing the documented wire protocol independently, or working directly with DChat on a source-level engagement. The Enterprise page covers what that kind of arrangement looks like.

Two things the SDK explicitly does not enforce on an integrator's behalf are worth flagging before anyone assumes otherwise. First, post-removal group key rotation is a caller's job: the SDK exposes the rotation method, but nothing inside it fires automatically when a member is removed - a client that never calls it leaves departed members able to decrypt group traffic indefinitely, rather than only until the next routine rotation. Second, only the ciphertext field of the message envelope is confidential; sender DID, sender public key, chat id, key generation and encryption mode are cleartext by design at every layer, including inside the SDK, so any relay, logging system or analytics pipeline an integrator builds on top of received envelopes is handling metadata that was never protected in the first place.