Architecture

Nibgate is built around a creator-owned origin, a package that gates content, a widget that verifies the site, and a hub that indexes metadata and events. On top sit two hosted rails — Subblogs and Nibshare — that reuse the same package, access rule, and encryption primitives.

System parts

The site that owns the content, routes, payment receiver, and unlock experience.

Creator site

The integration layer for gating, pricing, content events, unlocks, and receipts.

Nibgate package

The script that verifies the domain and streams browser-side activity signals.

Hub widget

The backend, dashboard, Explore index, analytics, and reputation layer.

Nibgate hub

Hosted blog rail (*.nibgate.xyz) — the package plus a full CMS, SIWE auth, and encryption.

Subblogs

Hosted quick-share rail (/ns/<slug>) — short-link gated content with no domain required.

Nibshare

Creator site

The creator site is the source of truth. It serves the public route, protects paid content, decides receiver addresses, and completes unlock flows.

Nibgate package

The package lives inside the creator app. It should gate resources, send content metadata, report unlock events, and attach receipt references after payment succeeds.

The stable unlock strategy is one_time: a buyer or agent pays once, the creator site verifies the receipt, then the server issues access. The package keeps an unlock policy field so later strategies can add metered video/audio streaming, section-based reading, time passes, and agent quotas without changing the core integration.

The wallet package (@nibgate/wallet/react) supplies the shared Reown wallet modal, SIWE sign-in, and the <NibgateUnlock> checkout component so every rail has one wallet UX.

The shared access rule

Both hosted rails and the SDK run one access decision (canAccess in @nibgate/sdk/server, packages/nibgate/src/server/access-policy.js) over three policy knobs — price, whitelist/whitelistPrice, and publicAccess. The rule’s order is: ban → invite-only deny → active paid entitlement → active free grant → valid bound proof → 402 challenge. A bare ?wallet= is a client claim, never an identity; possession comes from a bound unlock proof or a SIWE session wallet. Full detail: Whitelists & access control.

Encryption at rest

Every Subblogs post body and uploaded media file, and every Nibshare body and media blob, is AES-256-GCM encrypted before it reaches object storage (R2). Keys are envelope-wrapped with a backend-only KEK; only the wrapped key is persisted. Encryption is confidentiality at rest, not access control — free content is decrypted server-side and served to anyone, paid content only after proof. See Content encryption.

The widget proves the registered origin can serve the Nibgate token. It also streams page-level activity and helps scheduled verification checks confirm the site is still connected.

Nibgate hub

The hub receives verified metadata and events. It powers the creator dashboard, Explore, content analytics, earnings analytics, and future reputation surfaces.

End-to-end flow

Register site

The creator connects wallet and adds an origin.

Verify ownership

The creator pastes the widget and the backend confirms the homepage contains the data-nibgate-site marker for that site.

Publish metadata

The package sends structured content records for public discovery.

Gate and unlock

The creator site handles the protected route and payment flow. One verified payment unlocks one resource (lifetime entitlement). Streaming or metered unlocks are future adapters, not the default requirement.

Report events

The package reports views, unlocks, receipts, and content updates.

Build reputation

The hub turns verified interactions into content/source quality signals.

Reputation architecture

Nibgate should not require creators to mint each content item or route every payment through a Nibgate contract. Content remains on the creator site, and the creator site/package remains responsible for the unlock/payment flow.

The reputation layer can be split into three parts:

Content identity: deterministic content ids derived from verified site metadata.
Unlock eligibility: verified x402, Gateway, direct wallet, or future onchain payment receipts indexed by Nibgate.
Rating proof: onchain or attested ratings accepted only from wallets or agents with verified unlock eligibility.

Nibgate then indexes receipts and rating events and computes:

content reputation as 0.0-5.0 stars
site reputation as 1-100
creator reputation as 1-100