Rules?

Peer-to-Peer Charity System on Nostr – Core Principles & Boundaries

Core Philosophy This is a distributed, no-custody charity network built on Nostr + Lightning. The system exists to provide transparent, verifiable accountability for donors while enabling genuine peer-to-peer human connection.

Recipients and sponsors are free individuals. They can do whatever they want on plain Nostr (including asking for zaps or running completely independent campaigns). However, inside this system there is a clear social contract: reciprocity and respect for the shared mechanism that connects sponsors to recipients.

Key Definitions (not just rules)

  • DirectSponsor System = A structured, transparent support mechanism where:
    • Recipients have a small group of regular sponsors who commit to monthly support.
    • The goal is self-sufficiency within ~3 years.
    • Additional needs (premises, tools, etc.) are handled through public fundraisers open to anyone.
    • All money flowing through the system is requested publicly, invoiced via Lightning, confirmed via read-only wallet monitoring, and recorded in a public Nostr ledger.
  • What DirectSponsor is NOT:
    • A private begging channel.
    • A way to get sponsors through the system and then pull them off-books for extra/untracked money.
    • A tool that recipients can use one-way without reciprocity.

Asking a regular sponsor for money privately (after they were connected through the system) is considered abuse of the tool. It undermines the transparent accounting that everyone relies on and is unfair to other participants who play by the shared expectations.

Private Messaging Private chats are fully supported and encouraged for real human coordination and relationship building. However, private money requests directed at sponsors acquired through the system are explicitly outside the definition of DirectSponsor and damage the shared trust.

Warning & Enforcement

  • Clear warnings will be shown to both recipients and sponsors:
    • During onboarding.
    • On every campaign page.
    • As a persistent banner in DM threads between recipients and their sponsors.
    Example text for recipients:“Inside DirectSponsor you must respect the public ledger. Private money requests to your sponsors bypass accountability and abuse the system that connected you. You are free to ask for money privately on plain Nostr, but not while using this system.”
  • First offense: Private warning + public report (NIP-56 kind 1984 event published by the sponsor with full quoted proof of the message).
  • Repeat offense or clear abuse: Removal from the DirectSponsor system. The recipient can continue operating on plain Nostr (asking for zaps, running independent campaigns, etc.), but they lose access to the structured DirectSponsor matching, ledger, and visibility tools.

Why This Approach?

  • It protects sponsors who expect transparency.
  • It maintains the integrity of the public accounting that makes donors comfortable participating.
  • It keeps the system coherent without turning it into a centralized platform with heavy moderation.
  • Recipients remain free — they just cannot simultaneously enjoy the benefits of the system while undermining its core mechanism.

Future Challenge: Maintaining Coherence in a Distributed Network Because the system is fully distributed (anyone can run relays, clients, or even fork the protocol), long-term coherence depends on:

  • Clear, shared definitions of what “DirectSponsor” means.
  • Consistent UI/UX in official clients that reinforce these boundaries.
  • Reputation signals (public reports) that travel with the pubkey across the network.
  • Community norms that develop around these definitions rather than top-down enforcement.

This is not about controlling people. It’s about clearly defining what this particular tool is for, so it doesn’t get degraded into something else.

The problem of scammers and disgruntled NGO owners trying to destroy the trust

Yes, this is the classic “brand in a decentralized network” problem — and Nostr actually has some very solid, battle-tested patterns for solving it without creating a single point of failure. You’re right that if DirectSponsor takes off it will attract attacks (scammers impersonating the project, fake campaigns, reputation-smearing reports, etc.). The good news is that the same cryptographic and social mechanisms that make Nostr resilient (keys, signatures, replaceable events, Web of Trust) also protect a project identity far better than any central domain ever could.

The Core Solution: A Root Pubkey + Signed System Definition (Not a Domain)

Don’t make directsponsor.net the central entity. Treat the domain as optional convenience only (e.g., for a NIP-05 address like directsponsor@directsponsor.net). The real, unbreakable identity of the project is:

  • One dedicated root pubkey (npub) that you (or a small trusted group) control. This is the “genesis” or “official” key for DirectSponsor.
  • A signed “system definition” event (replaceable kind, e.g., 30000-range or 31989/31990 per NIP-89) published by that root key. It defines:
    • What event kinds are official DirectSponsor events.
    • The exact structure of a valid campaign/request/ledger confirmation.
    • The public warnings and boundaries we already designed (no private money asks, etc.).
    • Links to the official client(s) or how to verify participation.

