Member handbook

Sign in at /login/ with your GitHub account. Choose Continue with GitHub, approve the authorization, and you are in. No password is stored in the page, nothing is installed, and you do not fork anything.

A free account is enough to read the network and to keep track of what you find. No card is requested and nothing is billed.

Access comes in three levels. 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. Network Supporter adds commenting across the network, the full Discord community, member-only content, the member Shares stream, and publishing your own articles, projects, and prompts. Published work goes out to members first, and a superadmin reviews it before it appears on the public site. The membership page has pricing and the complete comparison.

The browser extension is optional. It carries the same authoring surface as the website, and adds a new tab feed and a reader that keeps you inside the extension while you browse. Add it if you want those. Skip it and the website does everything, including editing and publishing your own work.

Two things are worth doing first. Join the Discord, where your invite is minted on demand, and follow a few members. Following is what builds your feed, because the feed is assembled from what the members you follow 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.

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.

Author from the WorkBench at /workbench/. It holds your articles, projects and prompts, their pull requests with live gate status, and the editor. The browser extension carries the same surface if you would rather work there, and both read the same drafts.

You can also edit something already published without leaving it. Open your own article, project or prompt on the site and an edit control appears on the page. It appears for the folder owner only, so nobody else sees it on your work and you do not see it on theirs.

Every change becomes a pull request against the public content repository, and the membership gate is the only authority on what merges. The tools handle the git motions. Your content lives in your own folder (members/<username>/) with posts, projects, prompts and images, and your pull requests auto-merge only inside that folder.

The website never forks the repository and never takes a GitHub token from you. Your drafts are held in your account, and publishing commits to a branch on the canonical repository through GBTI's own GitHub App. The extension works differently, staging on a fork of your own, which is why it asks for access the website does not need.

Publishing is included in the paid membership. On a free account you can write and keep drafts, and nothing you stage reaches the public repository until you join. When you do, your staged drafts are there waiting to publish.

What you publish goes out to members first. A superadmin then reviews it, and it appears on the public site once that review passes. Profiles and comments are exempt from that review. The full explanation of how the content platform works, the revenue program included, is at /submit-content/.

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, projects, 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 page ships a locked placeholder either way, and it unlocks in place once you are signed in as a member. The website does this itself, and so does the extension.

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 project. 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: project 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 /account/ or the WorkBench, or from the extension if you use it. It publishes through the same pull request flow, and publishing a profile is included in the paid membership. A profile is exempt from editorial review, so it is public as soon as the pull request merges.

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.