AppWeaver Roadmap Module

1. Product Concept

The Roadmap module is a Nostr-native public issue tracker and fundable roadmap for AppWeaver.

It lets users:

It lets maintainers:

The core idea is not a classic Kanban board. The module has two layers: user-created issues, and maintainer-controlled workflows where tracker events assign selected issues to statuses/columns. Kanban-like columns are a maintainer workflow view over existing issues, not the thing users directly control.

Working tagline: Fund what you want built next.

2. Core Principles

2.1 Funding Is Signal, Not A Contract

Payments increase visible priority, but they do not guarantee implementation, timing, acceptance, or support.

Required disclosure:

Funding an issue is a signal, not a purchase or contract. Funded issues are more visible and more likely to influence our priorities, but AppWeaver maintainers decide what to build, when to build it, and whether an issue fits the product.

2.2 Free To Create, Paid To Prioritize

Creating issues should be free in the MVP.

This keeps feedback friction low and avoids turning every bug report into a payment moment. Funding is layered on top as prioritization, not as a gate to participation.

2.3 Nostr-Native, Client-Agnostic

Roadmap data should live on Nostr so it can be reused across different clients:

The feature should not depend on one UI shape. The landing page may show a ranked public roadmap, while the app may show a larger timeline-style widget with search, issue lists, and accordions for statuses/columns. A Kanban layout is optional and not required for the MVP.

2.4 Free Creation, Adjustable Spam Defenses

Issue creation is free for the MVP, but the system should leave room for stronger spam controls if needed.

Possible future precautions:

These are not MVP requirements. The MVP should start with free issue creation and relay/moderator controls.

3. MVP Decisions

Decision MVP Choice
Primary product name Roadmap
First use case AppWeaver dogfooding
Canonical object Issue
Issue types Feature requests and bug reports
Who can create issues Anyone with Nostr
Creation cost Free
Funding model Optional funding on any issue
User promise Signal only, no guarantee
Public ranking Unassigned issues sorted by highest total funding first
Board model Maintainer-controlled workflow; tracker events assign existing issues to statuses/columns
Board scope Core AppWeaver board plus separate official plugin boards
Landing page default Top funded issues only
Repo relays relays tag on the NIP-34 repo announcement, discovered through repo author NIP-65 when needed
Funding verification Clients verify board author lud16/lud06 -> LNURLP -> nostrPubkey -> zap receipt pubkey
Funding total source Clients compute from verified zap receipts fetched from repo relays plus relevant NIP-65 relays
First AppWeaver entry point Header Roadmap button
First surfaces Usable from AppWeaver, viewable from landing page
Payment priority Lightning zaps first; Nutzaps later

4. User Experience

4.1 In-App Flow

The AppWeaver app should make browsing, searching, submission, and funding easy for active users.

The first in-app entry point should be a Roadmap button in the app header. It should open a singleton timeline widget, not a small modal. The widget should have enough space for search, issue lists, funding controls, and status sections without feeling cramped.

Later entry points may include:

Basic submission flow:

User opens AppWeaver
  -> clicks Roadmap / Report Bug / Request Feature
  -> searches existing issues first
  -> reviews similar/exact matches if found
  -> comments or funds an existing issue when appropriate
  -> selects Feature or Bug
  -> enters title and description
  -> optionally includes app version, OS, logs, or context
  -> signs with Nostr key
  -> issue is published to Nostr
  -> user may optionally fund the issue

The in-app UI does not need to show a full board. It should behave like a singleton timeline widget and can show:

4.2 Landing Page Flow

The landing page should be read-focused and trust-building.

It should show potential users:

The landing page should not require login just to view the roadmap.

The default landing-page view should highlight top-funded unassigned issues. This keeps the page focused on social proof and funding competition while preserving the maintainer's freedom to decide what enters the actual roadmap board.

The page can then show the maintainer-controlled roadmap board as a separate widget below the unassigned issues, or as an adjacent section. The board can be rendered as status accordions:

This gives visitors a workflow view without requiring a classic Kanban board UI.

4.3 Maintainer Flow

Maintainers need enough tooling to keep the roadmap useful without overbuilding the first version.

MVP maintainer actions:

The next maintainer UI should make the issue itself the editing surface. Clicking an issue title can open an issue detail view with controls for assignment, status, duplicate handling, moderation, comments, and funding context. Assignment tools should publish tracker events rather than mutate the original issue.

