Readout · 05 · For developers
Your fix list, sorted by impact.
Every cell below Flawless names a NIP and carries a note. Here is how to get on the board, get counted, and move a score.
Using a coding agent?
Everything below is written up as a procedure an agent can follow inside your own repository. Open your terminal there and give it this:
Read https://nostrometer.com/SKILL.md and use it to submit this app to the Nostr app directories.It reads your project for the name, description, icon, platforms and the NIPs you actually implement, builds the event, and hands it back for you to check and sign. It never handles your key. Read the file first if you would rather see what it says.
Publish a kind 31990 listing
The matrix keys everything on your NIP-89 handler event. Without one, there is nothing to rate. A complete listing carries:
- a stable
dtag (change it and you start over) name,picture,aboutandwebsitein the content JSONktags for the kinds you handle- platform tags (
web,android,ios, …) with URL templates itags naming the NIPs you implement- an
atag pointing at your NIP-34 repository announcement (step 06)
{
"kind": 31990,
"content": "{\"name\":\"Your App\",\"picture\":\"https://…/icon.png\",\"about\":\"One sentence.\",\"website\":\"https://yourapp.example\"}",
"tags": [
["d", "your-app"],
["k", "1"], ["k", "30023"],
["web", "https://yourapp.example/<bech32>", "nevent"],
["android", "yourapp://<bech32>"],
["i", "nip-01", "nip"], ["i", "nip-17", "nip"], ["i", "nip-57", "nip"],
["a", "30617:<your-pubkey>:your-app", "wss://relay.ditto.pub", "repo"]
]
}The NostrHub wizard builds and signs one for you. If you prefer a file and a key, this one-liner with nak does it:
nak event --prompt-sec < listing.json \
wss://relay.ditto.pub wss://nos.lol wss://relay.damus.io wss://nostr.momFor apps in the review queue we prepare the file for you. The listing is assembled from your current listing, your repo and Zapstore release, and the NIPs the review verified, then handed over unsigned with a note on where every field came from. Edit anything, delete anything, and publish it from your key. It exists to save you the afternoon, not to speak for you.
Publish it from the key you develop with. Ratings bind to the listing's address. If someone else seeds a listing for your app, every rating attaches to their copy, and when you finally publish your own the ratings do not follow. Only the key that published a listing can update it, so the implemented NIPs, platforms and repo link are yours to set. One listing from your key, and everything published about your app sticks to it for good.
Tag events with client if you want usage counted
Monthly authors are counted from the client tag on published events. If you want your app's usage measured, add one to everything it signs:
["client", "Your App", "31990:<your-pubkey>:your-app", "wss://relay.ditto.pub"]The first value is matched against your listing's name and website host. A listing seeded under someone else's key, or a name whose capitalisation differs from what your app writes in the tag, makes the count miss you. Your own listing fixes both.
Omitting the tag is a legitimate choice, and NIP-89 says you SHOULD offer users the option: the tag tells every relay which software a person runs. An untagged app shows no usage figure rather than a zero, and usage has no bearing on its ratings either way.
Rate your own app
Publish kind 31986 ratings for the NIPs you implement, from the same key as your listing. They appear immediately, marked * self-rated until an independent rater confirms them. That is not a penalty; it is provenance.
Rate against what the NIP requires of a client, and leave unimplemented NIPs unrated. The full rule is on the methodology page.
Disagree with a cell? Publish a rating.
There is no appeals form. Every cell is a median of public events, so the way to change it is to add one. Fix the issue, publish your rating with a note pointing at the commit, and ask a rater to re-check. The median moves.
You will not be surprised by a bad cell. Every Borked or Isolated finding comes with an issue in your tracker that names the NIP, the clause, and what we saw, before it is public anywhere else.
Request a review
Reviews are worked in waves, ordered by usage. To get in the queue, open an issue on the tooling repo with your listing's naddr, or message Derek on Nostr.
Put the source on Nostr too
Your listing can point at your repository by Nostr address, the same way ratings point at your listing. That needs the repository announced on Nostr as a NIP-34 event, which is one command with ngit:
ngit initRun it in the repo, answer the prompts, and it publishes a kind 30617 announcement under your key with your existing clone URLs. Nothing moves. GitHub, GitLab or your own server stays where it is; the announcement just makes the repo addressable from Nostr, so the listing, the review and the ratings all resolve to the same code without leaving the protocol.
We ask every app in the review queue to do this. Issues we file for Borked or Isolated cells can then land as NIP-34 issues on the repo itself, next to the ratings, where the whole history is signed and readable by any client. An ecosystem that measures interoperability should keep its source where anyone can verify it the same way.