# Stage 01: nobro
<img src="res/nobro.png" alt="nobro" width="100" height="100">

## Goal
The goal is to create a universal Nostr browser that is not limited by a fixed user interface.

## Funding

This roadmap covers the first three months of funded development.

I would love for the funder to share a short message with the world. The message could be featured on the tool’s opening screen and displayed alongside their name in the funders section.

In the future, each funder could have the opportunity to contribute a brief message of their own.


## Target outcome after three months

By the end of this period, the project should provide a complete open-source solution that anyone can install and run independently.

The system will:

* collect selected data from Nostr relays,
* load the data into a database,
* provide a web interface for exploring it,
* support navigation using natural language, voice, and gestures,
* allow users to choose from all language models available through PayPerQ and configure any LLM supported by Goose (remote and local).

Anyone will be able to install the software for private use or expose the same functionality to other users.

I also intend to operate a public instance of the same software. After making a prepayment in LN, users will be able to experiment with the Nostr database using any model available through PayPerQ.

The pricing will be designed primarily to cover model usage, infrastructure, and operating costs rather than to maximize profit. The long-term goal is for the public server to sustain itself without requiring additional funding from me.

The system remains read-only during this stage and will not yet publish Nostr events.

Funding must cover AI token usage during development and the infrastructure required to operate the server.

If funding is obtained, I commit to working on the project for an **absolute minimum of 8 hours per day and 20 working days per month**. These are minimum commitments, not targets or upper limits.

> **Day 0** means the beginning of Phase 2.
>
> Completion dates include only the remaining work. Work completed before Day 0 is not counted again.
>
> The roadmap covers at least 60 working days over three months. The final phase reserves the remaining time for experiments, unexpected work, refinement, and quality improvements.

## Summary

| Phase | Goal                                                        | Total effort | Completed | Remaining | Completion from Day 0 |
| ----: | ----------------------------------------------------------- | -----------: | --------: | --------: | --------------------: |
|     1 | It works                                                    |    completed | completed |    0 days |          before Day 0 |
|     2 | Claude Code is replaced with Goose or another suitable host |       6 days |     1 day |    5 days |          after 5 days |
|     3 | Anyone can run the project independently                    |       6 days |     1 day |    5 days |         after 10 days |
|     4 | Selected values are replaced with safe local identifiers    |       3 days |     1 day |    2 days |         after 12 days |
|     5 | A semantic catalog of Nostr kinds is created                |       8 days |     0 days |    8 days |         after 20 days |
|     6 | Allow multiple selection                                    |       2 days |     1 day |    1 day |         after 21 days |
|     7 | A public experimental server is available                   |      10 days |     1 day |    9 days |         after 30 days |
|     8 | Flexible Nostr ingestion strategies are developed           |      10 days |    5 days |    5 days |         after 35 days |
|     9 | Data is separated from model-generated interfaces           |      10 days |    3 days |    7 days |         after 42 days |
|    10 | Add support for Cypher and a graph database                  |      10 days |    3 days |    7 days |         after 49 days |
|    11 | Experiments, refinement, and unexpected work                |      11 days |    0 days |   11 days |         after 60 days |

---

## Phase 1 — It works

| Total effort | Completed | Remaining |   Completion |
| -----------: | --------: | --------: | -----------: |
|    completed | completed |    0 days | before Day 0 |

`██████████ 100%`

The first working solution demonstrates that the idea is technically feasible.

Data from Nostr relays is buffered in a database, while its presentation is generated on demand.

The current version is suitable for demonstrations but not yet for easy independent use.

Demonstrations:

* https://agent0.pl/vid/nostr.mp4
* https://agent0.pl/vid/nostr2.mp4

---

## Phase 2 — Claude Code is replaced with Goose or another suitable host

| Total effort | Completed | Remaining | Completion from Day 0 |
| -----------: | --------: | --------: | --------------------: |
|       6 days |     1 day |    5 days |          after 5 days |

`█▋░░░░░░░░ 17%`

Claude Code will be replaced with an existing open-source agent host, most likely Goose.

Another suitable host may be selected, but we will not develop a custom one.

The selected host will become part of the installation and runtime environment prepared in Phase 3.

---

## Phase 3 — Anyone can run the project independently

| Total effort | Completed | Remaining | Completion from Day 0 |
| -----------: | --------: | --------: | --------------------: |
|       6 days |     1 day |    5 days |         after 10 days |

`█▋░░░░░░░░ 17%`

The goal is to make the project easy for anyone to install, configure, and start.

At least the following will be delivered:

* a simple installation and startup script,
* a clear and minimal configuration,
* sensible defaults,
* a ready-to-use Docker container.

The repository is already open source and includes this roadmap. The project and its dependencies use the Apache License 2.0 or similarly permissive open-source licenses.

---

## Phase 4 — Selected values are replaced with safe local identifiers

| Total effort | Completed | Remaining | Completion from Day 0 |
| -----------: | --------: | --------: | --------------------: |
|       3 days |     1 day |    2 days |         after 12 days |

`███▎░░░░░░ 33%`

A universal mechanism will replace selected values in tool payloads with short local identifiers.

Nostr public keys are the first important use case because language models hallucinate or incorrectly reproduce them.

Before a payload reaches the agent, each `npub` will be replaced with an identifier such as:

