Member handbook

GBTI Network has no website login. Your identity lives in the GBTI browser extension, which is also your reading and publishing workbench. Install it, then click the toolbar icon to open the setup wizard.

Setup is three steps, each backed by durable GitHub state, so you can never lose progress:

1. Sign in with GitHub. A device sign-in: visit the URL, enter the code. No password or secret is ever stored in a page.
2. Make your copy. Fork the public content repository from the GitHub UI. Your fork is where your drafts live.
3. Give access. Install the GBTI GitHub App scoped to that one forked repository, so the workbench can stage and publish for you.

Access comes in four tiers. Signed out, you can browse the public site. Free (signed in with any GitHub account, no card) adds the reading perks: follow the news feed, save favorites, build collections, follow members and topics. The trial (90 days, no card) adds the member Shares stream, draft authoring on your own fork, and read-only Discord. Paid ($150 per year) unlocks publishing, contributions, comments, member-only content, and the full Discord community. The membership page has the complete comparison.

After setup, a welcome view walks you through the first two moves: join the Discord (your invite is minted on demand) and discover members to follow. Following gives you a feed of what those members publish.

When your content merges, it enters the syndication queue and posts outward to the network channels with attribution to you. You publish here once and skip the re-posting by hand.

Live today: Discord. Every published item posts to the shared #shares channel and a second time to its mapped category channel. Posts credit you by name, and when your Discord account is linked, as a real @mention.

Being provisioned: X, LinkedIn, and Bluesky adapters are built or in progress but switched off until their accounts and tokens are approved. Reddit is planned. Substack is manual only: it has no public posting API, so anything on Substack is cross-posted by hand. We list a channel as live only when it actually is.

Items post automatically after a 60 minute hold window, which is also your cancel window. Posts are shaped by per-channel templates; anything a moderation filter flags waits for human approval instead of auto-posting.

Members-only content never leaks through syndication. An outbound post for a members-only item carries the title and link only, never the body; the queue is structurally incapable of carrying a gated body.

Membership is $150 per year. When a visitor becomes a paid member, the content that brought them in shares the revenue:

• 30% first touch: the author of the earliest member item in the visitor's journey.
• 10% last touch: the author of the final item before they joined.
• 5% collaboration pool: shared equally by members whose comments or accepted contributions live on those two items.
• 55% platform: keeps the network running.

A separate invite lane pays a flat 10% lifetime commission on anyone who joins through your personal invite link, funded from the platform share so content earnings are never diluted. No double dip: if you already earn a content share on a conversion, you take the larger of the two, not both.

Attribution uses a 90 day window, splits freeze at conversion, and payouts settle after a 90 day hold (refunds and chargebacks come out first). Your profile page counts as an entry point too: a visitor who lands on your profile and later joins credits you without any special link. Payouts arrive via Stripe Connect.

The full explainer, with the worked example, every rule, and the FAQ, lives on the revenue model page.

You author through either of two surfaces, and both use the same flow. The extension workbench gives you a workspace (your articles, prompts, products, and their pull requests), a browse view, and an in-extension reader. The npm CMS (gbti-network) runs a local editor in your browser plus an MCP server, so your AI agents can author through the exact same guarded flow you do.

Under the hood every edit is fork, branch, pull request against the public content repository. The membership gate is the only authority on what merges; the tools handle the git motions for you. Your content lives in your own folder (members/<username>/) with posts, products, prompts, and images, and your pull requests auto-merge only inside that folder.

During the trial, drafts stay on your fork; nothing you stage reaches the canonical repository. Publishing is for paid members. The moment you upgrade, the workbench publishes your staged drafts.

Paid members can also contribute to one another member's folder. That pull request waits until the folder owner approves it with a GitHub review, then merges with you credited as a contributor.

Content can be public or members-only. Members-only supports a whole gated item, a public teaser stub with a locked body, or a public item with one gated section. Gated bodies are encrypted and unlock through the membership service. One honest caveat: an authorized member can always copy what they read, so treat member-only as a perk boundary and keep real secrets out of content.

The network is local-first and git-native. The public git repository is the database; the static site is its published read view; your workbench is your own authoring node. Content syncs through membership-gated pull requests. There is no separate application database.

Stripe is the only registry. Your GitHub id keys a Stripe customer; membership status is derived from it (an active subscription means paid, a card-less customer inside 90 days means trial). Every membership check fails closed: on any doubt, the system treats an account as not paid rather than guessing.