The issue detail UI should use a signer-aware capability layer before showing or enabling mutation controls. This layer should derive canCreate, canComment, canMove, canMark, canDelete, and similar booleans from all applicable signing identities, not only the current browser pubkey. In the app this includes browser signers and saved bunker connections; on the landing page it includes only landing-supported signers. For example, canMove is true when any available identity matches the board/workflow author, while canDelete is true only when an available identity matches the original issue author. The publish handlers must still enforce these rules after signing, but the UI should avoid showing controls that no available signer can execute.

5. Issue Model

An issue represents either a feature request or a bug report. The issue event should follow NIP-34 as closely as possible.

The model has two layers:

This preserves two freedoms at the same time:

Canonical issue event data comes mostly from NIP-34:

Field Purpose
Event ID Stable issue identifier for NIP-34 kind:1621 issue events
content Markdown description of the bug report or feature request
subject tag Short user-facing issue title
a tag NIP-34 project/repository anchor
p tag Maintainer/project owner reference
t tags Labels such as bug, feature, product area, or platform
created_at Original submission timestamp

Derived view data is not part of the issue event itself. Clients can build a view model by combining the issue event with related events:

Avoid adding AppWeaver-specific issue fields unless NIP-34 tags are not enough. Extra tags can be added later if a concrete need appears.

Suggested board statuses/columns:

Assignment rules:

Open question: whether bug reports later need separate statuses such as Confirmed or Needs Reproduction.

6. Workflow And Board Model

The AppWeaver model should be issue-first, not board-first.

Useful lessons from the referenced Kanban drafts:

Recommended AppWeaver model:

Issue = canonical user-created feature/bug event
Board/workflow = maintainer-controlled event defining statuses/columns
Tracker = maintainer-controlled assignment of an issue to a board/workflow column
Funding events = payment proofs referencing an issue
Views = client-specific projections over issues, board assignments, and funding

This supports several UI shapes without changing the data model:

6.1 Board Scope

AppWeaver likely needs more than one board:

Official plugins already have their own NIP-34 repository/project anchors. A plugin board can use that plugin's NIP-34 repo event as its issue anchor.

The existing plugin catalog event can also help connect plugin metadata to boards. In the current codebase, plugin install/catalog parsing uses plugin events with kind 32107, and includes fields such as plugin name, repository, version, and compatible refs. A plugin roadmap can link to both:

Unofficial plugins should not automatically appear in the official AppWeaver roadmap. They may expose their own board, but the app should distinguish official boards from third-party/plugin-maintainer boards.

6.2 Unassigned Issues Vs Board Roadmap

Unassigned issues are the public feedback pool. They contain valid user-created bugs and feature requests that have not been placed on the maintainer-controlled board.

The roadmap board is the subset of issues that a maintainer has assigned to a status/column.

This distinction is important for product messaging:

6.3 Kanban-Like UI Without Kanban Lock-In

A classic Kanban board may be too heavy for the in-app and landing-page views. The same workflow can be represented as accordions or sections:

Top Funded
  issue
  issue
  issue

Unassigned
  issue
  issue

Planned
  issue

In Progress
  issue

Shipped
  issue

For maintainers, the same statuses can become columns:

Unassigned | Planned | In Progress | Shipped | Rejected | Archived

The important design constraint is that board assignment and movement between columns are maintainer actions, not user actions.

7. Ranking Model

The MVP ranking should be simple:

sort by funding_total descending
tie-break by created_at ascending

This makes the system easy to explain:

The most-funded unassigned issues appear first.

Clients should compute funding totals from verified zap receipts. For the MVP, clients should not treat relay acceptance as proof of payment. Instead, the client derives the board author's Lightning address from kind 0 profile metadata, fetches the LNURLP document, reads the LNURLP nostrPubkey, and only counts zap receipts authored by that pubkey.

Aggregate tables and summary events can be added later for performance, but they are not required for the first version.

Future ranking improvements may include:

These should be deferred until there is real usage data.

8. Payments

8.1 Client-Verified Funding

The MVP should start with repo relays rather than a dedicated AppWeaver relay. Repo relays are the relays tag values on the NIP-34 repository announcement. Clients can use the repo author's NIP-65 outbox write relays to discover the announcement, but the announcement's relays tag is the final project-level relay set for board/workflow events, tracker events, created issues, comments, status events, and zap receipts for that repository.

