# FAQ

The point is that modern apps are extremely limited in terms of functionality. It is easy to justify this by saying that the screen is small, fingers are thick, and controls need to be simple. As a result, we get very few options so as “not to complicate the interface.” In practice, this turns people into passive consumers. The algorithm serves something up, and you either accept it or reject it.

What I want is for the user to regain control. The idea is to preserve simplicity while returning to a time when you had control over what your phone displayed.

## What is the core idea?

Instead of exposing a fixed set of screens and functions, the system lets the user describe what they need and dynamically generates the corresponding interface.

The available capabilities are derived from Nostr and its NIPs.

The user can request a view or tool that was never explicitly designed in advance. This is why the project is intended not as another client covering a selected subset of Nostr, but as a genuine **Nostr Browser**.

It is intended to complement fixed clients, especially where useful views and workflows cannot be anticipated in advance.

## Does the user need to know NIPs?

No.

The user interacts through natural language and by pointing to elements already visible in the generated interface.

For example, they may say:

> Show me this user’s reactions.

while selecting a profile on the screen.

The system translates the request and its context into operations on Nostr-native data.

## How does the system generate an interface?

The LLM understands the relevant NIPs either from training or from documentation provided in its context.

It then:

* interprets the user’s intent,
* determines which data are needed,
* generates SQL or Cypher queries,
* selects the relevant events, tags, and relationships,
* creates an interface for exploring the result.

Unlike a normal assistant, the LLM is part of the application runtime. It does not only answer questions; it also determines how data should be retrieved, queried, and presented.

## How does the system access and query Nostr data?

The LLM uses general tools such as `nostr_query()`, exposed through an MCP-style tool layer.

Those tools may:

* query selected relays directly,
* use previously ingested data,
* combine both approaches.

The database is therefore an intermediate query layer, not a replacement for Nostr.

SQL is effective for filtering, sorting, aggregation, and value-based conditions. Cypher and a graph database are better suited to traversing relationships between identities, events, tags, and references.

The system can use whichever model is better suited to a particular request.

## Why buffer part of the Nostr graph?

Relay filters are optimized for fast event retrieval, not complex analysis.

For example, a relay cannot directly answer:

> Show me all products for sale priced below PLN 100.

The system must retrieve relevant events, interpret their tags, combine data from multiple relays, and apply conditions that the relay query language does not support.

The current work involves data from approximately 500 relays. When it is possible to predict which part of Nostr is likely to be useful, ingesting and organizing that data in advance is more efficient than repeatedly querying relays ad hoc.

## How is the buffered part of the graph selected and expanded?

This is one of the project’s main research challenges.

A basic strategy begins with a selected `npub`, retrieves associated events, and follows relationships to a limited depth, for example two or three levels.

Other strategies may consider current requests, earlier usage, relay availability, storage costs, and the probability that particular data will be useful later.

When the available dataset is insufficient, the LLM should plan the retrieval of additional events, tags, or relationships.

The buffer does not have to be minimal. It may include additional related data that could be useful for future requests.

The goal is to balance completeness, response time, storage, and synchronization costs.

## Does buffering improve privacy?

Yes.

Relays provide events, while the user’s full request and the resulting analysis can remain inside the system instance.

A relay may see that certain events were requested, but it does not need to know the higher-level purpose of the request or the complete query expressed by the user.

The actual privacy level depends on where the instance is hosted and who controls it.

## Where does the system run?

It is a web application deployed on a local or remote server and accessed through a browser from a phone, tablet, or computer.

The database, synchronization, query execution, buffering logic, and LLM may all run on the server. The phone primarily displays and interacts with the generated interface.

Because the system runs inside a browser, it operates within the browser’s permission and sandboxing model rather than receiving the broader device access available to a native mobile application.

## Can the generated interface be modified?

Yes.

The user can refine the interface through further instructions, add filters, change presentation, request more data, or point to an existing element and ask the system to transform it.

