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

Nibshare and Subblogs assemble database facts and call the SDK’s canAccess rule over price, whitelist/tier and invite-only policy. The order is reachability → invite membership → ban/revoke → free/paid grants → valid proof → payment challenge. A generic SDK integration must wire its own persistence and policy facts; protect alone is a token/access-mode check, not a database-backed entitlement service. 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 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

Private research boundary

Dr. Nib’s private research architecture separates browser encryption, a ciphertext broker, verified Phala orchestration, encrypted state and a restricted money service. It is distinct from creator/server-side storage encryption. Actual JEV and authorized Azure/OpenRouter ZDR research processing receive disclosed context; ordinary Hub/MCP access does not unlock private projects.

Runtime resource boundaries

The hosted Hub and Subblogs APIs reuse a Prisma client per process. Their runtime defaults allow up to five PostgreSQL connections with a ten-second pool acquisition timeout; explicit connection-string settings take precedence. These are application pool bounds, not limits on database server memory or the total number of connections across services.

Image processing loads on demand with a bounded native cache, and Subblogs loads document parsers only for the format requested. Its tenant lookup cache retains at most 1,000 entries with a one-minute freshness window. These bounds reduce retained memory without changing encryption, payment verification or entitlement rules.

Sleeping web processes and financial reconciliation have different lifecycle requirements. Database traffic and background polling can prevent a service from sleeping. Preserve settlement and shutdown guards when changing deployment topology; enabling a hosting sleep setting alone does not establish that a service actually sleeps.