The verification rule is:

board author kind:0 lud16/lud06
  -> LNURLP payRequest document
  -> LNURLP nostrPubkey
  -> zap receipt pubkey must match

Clients can fetch roadmap events and zap receipts from repo relays plus relevant NIP-65 relays, verify the receipts locally with this rule, sum the verified amounts, and sort issues by total funding.

Expected flow:

User chooses an issue
  -> clicks Fund
  -> chooses amount
  -> sends zap linked to the issue
  -> zap provider publishes a NIP-57 receipt
  -> client fetches receipts from repo relays and relevant NIP-65 relays
  -> client counts the receipt only if its pubkey matches the board author's LNURLP nostrPubkey

8.2 Nutzaps

Nutzaps fit the product values well:

When Nutzaps are added, clients or a later indexing/relay service should verify as much as practical before counting the event:

The event should only count after successful verification and redemption/swap. Nutzaps are not part of the first landing-page path.

8.3 Lightning Zaps

Lightning zaps should be supported with client-side receipt verification. The system must not blindly trust arbitrary NIP-57 zap receipts.

Client verification for Lightning zaps should verify:

Fake, unverifiable, duplicate, or unrelated zap receipts must be ignored and must not affect funding totals.

8.4 Refunds And Expectations

The MVP should avoid bounty or escrow semantics.

Funding is a voluntary signal. Refunds should not be promised by default unless a separate bounty/escrow product is introduced later.

9. Moderation And Abuse

Because issue creation is free and events may be fetched from public relays, moderation is required.

MVP controls:

Possible later controls:

Important distinction:

NIP-56 is useful because moderation can stay event-based and auditable. If the maintainer or an accepted moderator reports an event as spam, abuse, or another moderation reason, clients can use that report to hide the event in the roadmap projection. A later AppWeaver relay or indexer can also use the same report events for deletion, bans, or review workflows.

The relay dashboard is not part of the MVP, but the relay should be designed so moderation state can eventually be changed at runtime rather than requiring relay restarts.

10. Nostr Architecture

NIP-34 gives AppWeaver a good base for issues. The module should reuse NIP-34 issue semantics where possible, then add a maintainer-controlled board layer for roadmap assignment.

10.1 Project / Repository Anchor

If AppWeaver wants compatibility with NIP-34 clients, it should announce the project with a NIP-34 repository announcement, even if the Roadmap UI is product-focused rather than Git-focused.

{
  "kind": 30617,
  "content": "",
  "tags": [
    ["d", "appweaver"],
    ["name", "AppWeaver"],
    ["description", "Nostr-native app builder"],
    ["web", "https://getappweaver.com"],
    ["relays", "wss://relay.ditto.pub", "wss://relay.primal.net", "wss://relay.snort.social", "wss://nostr.mom", "wss://nos.lol"]
  ]
}

The repository/project announcement gives issues a canonical a tag target.

10.2 Relay Strategy And NIP-65 Outbox

The MVP should start on repo relays instead of requiring an AppWeaver-controlled relay. Repo relays are the relays tag values on the NIP-34 repository announcement. Clients may use public discovery relays only to resolve an author hint, find the owner's NIP-65 relay list, and fetch the repository announcement.

Discovery/bootstrap relays:

wss://relay.vertexlab.io
wss://relay.nos.social
wss://user.kindpag.es
wss://relay.primal.net

Relay resolver:

repoAddress = nostr://_@getappweaver.com/core
authorPubkey = nip05(repoAddress.authorHint)
announcementDiscoveryRelays = nip65WriteRelays(authorPubkey)
repoAnnouncement = query kind:30617 by authorPubkey and d tag from announcementDiscoveryRelays
repoRelays = repoAnnouncement.tags.relays

The repository announcement relays tag is the relay set that clients monitor for issues, board/workflow events, tracker events, comments, status events, and funding receipts. Created issues should be published to those relays as well. The repository owner's NIP-65 write relays remain the discovery path for finding or refreshing the repository announcement itself. If the announcement has no relays tag, clients may fall back to the owner's NIP-65 write relays.

Clients should subscribe to relevant event classes on repo relays:

Because these are public relays, clients must filter and validate the event graph themselves. A dedicated AppWeaver relay or indexer can be added later for performance, moderation, and stricter write policy, but it should not be required for the first public roadmap.

NIP-65 relay lists should augment repo relays for publishing and discovery:

Suggested publish targets:

Action Publish to
Create issue Repo owner NIP-65 write relays + issue author NIP-65 write relays
Comment on issue Repo relays + commenter NIP-65 write relays + replied-to author NIP-65 read relays
Zap issue Repo relays + zapper NIP-65 write relays + repo owner NIP-65 read relays
Close own issue Repo relays + issue author NIP-65 write relays
Close/resolve issue as owner Repo relays + owner NIP-65 write relays + issue author NIP-65 read relays
Tracker assignment/status change Repo relays + board/repo owner NIP-65 write relays + issue author NIP-65 read relays
Board/workflow update Repo owner NIP-65 write relays

For reading, clients should start with repo relays and optionally query relevant NIP-65 read relays for issue authors, board authors, zappers, and commenters when more complete discovery is needed.

10.3 Board Authority

To avoid delegated authority complexity, AppWeaver should derive roadmap authority from event authorship. The project/repository event author is the project owner, and the board/workflow event author must be the same key.

Authority rules:

For official plugin boards, the same rule applies: the plugin board author must match the plugin's NIP-34 project/repository author. If plugin catalog metadata is linked, clients can also require the plugin catalog event author to match the same key.

This is simpler than trying to determine whether another key was a valid maintainer at the time a tracker was created. If AppWeaver later needs multi-key administration, it should add an explicit AppWeaver delegation mechanism instead of relying on the NIP-34 repository announcement.

10.4 Issue Events

Users create issues with NIP-34 kind:1621 events.

{
  "kind": 1621,
  "content": "Markdown description of the bug report or feature request.",
  "tags": [
    ["a", "30617:appweaver-owner-pubkey:appweaver"],
    ["p", "appweaver-owner-pubkey"],
    ["subject", "Add project export"],
    ["t", "feature"],
    ["t", "appweaver"]
  ]
}

Recommended issue labels:

Replies and discussion should use NIP-22 comments, as NIP-34 recommends.

10.5 NIP-34 Status Events

NIP-34 defines status events for issues:

These are useful for broad issue state. They should be used alongside board/tracker events, not instead of them.

Examples:

Recommendation:

This gives both sides flexibility. Users can close their own issue when appropriate. Maintainers can close or resolve issues at the NIP-34 layer, and separately control roadmap placement through board/tracker events.

10.6 Board / Workflow Event

The board event is controlled by the maintainer. It defines the roadmap workflow: title, description, columns, and visual metadata.

After reviewing the workflow and Kanban proposals, the better model is:

This avoids large mutable board events that contain every card assignment. It also avoids race conditions if automation later updates assignments.

Possible board/workflow event shape. The exact AppWeaver event kind can be chosen later; the important schema decision is the tags and relationships.

{
  "kind": 39010,
  "content": "",
  "tags": [
    ["d", "appweaver-roadmap"],
    ["title", "AppWeaver Roadmap"],
    ["description", "Maintainer-selected AppWeaver roadmap issues"],
    ["col", "planned", "Planned"],
    ["col", "in-progress", "In Progress"],
    ["col", "shipped", "Shipped"],
    ["col", "rejected", "Rejected"],
    ["col", "archived", "Archived"],
    ["a", "30617:appweaver-owner-pubkey:appweaver", "wss://xxx", "project"]
  ]
}

Only board-author-signed board/workflow events should be accepted as the canonical AppWeaver roadmap board, and the board author must match the referenced project/repository author.

10.7 Tracker Events For Board Assignment

Tracker events are the assignment layer. A tracker says: this issue is tracked in this workflow, with this workflow-specific state.

For AppWeaver, the tracker content can be the column ID.

Possible tracker event shape. The exact AppWeaver event kind can be chosen later.

{
  "kind": 39011,
  "content": "in-progress",
  "tags": [
    ["d", "appweaver-roadmap:issue-event-id-1"],
    ["e", "issue-event-id-1", "wss://xxx", "tracked_item"],
    ["a", "39010:appweaver-board-pubkey:appweaver-roadmap", "wss://xxx", "workflow"],
    ["rank", "10"]
  ]
}

The tracker uses both d and e tags for different reasons:

Using only d would make the event harder to query with standard #e filters and would hide the actual issue relationship inside an AppWeaver-specific identifier.

Tracker rules:

Unassigned issues are all valid NIP-34 issue events for the AppWeaver project that have no latest valid tracker in the AppWeaver roadmap workflow.

10.8 Funding Events

Users zap/fund issues directly, not board columns.

Funding events should reference the issue event ID. For Nutzaps, the event should include an e tag pointing to the kind:1621 issue.

Repo and NIP-65 relays are transport, not payment authority. Clients should compute funding totals by scanning zap receipts from repo relays and relevant NIP-65 relays, then verifying that each receipt was authored by the LNURLP nostrPubkey for the relevant board author.

This means ordering is deterministic for clients that use the same relay set and verification rules:

funding_total(issue) = sum(amount of verified funding events referencing issue)

If a funding event cannot be verified against the board author's LNURLP payRequest metadata, it does not count toward ranking.

Board assignment does not affect funding. If a funded issue later moves from unassigned to Planned, the issue keeps its funding total.

10.9 Derived Views

Clients can derive the main views from the same data:

Current technical decisions:

Duplicate handling can be simple:

If duplicates become common, AppWeaver can later standardize a tag or tracker convention for duplicate-of, but that is not needed for MVP.

11. Monetization Strategy

The first monetization target is AppWeaver itself, not a generic SaaS product.

11.1 Direct Monetization

Users can fund specific issues they care about.

This creates a lightweight open-source funding loop:

User has a need
  -> submits or finds an issue
  -> funds it
  -> issue rises publicly
  -> maintainer sees stronger demand
  -> development priorities become easier to justify

This does not sell implementation guarantees. It sells influence as signal.

11.2 Indirect Monetization

The public roadmap can also increase AppWeaver revenue by showing:

This can support subscriptions, paid plans, sponsorships, or future commercial features.

12. MVP Scope

Phase 1: Public Roadmap Data And View

Phase 2: In-App Submission

Phase 3: Funding

Phase 4: Maintainer Tools

13. Open Questions

Question Current Leaning Status
Should bugs and features share one ranked list? Start together, add filters Pending
Should landing page show all issues or only funded/top issues? Top funded only Decided
Should maintainers be able to pin issues above funded ranking? Maybe later Pending
Should funding totals be computed client-side or published by AppWeaver? Client computes from locally verified zap receipts Decided
Which Nostr event kind should be used for issues? NIP-34 kind:1621 Proposed
Should anonymous/throwaway submissions be encouraged? Useful, but may increase spam Pending
What minimum moderation tools are required before public launch? Hide/archive/rate limit/NIP-56 reports Pending
Should board assignment be separate from the board definition? Yes, use tracker events Proposed
How should official plugin boards be discovered? NIP-34 repo + plugin kind:32107 metadata Proposed

14. Next Decisions Needed

Before development starts, decide:

  1. The exact Nostr event model for the board workflow, tracker assignments, and funding references.
  2. Whether the public status accordion should be available on the landing page immediately or after the top-funded list.
  3. Whether bug reports and feature requests need different form fields in the first version.
  4. The exact issue detail UI and assignment controls for board workflow actions.
  5. Whether and when to add an AppWeaver relay or indexer after the public-relay MVP.

15. Current Summary

Build a Nostr-native Roadmap module for AppWeaver first.

Anyone with Nostr can submit feature requests or bug reports for free as NIP-34 issues. New issues start unassigned. Users should search before submitting and comment/fund an existing issue when one already exists. Any user can fund any issue. Funding is a public prioritization signal, not a contract. The MVP uses repo relays from the NIP-34 repo event relays tag, after discovering that repo event through NIP-05 and repo owner NIP-65 when needed, and created issues are published to those relays. Clients compute funding totals by verifying zap receipts against the board author's LNURLP nostrPubkey. Board authors control workflow events that define board columns for AppWeaver core and official plugins, and clients should only accept boards whose author matches the referenced NIP-34 project/repository author. Tracker events assign selected issues to planned, in progress, shipped, rejected, or archived columns. The app provides creation and funding through a header Roadmap button that opens a singleton timeline widget; the landing page highlights top-funded unassigned issues and can show roadmap boards as separate widgets. The next maintainer tooling step is an issue detail UI, opened from the issue title, with assignment controls that publish tracker events.