The site builds with Astro and deploys to Cloudflare Pages; one Cloudflare Worker handles signup, membership checks, and member-content encryption. The merge gate and the daily reconcile run as GitHub Actions. Nothing is always-on, and hosting costs stay near zero.

The repository is public and anyone can open a pull request, but the gate reads metadata only and never executes submitted code, auto-merge is scoped to your own folder, and the governance files are code-owned. Roles and permissions are structurally out of reach of a content pull request.

Nothing is deleted when membership lapses. Content flips to draft and comes back exactly as it was when you resubscribe.

Everything about you lives in exactly one of three homes, chosen by what the data is. There is no hidden application database.

• Published works (your profile, posts, products, prompts, and comments) live in the public git repository, which is public on purpose: your work stays versioned and portable under your own name.
• Billing identity lives in Stripe and only in Stripe. Your email is passed straight to your Stripe customer at signup; the platform keeps no email store of its own.
• Preferences and activity (favorites, collections, who and what you follow, your news and category preferences) live in a deletable edge store keyed by your GitHub id. None of it ever reaches the immutable git history.

Some preferences never leave your device at all: your theme, the new-tab splash settings, and any splash background image you upload stay in your own browser storage, on this device only.

The only activity-shaped things committed to git are member-identity-free aggregates: a favorite count per item, and the opt-in "favorited by" list for members who explicitly turn that on. Usage analytics are aggregate and PII-free by construction (a tier bucket and an event name, never an id, login, or address).

The split is what erasure depends on. Deleting your account hard deletes the edge-store data and unpublishes your works. The honest limit: the content repository is public, so copies in third-party forks, caches, and archives cannot be guaranteed gone, and the privacy policy says so plainly. Backups of the edge-store data are encrypted and retention-bounded, so deleted data ages out of them too.

When you mark content member-only, the gated markdown is encrypted with AES-256-GCM into an envelope file, and only that ciphertext is committed to the public repository. The encryption key never leaves the membership service: your client sends ciphertext up to decrypt (reading) or plaintext up to encrypt (publishing), and the service answers only a caller whose membership checks out as paid. The key is never in the page, the extension, or the repository.

Three gating modes cover the shapes member-only content takes: a whole item with no public page, a whole item with a public teaser stub (a locked card with a join prompt), or a public item with one members-only section. The static site ships an inert locked placeholder either way; the extension upgrades it into the decrypted content for members.

Two guarantees hold at build time: gated plaintext never reaches the published site bundle (a build guard proves it), and the key rotates on a schedule with the old key destroyed, so ciphertext that sits in git history forever becomes unreadable. A compromise is bounded to one rotation window.

The honest framing we state everywhere: member-only encryption controls delivery, and it does not make content secret. A paying member is served the plaintext by design and can copy what they read; no client-side cryptography can stop an authorized reader. What it reliably does is stop anonymous scrapers and lapsed or banned accounts at the point of delivery. Do not put credentials, personal data, or anything catastrophic to disclose inside member-only content.

The community is the product. The Discord guild runs on three roles, exactly one per member, swapped automatically as your status changes: Member (paid, full access), Trial (read along while you evaluate), and Locked (lapsed or banned; you stay in the guild but the gated channels close). Nobody is ever kicked by the system.

The weekly two hour shop-talk session anchors the community: product development, publishing, business progress, technical decisions, and member coaching.

The #shares channel carries everything members publish, and each item posts again into its category channel, so following a topic means watching one channel. Trending developer news lands in the category channels too, curated by hand, so the channels stay readable.

Your invite arrives in the welcome view after setup (and signup can add you to the guild automatically when you link Discord). Roles follow your membership on their own; there is nothing to configure.

Your public profile is one file you own: members/<username>/profile.md. Edit it from the extension account page, or through the CMS and MCP like any other content. It publishes through the same pull request flow, and publishing a profile is a paid-member capability.

Fields you control: display name, headline, avatar (defaults to your GitHub avatar), location, roles and skills, social links, a for-hire flag, and directory: true to opt in to the member directory. Fields the system controls: your tier, your join date, and the author identity, which is always forced to the signed-in account.

Your profile page at /members/<username>/ also works as a revenue attribution entry point. A visitor who lands on your profile and later becomes a member credits you in the revenue split, no special link required.