Nostr Catalog for YunoHost: Decentralised App Discovery Without Replacing YunoHost
- The basic idea
- Nostr is not distributing the application
- From Nostr events to a YunoHost catalogue
- Trust stays with the administrator
- The role of nostr_catalog_ynh
- Quick start: installing the Nostr Catalog
- Why use Nostr for this?
- Replaceable application declarations
- YunoHost remains responsible for installation
- A decentralised catalogue that still looks native
- Where this could go
Nostr Catalog uses Nostr as a decentralised publication layer for YunoHost applications, while keeping normal YunoHost packages, repositories, validation, installation and upgrades exactly where they are.
The YunoHost package for the project is:
https://github.com/imattau/nostr_catalog_ynh
The underlying catalogue service is:
https://github.com/imattau/nostr-yunohost
The basic idea
A normal YunoHost application might live in a repository such as:
foo_ynh/
├── manifest.toml
├── scripts/
├── conf/
├── doc/
└── tests/
That does not change.
Instead of requiring a central catalogue operator to add that application to a central database, the publisher can create a signed Nostr declaration describing the application and where its package repository can be found.
The flow looks like this:
Developer
↓
normal YunoHost app repository
↓
signed Nostr application declaration
↓
Nostr relays
↓
nostr-catalogd
↓
validation + trust policy + repository verification
↓
local catalogue cache
↓
/v3/apps.json
↓
YunoHost custom catalogue
↓
normal YunoHost install / upgrade
The important point is that YunoHost itself does not need to understand Nostr.
The catalogue service translates what it discovers through Nostr into the existing catalogue format YunoHost already supports.
Nostr is not distributing the application
This is an important distinction.
The YunoHost application repository remains authoritative.
Nostr does not replace manifest.toml, installation scripts, configuration, documentation or YunoHost’s application lifecycle.
Instead, the Nostr declaration points to a specific repository and revision and includes enough metadata to describe and verify it.
A declaration can include information such as:
application ID
publisher identity
YunoHost platform
repository URL
version
Git commit or tag
manifest hash
supported architectures
category
description
licence
homepage
support and source links
The declaration is signed by the publisher’s Nostr key.
That makes Nostr the discovery and publication layer, rather than the package transport or installation layer.
From Nostr events to a YunoHost catalogue
The core of the system is nostr-catalogd.
Its job is not simply to download events from relays.
It processes them through a catalogue pipeline:
subscribe to relays
→ validate events
→ apply local trust policy
→ deduplicate declarations
→ verify repository metadata
→ cache accepted applications
→ generate /v3/apps.json
Before an application is accepted, the service can retrieve the declared Git repository at the declared revision and verify the corresponding manifest or content hash.
If the declaration does not match the repository, it can be rejected.
This means a signed event is only the beginning of the verification process.
Trust stays with the administrator
Nostr signatures solve one problem very well: they tell you which key published an event.
They do not tell you whether the software is safe.
Nostr Catalog therefore deliberately separates:
publisher identity
curator identity
local administrator policy
The simplest model is an explicit list of trusted publishers.
An administrator can choose to accept applications only from selected Nostr public keys.
Later models can build on that with curator endorsements, minimum endorsement thresholds or eventually web-of-trust approaches.
The important part is that there does not need to be one globally authoritative catalogue deciding what everyone can see.
Different administrators can apply different trust policies to the same underlying network.
The role of nostr_catalog_ynh
nostr_catalog_ynh packages the catalogue service as a normal YunoHost application.
It handles the YunoHost-facing parts of the system, including configuring the daemon, managing its service, exposing configuration through YunoHost and registering the generated catalogue.
The package also includes publisher tooling.
An administrator can create a dedicated publishing identity, provide a YunoHost app repository and Git revision, and publish a signed application declaration through configured relays.
That means the same YunoHost installation can potentially participate on both sides of the system:
publish applications
and
consume the decentralised catalogue
Quick start: installing the Nostr Catalog
The easiest way to try Nostr Catalog is to install nostr_catalog_ynh directly from its Git repository on an existing YunoHost server.
From the YunoHost command line:
sudo yunohost app install https://github.com/imattau/nostr_catalog_ynh
The package installs nostr-catalogd and the nostr-ynh tooling, creates a dedicated publisher identity, configures the system service and registers the generated catalogue with YunoHost.
By default it connects to:
wss://relay.damus.io
wss://nos.lol
These can be changed from the application’s YunoHost configuration panel.
Configure who you trust
Open:
Webadmin → Applications → Nostr Catalog → Configuration
The Catalogue section lets you configure the Nostr relays and the publisher keys your catalogue will trust.
Trusted publishers can be entered as comma-separated npub or hexadecimal public keys.
The configuration panel also supports trusted curators and a minimum endorsement count if curation is being used.
Once configured, nostr-catalogd discovers declarations from the configured relays, validates them and builds the local YunoHost-compatible catalogue.
Publishing your own YunoHost application
Installation also generates a dedicated Nostr publishing identity.
Its npub is shown under:
Configuration → Publisher → Publisher identity
To publish an application, enter the HTTPS URL of a YunoHost application repository containing a manifest.toml, then specify the Git branch, tag or commit to publish.
For example:
Repository:
https://github.com/example/example_ynh
Git ref:
main
Select Publish signed declaration.
The wrapper verifies the repository, signs the application’s current declaration using its dedicated publishing identity and sends it to the configured Nostr relays.
Other Nostr Catalog installations that trust that publisher can then discover the application.
The result is still a normal YunoHost application. Nostr is only being used to announce and discover it.
Why use Nostr for this?
Nostr provides several useful building blocks without requiring a new central service:
public-key identities
signed events
multiple independent relays
event discovery
replaceable records
simple replication
For software discovery, that creates an interesting alternative to a traditional catalogue database.
A developer can publish an application declaration.
Multiple relays can carry it.
Multiple catalogue services can discover it.
Different administrators can decide whether they trust it.
No single relay needs to become the catalogue.
Replaceable application declarations
The current application record is designed around a parameterised replaceable Nostr event.
In practical terms, this means a publisher can update an application’s declaration when a new version is released without requiring the catalogue to treat every historical announcement as a separate current application.
The logical identity is based around the publisher and application ID rather than assuming globally unique application names.
That also avoids needing a central naming authority.
YunoHost remains responsible for installation
One of the strongest parts of the design is what it deliberately does not replace.
Nostr Catalog does not introduce:
- a new package format
- a new installer
- a new dependency resolver
- Nostr logic inside YunoHost core
- application binaries distributed through relays
Once an application appears in the generated catalogue, YunoHost handles it normally.
Webadmin remains Webadmin.
Installation remains a normal YunoHost installation.
Upgrades remain normal YunoHost upgrades.
The decentralised part stops at discovery.
A decentralised catalogue that still looks native
From the user’s point of view, the result can be fairly ordinary.
They install the Nostr-backed catalogue.
Applications discovered through Nostr appear through YunoHost’s existing catalogue mechanisms.
They install those applications using the same YunoHost tooling they already use.
The interesting part is underneath.
Instead of every application needing to originate from one central catalogue database, the available catalogue can be assembled locally from signed declarations discovered across Nostr relays.
That changes the architecture from something like:
one catalogue authority
↓
everyone
to:
many publishers
↓
many relays
↓
local trust and verification
↓
local catalogue
↓
YunoHost
There is no single catalogue that every installation must agree on.
Two YunoHost servers can listen to the same Nostr network while producing different catalogues because their administrators trust different publishers or curators.
Where this could go
YunoHost is the first implementation, but the underlying idea is broader.
The same model could potentially be adapted to other software ecosystems:
signed software declaration
↓
Nostr relay network
↓
platform-specific catalogue adapter
↓
existing package manager or app store
The platform does not necessarily need to adopt Nostr internally.
It only needs an adapter capable of converting trusted declarations into its existing catalogue or repository format.
That makes Nostr Catalog less a replacement app store and more a possible decentralised software registry protocol.
It also creates an interesting path towards shared primitives with projects such as npack: publisher identities, software declarations, releases, repository references, integrity information, attestations and endorsements could eventually be useful across multiple package ecosystems.
For now, YunoHost provides a practical environment to prove the model with real applications and existing installation tooling.
And that is the core of the project:
keep YunoHost for packaging and installation, but move application publication and discovery onto a decentralised network.
Write a comment