PlebDevs
PlebDevs is where a beginner can move from first code editor setup to Lightning and Nostr app experiments. The interesting part for Nostr readers is not only the lessons; the platform itself uses Nostr-native content, relay reads, NIP-05 identity, zaps, badge events and Lightning payment plumbing.
What PlebDevs really is
PlebDevs is a developer education community and platform for people who want to build with Bitcoin, Lightning, Nostr and adjacent privacy-minded tools. The live site frames the promise in plain language: learn to code, build on Bitcoin, become a developer. The same page describes the platform as developer education, content and community built on Nostr and fully Lightning integrated. That makes PlebDevs more than a YouTube channel and less than a protocol standard. It is a learning surface, a community doorway and an open-source platform experiment at the same time.
You should not read PlebDevs as a wallet, a relay operator, a Nostr client replacement or a custody service. It does not become the source of truth for NIP behavior just because it teaches Nostr and uses Nostr. Its job is to help a learner cross the gap from curiosity to hands-on building: code editor setup, GitHub, HTML, CSS, JavaScript, React, Lightning wallet basics, backend work, LND, LNURL, Nostr Dev Kit, Nostr Wallet Connect, Cashu, AI tooling and project workflow.
That education role matters in the Nostr ecosystem because protocols do not spread only through specs. They spread when builders can copy working patterns, break demo apps, inspect source code, watch a workshop, then ship a small thing of their own. PlebDevs is strongest when you treat it as a guided workbench: open a course, open the matching repo, run the code locally, compare it to the relevant NIPs, and keep asking what happens to keys, relays, payments and user trust in the real world.
The current public doorway
The live PlebDevs homepage checked on June 13, 2026 says the platform is built around Bitcoin, Lightning and Nostr. It shows three important signals for a reader: Nostr-native content formats, Lightning integrated, and more than 1000 students enrolled and supported. It also says zaps are enabled while all content is free. That last detail is important because older repository text still describes paid content and subscriptions; the current public product message is free access while the platform keeps improving.
The visible library is split into courses, videos and documents. Courses include the Adversarial AI Course, the Starter Course, a Lightning wallet backend course and a Lightning wallet frontend course. Videos include a Nostr Wallet Connect workshop, Cashu protocol overview, Lightning Login, Lightning Address, LND interfacing, node dashboard work and MutinyNet/Voltage development. Documents include AI review workflows, local AI tooling, React setup, Node.js backend walkthroughs, Pleb Node app templates and language cheatsheets.
That mix tells you what PlebDevs is trying to become. It is not only a linear school with one syllabus. It is a content shelf for builders, with short videos, long courses, reusable code, templates and written guides. A new learner might start with the starter course. A Lightning developer might open the LND or NWC workshop. A Nostr builder might inspect the NDK basics repo. An AI-assisted developer might use the newer privacy and security guides. The platform is trying to hold those paths in one place.
Two platform generations
There are two important platform code paths to keep separate. The older `AustinKelsay/plebdevs` repository is a JavaScript Next.js application with a README that documents the original PlebDevs platform architecture. It is public, MIT-licensed, describes NIP-23 content, NIP-51 course lists, NIP-99 monetization, NIP-47 automated subscriptions, NIP-58 badges, NIP-05 identity and NIP-57 zaps, and was pushed in January 2026. It is still useful because it exposes many concrete implementation choices.
The newer `pleb-devs/plebdevs-platform` repository is the more current TypeScript platform track. Its README calls the project a Nostr-native course platform built with Next.js, forkable as a white-label learning hub with Lightning payments and decentralized content. It describes a hybrid data model where PostgreSQL stores users, purchases, progress, prices and relations while Nostr relays store content via NIP-23 and NIP-99. It also lists NIP-01, NIP-07, NIP-19, NIP-23, NIP-51, NIP-57 and NIP-99 as used by the platform.
This matters because readers can easily mix claims across eras. The live homepage is the product doorway. The old repo explains many features that may have existed or informed the build. The newer platform repo explains the direction and architecture of the platform base. A careful reader should compare all three before making a hard claim about what is live today. The article can say PlebDevs is Nostr-native and Lightning-integrated; it should also say you need to verify the exact current behavior before relying on a payment, identity or badge path.
Why Nostr is not decoration
The older platform README says PlebDevs publishes content to Nostr and actively pulls from Nostr relays, creating a distributed trail of documents, videos and courses. The code backs that up. The NDK context builds an NDK instance from default relays plus user relays, enables the outbox model, uses `wss://nos.lol/` as an outbox relay, and adds a Dexie cache adapter. That is not merely a share button. It is a client-side Nostr reading layer inside the learning platform.
The document and video hooks fetch Nostr events of kinds `30023` and `30402`, filter by author pubkeys and content IDs, and then check tags such as `t=document`, `t=video` and `d=
That design is exactly the kind of practical Nostr compromise readers should understand. The database still matters. PlebDevs needs accounts, progress, purchases, drafts, pricing, relations, submissions and admin state. Nostr relays carry signed content and public learning objects. The user sees one web app, but the architecture is split. The useful lesson is not that everything is magically decentralized; it is that content portability can coexist with normal web-app state when the boundaries are visible.
Content kinds and course structure
PlebDevs uses familiar Nostr content patterns for educational material. NIP-23 long-form content maps naturally to written lessons and documents. NIP-99 paid-content events map to resources where metadata remains visible even when bodies or access rules may be controlled. NIP-51 list structures map to courses: a course is not just one article, but an ordered collection of resources and lessons. The old README explicitly describes documents as Markdown posted as NIP-23 events, videos as formatted Markdown documents with rich media, and courses as Nostr lists combining multiple documents and videos into a learning path.
The Prisma schema in the old platform shows why a local database still exists. There are models for users, sessions, accounts, roles, resources, drafts, courses, lessons, user lessons, purchases, user courses, platform NIP-05 records, Lightning addresses, badges and user badges. That gives the platform ordinary learning-management features: started and completed states, lesson progress, course submissions, pricing, ownership and profile data. If you are evaluating PlebDevs as a builder, this schema is a reality check against any simplistic claim that the entire school lives only on relays.
For a learner, the practical consequence is simple. A course may be visible and portable as Nostr-linked content, but your private progress, account recovery state, purchases and admin workflows live in the platform. If you care about long-term access, save the public source links, inspect the course repository when one exists, and understand that platform convenience and protocol portability are different promises.
Authentication lowers the ramp
PlebDevs does not force every beginner to arrive with perfect Nostr key hygiene. The sign-in page supports Nostr login, email login, GitHub login, anonymous login and recovery login. The Nostr path uses a NIP-07 browser signer through NDK. Email, GitHub and anonymous flows can generate platform-managed ephemeral Nostr keypairs so non-Nostr users can still interact with the platform. That is a deliberate onboarding tradeoff.
The NextAuth code makes the split more concrete. Nostr login syncs a Nostr profile from relays, reads kind-0 profile fields and stores public profile data such as avatar, username, Lightning address and NIP-05. GitHub and email users can receive generated keypairs for protocol access. Anonymous users can reuse keys stored in browser local storage. A recovery provider accepts a recovery key for platform-generated accounts, and the sign-in UI warns users not to enter a personal Nostr nsec there.
That warning deserves attention. A platform-managed or recovery key can be useful for beginners, but it is not the same as keeping your primary Nostr private key in your own signer. If you use PlebDevs with your main Nostr identity, prefer a signer path and understand what you are authorizing. If you use anonymous or email login, understand that the platform may generate and retain key material needed for that account. The easier path is good for learning; it is not a reason to become careless with a high-value identity.
NIP-05 identity is live
PlebDevs also touches identity through NIP-05. The live `.well-known/nostr.json?name=plebdevs` response checked on June 13, 2026 resolved `plebdevs` to the hex pubkey `f33c8a9617cb15f705fc70cd461cfd6eaf22f9e24c33eabad981648e5ec6f741` and listed relays including `wss://nos.lol`, `wss://relay.damus.io`, `wss://relay.snort.social`, `wss://relay.primal.net` and `wss://purplerelay.com`. That gives the public PlebDevs identity a normal Nostr verification surface.
The old platform code also includes NIP-05 endpoints and models. A user can create, update, fetch or delete a platform NIP-05 record through authenticated API routes, while the public NIP-05 endpoint returns the name-to-pubkey mapping. The schema has `PlatformNip05` and user fields for `nip05`, making identity a first-class platform feature rather than a static JSON file committed once and forgotten.
Readers should still test identity claims directly. NIP-05 proves a domain-pubkey mapping at the time you check it; it does not prove that every social profile, GitHub account, video channel or course author using the PlebDevs name is controlled by the same actor. Before sending value, accepting badge claims or trusting a course announcement, compare the live NIP-05 response, the Nostr profile, GitHub links and the official website.
Lightning is part of the lesson
PlebDevs has always been especially close to Lightning app development. The live site highlights Lightning integration and zaps. Course I teaches a Lightning wallet frontend with HTML, CSS, JavaScript, React, API calls, LNbits, GitHub and Vercel. Course II moves into backend work with Node.js, Express, JWT authentication, local Lightning development, LND, SQL, Knex, frontend-backend integration and deployment. Workshop material covers Lightning Address, Lightning Login, LND interfacing, a node dashboard and a 20-minute Lightning wallet.
The platform code also shows Lightning not only as a subject but as infrastructure. The old app includes Bitcoin Connect, Alby SDK, Lightning tools, zap displays, purchase records, payment buttons and subscription state. The app configuration includes custom Lightning Address records with LND REST host, port, macaroon and min/max sendable fields. Even if current public content is free, those code paths explain the kind of platform PlebDevs has been building toward: learning material that can itself receive zaps, accept payments or connect to wallets.
This is where readers should separate education from custody. A workshop can teach you how to build a Lightning wallet. A platform can request an invoice or use a connected wallet to pay. Neither fact means PlebDevs should hold production funds for you, nor that a tutorial pattern should be copied directly into a business without review. Use the lessons to understand flows, then review wallet permissions, invoice verification, LND credentials, budgets, rate limits and threat models before shipping anything real.
NWC appears in two places
Nostr Wallet Connect appears both as curriculum and as platform plumbing. On the education side, the `pleb-devs/nwc-wallet-workshop` README says the repository is filled with comments to help learners build on Nostr and implement NWC. It points directly to NIP-47 for protocol questions and invites learners to go through code snippets, write the code manually, read comments, break things and implement more NWC methods. That is a strong teaching pattern because NWC is easiest to learn by seeing request methods and wallet permissions in motion.
On the platform side, the older PlebDevs app initializes Bitcoin Connect with `filters: ['nwc']`, imports Alby SDK, creates a new NWC client for recurring subscriptions, asks for `pay_invoice`, sets a max amount, chooses a monthly or yearly budget renewal and can also accept a manually entered NWC URL. It then uses a Nostr WebLN provider to send a payment and stores subscription state in the API. Whether or not that exact subscription path is live in the current free-access product, the code is a concrete NWC implementation to study.
That also means there are real user risks to explain. An NWC string is a capability. If it is too broad, too long-lived or pasted into the wrong place, it can authorize payments you did not intend. The PlebDevs UI text around manual NWC asks users to set a budget at least as large as the subscription amount and set the correct renewal period. A safer reader should go further: use a separate low-limit wallet connection, avoid pasting unrestricted NWC URLs, revoke old connections, and treat screenshots of wallet permissions as sensitive.
NDK workshops make the protocol tangible
The NDK basics repository is one of the clearest examples of PlebDevs making Nostr practical. It teaches a simple app that can fetch a note or profile and update a profile. The README installs `@nostr-dev-kit/ndk` and `nostr-tools`, creates an NDK instance, connects to relays such as `wss://relay.damus.io` and `wss://relay.primal.net`, decodes `npub` and `note` strings with NIP-19 helpers, fetches kind-0 metadata and signs a profile update with a NIP-07 browser extension signer.
The Next.js NDK template repo expands the same idea into reusable app structure. It shows a React context provider, a global NDK instance, relay connection, a `subscribeAndHandle` helper, filters, subscription callbacks and a basic kind-1 event feed. It is beginner-friendly without hiding the key concepts: relays, filters, event kinds, signer paths and the difference between reading and writing.
Those small workshops are valuable because they teach the grammar before the grand theory. A learner can see that a Nostr app is not magic. It connects to relays, requests events with filters, decodes identifiers, renders event content, asks a signer to authorize writes and publishes signed events. Once that model clicks, larger systems such as PlebDevs, Nests, NWC apps and zap-enabled media tools become easier to reason about.
Badges turn learning into events
The older platform repo also includes a badge issuer that deserves attention. The API route verifies that a course is completed, checks whether a required repository submission exists, looks up the badge definition, prevents duplicate awards, builds a kind-8 badge award event, references the badge definition, signs the event with a configured signing key, verifies it with `nostr-tools` and publishes it to configured relays through a `SimplePool`. The badge is then stored in the database as a user badge.
That is a strong example of where Nostr fits education. A course completion can become more than a row in a private learning-management database. It can be a signed public event that other clients, portfolios or communities may inspect. The model still depends on a platform signing key and the trust people place in PlebDevs as the issuer, but the claim can travel beyond the original website.
The risk is credential inflation. A badge event says a particular issuer awarded a particular thing to a pubkey. It does not automatically prove job readiness, code quality, identity continuity or that the learner completed the work without help. For readers, the right posture is balanced: badges are useful portable receipts, especially for beginner achievements, but serious hiring or collaboration still needs source repos, code review, conversation and evidence of current skill.
Community remains the support layer
PlebDevs is also a community, not only a website. The GitHub organization profile links the website, Discord community, YouTube channel and repository list. The old platform README lists Nostr-based chat as read/write and Discord plus Stacker News `~devs` integration as read-only. The live and repo materials show the project trying to unify content, workshops, source code and social support in one learning environment.
That support layer is especially important for beginners. Bitcoin, Lightning and Nostr development can feel hostile if the first error is a broken invoice, a failed relay connection, a missing signer, a CORS problem or a database migration. PlebDevs lowers the psychological cost by giving people a place to ask, watch, copy, break and try again. The best developer education is rarely only a polished lesson; it is a loop of material, source, feedback and repetition.
The tradeoff is that community advice ages. A Discord answer, a workshop recording or a Stacker News comment may be correct for a specific date, dependency version or testnet. When money, identity or production infrastructure is involved, treat community help as a pathfinder. Confirm it against source code, current docs, package versions, NIPs and a small test environment before you teach it to someone else or ship it.
The AI program broadens the scope
The newer PlebDevs organization is not limited to Bitcoin and Lightning basics. The AI Development Program frames itself as adversarial AI for developers: freedom-focused, privacy-first and useful for people building Bitcoin technologies with AI-enhanced workflows. Its README says lesson 1 of the free AI Development Program is live, and points to AI Guides, Freedom Tech and New Project Boilerplate repositories.
That may look like a detour from Nostr, but it fits the builder audience. The AI Guides focus on coding agents and clients such as OpenCode, Goose, Ollama, Maple and SearXNG with sections for privacy, security, cost and safe operation. Freedom Tech catalogs sovereignty-focused libraries across Bitcoin, Lightning, Ecash, Nostr, cryptography, privacy, storage, messaging and auth. New Project Boilerplate teaches a documentation-first workflow for AI-assisted projects.
For a reader, the implication is that PlebDevs is becoming a wider builder-school for adversarial environments, not only a Lightning tutorial archive. That is useful, but it also raises quality expectations. AI-assisted development needs careful review. PlebDevs says the Adversarial AI course teaches threat modeling, prompt-injection awareness, secure workflows and hardening. A good learner should take those warnings seriously and not ship generated payment or key-management code just because it passes a happy-path demo.
Self-hosting is possible, not casual
Both platform generations invite builders to inspect or fork the platform. The older README lists Docker, PostgreSQL, Redis, optional Lightning node and optional Nostr relay as self-hosting requirements. The newer platform README gives a quick start with Node.js, PostgreSQL or Docker, Prisma setup and a Next.js development server, and describes configuration files for auth, theme, content, copy, payments, Nostr relays and admin pubkeys.
That is encouraging for educators who want their own Nostr-native course platform, but it is not a one-click blog install. A real deployment needs a database, session secrets, OAuth credentials if enabled, email settings, encrypted private-key handling, allowed origins, rate limiting, view counters, migration discipline, cron secrets, CORS decisions, relay configuration, payment settings and branch protection if you care about production quality. The newer README even includes a CI gate with lint, typecheck, tests and build.
The strongest use case for self-hosting is not to copy PlebDevs branding. It is to understand the pattern: keep sensitive account and progress state in your database, publish portable content events to relays, let users sign where possible, accept zaps or payments with clear limits, and expose enough code that learners can audit the system. If you fork it, budget time for security, moderation, backups, key handling and stale dependency maintenance.
What to test before relying on it
If you are using PlebDevs as a learner, test the simple things first. Open the current site, browse a course without signing in, start a free lesson, then sign in with the identity path you actually want to use. If you use Nostr login, confirm the signer prompt makes sense and the profile that appears is yours. If you use email, GitHub or anonymous login, understand that the account may use generated Nostr keys for platform access.
If you are testing the Nostr side, verify the live NIP-05 mapping, inspect relay behavior, compare the content you see in the web app with the relevant Nostr event kinds, and open the matching source files. For NDK or NWC workshops, run the sample app locally with test relays or test wallets before involving real funds. Check package versions, especially NDK, nostr-tools, Bitcoin Connect, Alby SDK, snstr and zapthreads, because Nostr tooling changes quickly.
If you are testing the payment side, use tiny amounts and low-limit wallet connections. Confirm which Lightning address or invoice endpoint is actually live today. The checked `plebdevs.com/.well-known/lnurlp/plebdevs` path returned 404 on June 13, 2026, while repository materials mention support addresses and payment flows. That is not a contradiction; it is a reminder to test the current endpoint rather than assuming every historical README feature is live on the current domain.
Where the risks sit
The first risk is stale learning material. Workshops from 2023 and 2024 can still be excellent, but Nostr libraries, relay behavior, NWC wallet support, Lightning development sandboxes and package APIs move. A learner should use old workshops to learn concepts and then compare against current package docs and repository commits. When a tutorial asks you to install dependencies, inspect the version it expected and the version you are actually getting.
The second risk is identity confusion. PlebDevs uses Nostr, NIP-05, GitHub, email, anonymous accounts and recovery keys. That flexibility is good for onboarding, but a user can misunderstand which key controls what. Do not paste your primary nsec into a recovery form. Do not assume a generated anonymous account is your long-term public identity. Do not assume GitHub account linking proves Nostr identity. Keep a small test identity for workshops until you understand the flow.
The third risk is money movement. Zaps, Lightning invoices, NWC strings, LND credentials, macaroons and paid-content patterns can all show up around PlebDevs material. Use test networks where possible, create low-limit NWC budgets, revoke unused connections, avoid sharing payment screenshots with sensitive metadata, and never copy environment variables from a tutorial into production without understanding them. The best education platform teaches you to be slower with secrets than with code.
Why PlebDevs matters
PlebDevs matters because Nostr needs more than social users. It needs people who can build small clients, wallet integrations, course platforms, relays, content tools, payment flows and weird prototypes that reveal where the protocol is strong or weak. A beginner-friendly education surface is infrastructure for the human side of the network.
It also matters because it shows a practical path for Nostr-native publishing outside the normal microblog feed. A course is a structured object. A document can be long-form. A video can be represented as content with metadata. A badge can be a signed award. A zap can support a resource. A NIP-05 identifier can help users find the project. None of that requires turning PlebDevs into a general social client.
The project is most convincing when it stays honest about its hybrid nature. Databases, OAuth, email, GitHub, relays, signers, Lightning nodes, NWC connections and public Nostr events all have a place. The learning opportunity is seeing how those pieces fit. If a student leaves PlebDevs understanding those boundaries, they are already ahead of many people who can repeat slogans but cannot debug a failed relay fetch or a wallet permission screen.
Closeout
PlebDevs belongs in this guide because it is one of the clearer bridges between learning and building. You can open it as a beginner and find starter courses. You can open it as a Lightning developer and find app workshops. You can open it as a Nostr developer and find NDK, NWC, NIP-05, content events and badge flows. You can open its repos and inspect how the platform tries to make education itself Nostr-aware.
Use it with the right expectations. PlebDevs is education and community first. It is also an open-source platform experiment. It is not a substitute for the NIPs, not a wallet security authority, not a promise that every old paid or subscription feature is live today, and not a reason to relax around private keys or wallet permissions. The more a lesson touches identity or money, the more you should test with a throwaway identity and low-value wallet first.
The strongest reading of PlebDevs is hopeful and practical: a builder school that teaches Bitcoin and Nostr by shipping code in public. If that model spreads, the ecosystem gets more people who know how to build, not just how to post. That is the kind of adoption Nostr needs: patient, technical, slightly scrappy, and grounded enough to turn curiosity into working software.
Sources worth opening
Start with the live PlebDevs site, the PlebDevs GitHub organization profile, the older AustinKelsay platform repository, the newer pleb-devs/plebdevs-platform repository, the platform README files, the app configuration, NDK context, Nostr content hooks, Bitcoin Connect and NWC payment components, authentication code, badge issuer and live NIP-05 response. Then compare the workshop repos for NWC, NDK basics, Next.js NDK templates and Lightning wallet exercises with NIP-01, NIP-07, NIP-19, NIP-23, NIP-47, NIP-51, NIP-57, NIP-58 and NIP-99 before treating any learning platform feature as production wallet guidance.
- PlebDevs live site
- PlebDevs GitHub organization
- PlebDevs organization profile README
- AustinKelsay/plebdevs repository
- AustinKelsay/plebdevs README
- AustinKelsay/plebdevs package file
- AustinKelsay/plebdevs Prisma schema
- PlebDevs app configuration
- PlebDevs NDK context
- PlebDevs document hook
- PlebDevs video hook
- PlebDevs course hook
- PlebDevs Bitcoin Connect component
- PlebDevs subscription payment component
- PlebDevs sign-in page
- PlebDevs NextAuth configuration
- PlebDevs Nostr account linking route
- PlebDevs badge issuer route
- PlebDevs public NIP-05 response
- pleb-devs/plebdevs-platform repository
- pleb-devs/plebdevs-platform README
- pleb-devs/plebdevs-platform package file
- PlebDevs workshops repository
- PlebDevs workshops README
- PlebDevs NWC wallet workshop
- PlebDevs NWC wallet workshop README
- PlebDevs NDK basics repository
- PlebDevs NDK basics README
- PlebDevs Next.js NDK template
- PlebDevs Next.js NDK template README
- PlebDevs 20-minute Lightning workshop
- PlebDevs AI Development Program
- PlebDevs AI Development Program README
- getAlby awesome-nwc education listing
- NIP-01 basic protocol flow
- NIP-07 browser signer capability
- NIP-19 bech32 encoded entities
- NIP-23 long-form content
- NIP-47 Nostr Wallet Connect
- NIP-51 lists
- NIP-57 zaps
- NIP-58 badges
- NIP-99 classified listings
- Nostr Dev Kit
- nostr-tools
- Bitcoin Connect
- Alby JS SDK
- ZapThreads
- PlebDevs YouTube channel
- PlebDevs Nostr profile via nostr.band