Generated views cannot currently be saved. Saving is planned for a later stage.

## Will users be able to share queries and views?

Potentially, yes.

A later version may allow users to save and share generated queries, interfaces, or complete views.

This could create a reusable community layer in which one user’s successful exploration pattern becomes a starting point for others while remaining editable.

## Can the system publish to Nostr?

Not initially.

The first phase is read-only. Publishing is planned for Phase 6, according to `/docs/roadmap.md`.

## Does every user need to deploy an instance?

No.

Phase 5, planned within the first three-month grant, will allow users to deploy their own instances.

An operator will be able to use an instance privately or provide access to others after receiving a Lightning Network prepayment.

This supports both self-hosted use and paid access to instances operated by others.

## Is the system production-ready?

No.

This grant is focused on validating user value and technical feasibility.

Production-grade query validation, generated-code isolation, permission controls, and data protection will become a major area of work only if the concept proves useful.

## Is this approach more chaotic than static interfaces?

Yes.

A generated interface is less predictable than a fixed application built from predefined screens and queries. Similar requests may produce different results, available data may vary, and the interface may evolve during use.

Nostr itself is open, distributed, and structurally messy. Traditional clients reduce this complexity by exposing only a carefully selected subset of the protocol.

This project makes a different trade-off: it accepts more variability in exchange for broader access and greater user control.

The approach will probably not appeal to everyone. The hypothesis is that it will attract a smaller but meaningful group of users who value exploration and flexibility over a fully static experience.

## Why does development require a relatively large token budget?

The budget reflects a development methodology designed to combine rapid iteration with code quality.

Instead of asking the LLM to make large changes from partial code fragments, the project maintains separate contextual documentation for individual modules. When changing a module, the model receives both the relevant implementation and a description of that part of the system.

This gives the model a better understanding of what it is changing and how the module fits into the wider architecture. The trade-off is that it must read more complete files and more contextual material, which increases token usage.

The project also favors many small, reviewable changes over fewer large rewrites. This increases iteration cost but reduces the risk of introducing broad, difficult-to-diagnose regressions.

## How is AI-generated code verified?

The use of an LLM does not replace explicit verification.

Tests are treated as executable requirements. Instead of relying only on natural-language descriptions, expected behavior is encoded in precise test cases.

For example:

> If a relay sends this event, this exact data should appear in the database.

Tests are especially important around relay ingestion, event normalization, database writes, and query behavior. In these areas, generated code and test changes are reviewed line by line.

This keeps rapid AI-assisted development grounded in strict, reproducible behavior.

## Why collect usage data and develop an open-source model?

The experimental phase will collect examples of:

* user requests,
* generated queries,
* generated interfaces,
* user corrections and refinements.

These data may later be used to train or fine-tune an open-source model specialized in Nostr data exploration, query generation, buffering, and interface generation.

General-purpose models are not optimized for the combination of NIPs, Nostr-native data, SQL, Cypher, graph traversal, adaptive buffering, and dynamic UI generation.

A specialized open-source model could make the system:

* more private,
* faster,
* cheaper,
* easier to self-host,
* less dependent on commercial model providers,
* more reliable within this specific domain.

The long-term goal is for the full system to run on infrastructure controlled by the user or instance operator.

## Will user data automatically be used for training?

The exact policy has not yet been defined.

Before data are used for model training, the project will need clear rules covering consent, storage, anonymization, scope of collection, and withdrawal.

A self-hosted instance should also allow the operator to keep all usage data private.

## What will the first grant validate?

The grant is intended to test three main assumptions:

1. Users find dynamically generated interfaces useful.
2. Adaptive ingestion and local Nostr graph querying enable interactions that fixed clients and relay filters cannot provide.
3. Real usage can produce the data needed to improve retrieval strategies and train a specialized open-source model.

The immediate output is an experimental Nostr Browser. The longer-term objective is a private, fast, inexpensive, and self-hostable system that gives users direct control over how Nostr data are explored and displayed.

