Introduction

@beblurt/dblurt is a JavaScript and TypeScript SDK for applications that read from and write to the Blurt blockchain.

It gives application developers one practical package for read-only RPC calls, Nexus social/indexed queries, operation construction, local signing, broadcasting, browser usage and typed integration. The purpose of this page is to explain what the library is before you choose an API.

What dblurt is

dblurt sits between your application and Blurt infrastructure:

Your app, bot, dApp, dashboard or indexer
        |
        |  @beblurt/dblurt
        v
+-------------------------------+
| JSON-RPC client and helpers    |
| Typed Blurt data models        |
| Operation builders             |
| Local crypto/signing utilities |
| Nexus social/indexed helpers   |
+-------------------------------+
        |                  |
        v                  v
Blurt Layer 1        Nexus / Bridge Layer 2
consensus chain      indexed social views

Use dblurt when you want to build software that talks to Blurt from Node.js, a browser bundle or a TypeScript codebase without writing raw JSON-RPC plumbing for every call.

What dblurt is not

dblurt is not an application framework and it is not a wallet.

It does not decide:

• what a user is allowed to do;
• which content, account or community policy your app should enforce;
• how private keys are stored;
• whether a UI confirmation is sufficient;
• which RPC endpoints your production deployment should trust;
• whether a Nexus result is fresh enough for a security-sensitive decision.

Those are application and operator responsibilities. dblurt provides the SDK primitives.

Who it is for

dblurt serves several reader groups:

Reader	What they usually need first
Developers discovering Blurt	a safe read-only path and a small mental model
Hive or Steem developers	which concepts transfer and which Blurt assumptions differ
Blurt developers new to dblurt	a map from developer goals to helper families
TypeScript developers	public exports, types, overloads and error shapes
Maintainers	documentation ownership, validation and release workflows

The documentation is organized so concepts come before implementation details. If you know exactly which method you need, go to the API reference. If you are still choosing a surface, start with Choose your path.

What problems it solves

Reading chain data

Applications often need account state, content, witnesses, blocks or account history. dblurt wraps the Blurt JSON-RPC APIs through helper families such as client.condenser, client.database, client.accountHistory and client.blockchain.

Reading social/indexed data

Social interfaces often need ranked feeds, communities, profiles, discussions, notifications or referral views. dblurt exposes Nexus / Bridge data through client.nexus.

Building operations safely

Some workflows need to construct social or content operations without immediately signing or broadcasting them. dblurt includes typed operation builders so applications can preview, confirm, externally sign or test operation payloads.

Signing and broadcasting

When an application deliberately supplies the correct private key, client.broadcast can prepare, sign and submit transactions to Blurt Layer 1. This is intentionally not the first learning path.

Surviving endpoint failures

RPC endpoint failures are normal in blockchain applications. dblurt supports endpoint lists and failover behavior so applications are not tied to one URL.

The first mental model

The most important distinction is:

Blurt Layer 1 records canonical chain events and state.
Nexus Layer 2 indexes and presents application-friendly social views.

When exact chain truth matters, use Layer 1 helpers. When you are building discovery, feeds, profile or community interfaces, Nexus can provide more convenient views.

Learn this distinction next: Layer 1 and Nexus Layer 2.

Recommended path

1. Getting started — make a safe read-only call.
2. Blurt mental model — learn the domain vocabulary.
3. Layer 1 and Nexus Layer 2 — understand source-of-truth boundaries.
4. Choose your path — pick the correct helper family.
5. Accounts and authorities — understand keys before signing.
6. Read-only vs broadcast — understand side effects before calling broadcast helpers.