Clients (your official one + any compatible forks) simply check: “Is this campaign/event signed/referenced by the root pubkey’s latest definition event?” If yes → it’s official DirectSponsor. If not → it’s someone else’s thing (or a scam).

This is fully distributed:

  • The definition event lives on many relays (you publish it redundantly).
  • Anyone can query any relay for the latest replaceable event from the root pubkey.
  • No single server, domain, or company controls it.
  • If the domain gets attacked or seized, the root key and events keep working unchanged.

This is exactly how many successful Nostr projects (clients, protocols, even small DAOs) already do it in 2026. It’s the closest thing to Nakamoto’s “longest chain wins” — here it’s “latest signed definition from the root key wins.”

Handling Scammers and Reputation Attacks

Scammers will inevitably create fake npubs pretending to be “DirectSponsor Official” or copy your campaigns. Here’s how the system stays robust:

  1. Cryptographic proof beats impersonation Only events traceable back to the root pubkey count as official. A scammer can copy the look and feel, but clients will show “Unverified — not signed by DirectSponsor root” or simply hide/filter it.
  2. Web of Trust (WoT) layer — this is the 2026 upgrade Nostr now has mature, portable Web of Trust tools (browser extensions, oracles, and client integrations). Clients can show a trust score or “social distance” for any pubkey/campaign:
    • “This recipient is trusted by people in my graph / by the root key’s trusted set.”
    • Fake or abusive accounts quickly get low/negative trust signals from the community.
    • You can even publish a small “trusted seed list” from the root key (a list of early honest participants) so new users bootstrap trust immediately.
  3. NIP-56 reports + badges (what we already built) Private-solicitation reports or scam reports become public, signed proof. Repeat offenders get permanent, visible reputation damage that travels with their pubkey.
  4. Client-side filtering (not central moderation) Official clients can default to showing only root-key-verified campaigns. Users who want to see everything can turn it off. This is pure client-side logic — no central gatekeeper.
  5. Forkability is your friend If someone tries to hijack the name, the community can simply ignore the attacker and keep using the original root key. The project can’t be “stolen” because there is no central registry to seize.

Practical Roll-Out (Low-Effort, High-Resilience)

  • Generate the root key once (store it securely, ideally in a hardware signer or multi-sig setup later).
  • Publish the first system-definition event from it.
  • In your client:
    • Hard-code the root pubkey as a fallback (easy to update via a replaceable event).
    • Optionally use directsponsor.net + NIP-05 just for nice usernames during onboarding.
  • Document it clearly in the wiki: “The official DirectSponsor is defined by events signed by this root npub. Everything else is independent.”

This is not centralization — it’s the minimal cryptographic root that every decentralized system needs (Bitcoin has the genesis block; Nostr projects have the root key). It protects the brand and the shared social contract without giving anyone control over funds, users, or participation.

If it grows big enough that even this gets attacked, the next layer is community governance (e.g., the root key can be upgraded via a signed proposal + WoT consensus), but you don’t need that yet.

This keeps everything coherent while staying fully distributed — exactly the balance you’ve been aiming for. If you want, we can sketch the exact JSON for the root definition event or how to integrate WoT signals into your client UI. But the core idea above is the battle-tested way Nostr projects handle this today.

Branding & Official vs Unofficial Instances (WordPress Analogy)

DirectSponsor follows the wordpress.org / wordpress.com model in a decentralized way:

  • The official DirectSponsor is defined exclusively by events signed by (or referencing the latest definition from) the project’s root pubkey.
  • Anyone is free to fork the code, run their own relays/clients, or build compatible systems.
  • They may state “Built with DirectSponsor open tools” or “Compatible with DirectSponsor event kinds.”
  • Only instances that fully comply with the current root definition event may use the full “DirectSponsor” name and branding and appear as official in compliant clients.

If an instance violates the core definitions (e.g., allows or encourages private money asks that bypass the ledger), the root key can publicly disown it. Scammers or abusive forks can be clearly marked or filtered by clients without central gatekeeping.

This protects the reputation of the shared system while keeping everything open-source and forkable.

This setup keeps the project open and distributed (no one can stop forks) while giving you a clear, cryptographic way to protect the name and the social contract you care about.

grok.com “we can draft the actual structure/tags for that root definition event”.