`#npub_123`

Subsequent tools will accept the identifier and resolve it automatically. The agent will also be able to retrieve the original `npub` when it is relevant to the user or required for an operation.

The mechanism may later support other value types where exact resolution is required but the original value does not need to remain in the model context.

---

## Phase 5 — A semantic catalog of Nostr kinds is created

| Total effort | Completed | Remaining | Completion from Day 0 |
| -----------: | --------: | --------: | --------------------: |
|       8 days |     0 days |    8 days |         after 20 days |

`░░░░░░░░░░ 0%`

A semantic catalog of Nostr kinds will be created so that the system can select the appropriate kind based on user intent rather than only by kind number, name, or a specific NIP.

A more detailed description is available in [`features/kinds_catalog.md`](features/kinds_catalog.md).

Each kind will be represented as a self-contained full-text document describing its purpose, common use cases, event structure, tags, constraints, related NIPs, and important alternatives. Some information may be intentionally repeated across documents because local completeness is more useful for semantic search and LLM context than strict normalization.

The catalog will be generated and maintained with the help of an LLM. The model will analyze NIPs and other relevant specifications, identify kinds and extensions, extract rules and dependencies, and regenerate affected documents when the specifications change. Source references and normative terms such as `MUST`, `SHOULD`, and `MAY` will be preserved so that generated descriptions can be verified.

The catalog will support both searching the existing Nostr graph and generating appropriate event structures. For example, it should help determine which kinds and tags are needed to find product listings, or which event structure should be used to publish a product for sale. Event publication itself remains outside the scope of this read-only stage.

---

## Phase 6 — Allow multiple selection

| Total effort | Completed | Remaining | Completion from Day 0 |
| -----------: | --------: | --------: | --------------------: |
|       2 days |     1 day |    1 day |         after 21 days |

`█████░░░░░ 50%`

Allow multiple selection.

---

## Phase 7 — A public experimental server is available

| Total effort | Completed | Remaining | Completion from Day 0 |
| -----------: | --------: | --------: | --------------------: |
|      10 days |     1 day |    9 days |         after 30 days |

`█░░░░░░░░░ 10%`

Any user will be able to run the software as a server and expose its functionality to others.

I also intend to launch one public instance using the same open-source software that users can install independently.

This will let anyone try the project without installing it and will provide more real-world use cases for improving the product.

Feedback and debugging will also be easier because logs, errors, and operational data from this instance will be available on infrastructure under my control.

Users will make a prepayment in LN and use any language model available through PayPerQ.

The pricing should cover model and infrastructure costs so that, over time, operating the server does not require additional funding.

---

## Phase 8 — Flexible Nostr ingestion strategies are developed

| Total effort | Completed | Remaining | Completion from Day 0 |
| -----------: | --------: | --------: | --------------------: |
|      10 days |    5 days |    5 days |         after 35 days |

`█████░░░░░ 50%`

The current ingestion model is simple: the system subscribes to a selected `npub`, ingests all events published by it, and also ingests events that reference it in tags.

This works, but it is not sufficient for broader use cases.

It is not realistic to ingest the entire Nostr network, so the system needs more advanced mechanisms for selecting the data most likely to be useful to a particular user.

The work will also cover dynamically changing ingestion rules, resuming interrupted ingestion processes, and monitoring what data is currently being collected.

Because it is not yet clear which algorithms and strategies will work best, the system should also make it easy for users to plug in custom ingestion logic or provide their own ingester.

The result should prioritize relevant data without attempting to download the entire Nostr network.


---

## Phase 9 — Data is separated from model-generated interfaces

| Total effort | Completed | Remaining | Completion from Day 0 |
| -----------: | --------: | --------: | --------------------: |
|      10 days |    3 days |    7 days |         after 42 days |

`███░░░░░░░ 30%`

The language model should be able to generate a user interface without receiving the complete dataset that will be displayed.

For example, if a Nostr query returns 300 records, the LLM should receive only:

* the structure of the records,
* available fields and their types,
* possibly a small representative sample.

Based on this information, the model will generate a suitable interface. The complete dataset will be passed to that interface outside the LLM context.

This will improve privacy, reduce LLM costs, speed up interface generation, and allow much larger datasets to be displayed.

The user should see the complete result even though the model does not need to read every record.

---

## Phase 10 — Add support for Cypher and a graph database

| Total effort | Completed | Remaining | Completion from Day 0 |
| -----------: | --------: | --------: | --------------------: |
|      10 days |    3 days |    7 days |         after 49 days |

`███░░░░░░░ 30%`

SQL is the most suitable approach for some queries, while others are better served by a graph-based representation of Nostr and a query language such as Cypher.

The system should therefore support this type of database as well. However, this work should be postponed until Phase 10, because maintaining both database models earlier would slow down product development.

---

## Phase 11 — Experiments, refinement, and unexpected work

| Total effort | Completed | Remaining | Completion from Day 0 |
| -----------: | --------: | --------: | --------------------: |
|      11 days |    0 days |   11 days |         after 60 days |

`░░░░░░░░░░ 0%`

This phase is reserved for experiments, unexpected technical work, feedback-driven changes, refactoring, and quality improvements across the earlier phases.

The exact scope will depend on what is learned during implementation.
