Overview
OnlyBoosts is an index of podcast boosts that have been published to Nostr. Boost notes are collected from relays across the network, cross-referenced against the Podcast Index for show and episode metadata, and served as an open feed.
Boosting requires no Nostr at all. A listener sends sats to a show through the Podcasting 2.0 value block, the payment is split among the recipients the podcaster has named in the RSS feed, and a boostagram message frequently travels with it. That process predates this site by years and it remains the mechanism behind the large majority of boosts sent today.
What this site indexes is considerably narrower. A small number of podcast applications now publish a public note to Nostr when a boost is sent, announcing that the boost occurred. Those notes, and only those notes, are what OnlyBoosts collects. The result is a cross-application view of boost activity assembled entirely from what the applications themselves have chosen to broadcast.
Nostr Fundamentals
Nostr is an open protocol for publishing cryptographically signed messages to a network of independent servers. Four of its properties are relevant to how this index works.
Relays
A relay is a server that accepts signed messages and serves them back to anyone who requests them. Anyone can operate one and there are hundreds in operation. There is no central authority, no account database and no algorithmic distribution. A given message may be stored on many relays or on very few, so retrieving it is a matter of querying the right ones. Relays are also under no obligation to retain messages indefinitely, which places a practical limit on how far back this index can reach.
Keys and Identity
Nostr has no usernames and no accounts. An identity is a cryptographic keypair; the public half is referred to as an npub and serves as the identifier for everything that key publishes. Every message is signed with the private half, so any reader can independently verify that a message originated from a particular npub. No authority can revoke that identity and no third party can forge messages from it.
Event Kinds
Every Nostr message, referred to as an event, carries a kind number declaring what type of message it is. Kind 1 is the standard short text note. A boost note is a kind 1 event that carries additional tags describing the boost.
Tags
Alongside its text, an event carries a list of tags. Most tags serve social functions such as mentions and replies. One convention, NIP-73, allows an event to reference something that does not exist on Nostr at all. That convention is what makes this index possible.
NIP-73 and External Content IDs
NIPs, or Nostr Implementation Possibilities, are the protocol’s specification documents. They are numbered, publicly maintained and open for any developer to implement. NIP-73, titled “External Content IDs,” addresses a single question: how does a Nostr event declare that it refers to something outside of Nostr?
The specification defines two tags for this purpose. An i tag carries the external identifier and a k tag declares what kind of identifier it is. NIP-73 covers books by ISBN, papers by DOI, films by ISAN, web URLs, geohashes and blockchain transactions, among others. Three of its identifier types apply to podcasting.
The significance of these identifiers is that none of them are new. The show GUID is the <podcast:guid> value published in the RSS feed, the namespaced UUID that Podcasting 2.0 introduced so that a show retains a stable identity across host migrations. The episode GUID is the episode’s own <guid> element.
Because the Nostr event and the Podcast Index entry both reference the same values from the same feed, a note published by any application to any relay can be matched to a specific show and episode without a registry, a mapping table or any coordination between the parties involved. That match is what allows this site to attach the correct title, artwork and air date to a boost that arrived carrying none of them.
For the purposes of this index, a boost note is a kind 1 event satisfying two conditions: it carries the NIP-73 podcast tags, and it carries evidence that a payment occurred. That evidence takes the form of an amount tag, a reference to a Lightning zap receipt, or a topic tag identifying the note as a boostagram.
Keysend Boosts and What Is Not Indexed
The majority of boosting activity in Podcasting 2.0 is not visible to this site. Boosts sent by the conventional method never touch Nostr, and there is consequently no record for this index to collect.
The original boost mechanism involves no social network. The listener’s application reads the value block from the podcast’s RSS feed, calculates the splits and sends a keysend payment to each recipient’s Lightning node. Keysend is a spontaneous payment method requiring no invoice from the recipient. The boostagram travels inside a custom TLV record attached to that payment (record 7629169, defined by the Satoshis.Stream convention), carrying the sender name, message, application, episode and total amount.
That design works well and it is entirely opaque to any third party. A keysend payment moves between two nodes and its TLV record is delivered only to the recipient. There is no public broadcast and no intermediary with visibility into the transaction. The only parties aware that the boost occurred are the sending application and the receiving nodes.
A boost sent from an application that does not publish to Nostr is therefore not missing from this index; it was never observable in the first place. The same applies to streaming sats, which are sent by the same keysend mechanism on a per-minute basis and are not announced individually.
Interpreting the Numbers
The practical consequence is that this data should be treated as a sample rather than a census. A show with no boosts recorded here may be receiving substantial support through keysend. A show ranked highly here may simply have an audience concentrated in an application that publishes to Nostr. The rankings measure boosts published to Nostr, which is a meaningful quantity and one that was not previously measured anywhere, but it is not equivalent to total boost activity.
Stated plainly: absence from OnlyBoosts indicates nothing. Presence indicates something.
How the Index Is Built
- Scan. A collector continuously queries a curated set of relays, along with the personal relays of every npub previously observed boosting, for events carrying podcast tags.
- Classify. Events carrying a NIP-73 podcast tag and a payment signal are retained. Everything else is discarded.
- Enrich. Each show and episode is looked up in the Podcast Index by GUID to attach its title, artwork and air date, and the booster’s public Nostr profile is resolved for a display name and avatar.
- Serve. The result is written out as plain JSON and served openly. This website reads exactly the same files that are available to anyone else.
An initial backfill reached as far back as relays still retain these events, approximately October 2024. An incremental scan runs roughly every fifteen minutes to keep the index current, and a daily pass widens the set of relays queried.
Applications Publishing Boost Notes
Three sources are known to be publishing NIP-73 boost notes at present.
- Fountain publishes a note referencing a Lightning zap receipt for the amount. This accounts for the bulk of the data.
- BoostMeBitch publishes a note carrying an explicit
amounttag. - Local Bitcoiners publishes a note carrying an
amounttag from its website boost widget.
That is a short list and it is the single largest constraint on this data. Nothing about the index is specific to those three applications, however. NIP-73 is an open standard, so any application that begins publishing boost notes in the same format will appear here automatically, without registration or coordination. The coverage of this index improves as adoption grows; that is the premise the site is built on.
How Amounts Are Determined
Boost notes do not all state their amounts the same way, and some do not state an amount at all. Every record carries the method used so that the figure can be weighed accordingly.
| Source | Definition | Confidence |
|---|---|---|
amount_tag |
The note carries a structured amount tag, denominated in millisats. |
Strongest. An explicit machine-readable figure supplied by the application. |
zap_receipt |
The amount is read from a Lightning zap receipt referenced by the note. | Strong. A receipt exists for a paid invoice, though it is per-leg and is not proof that the full split settled. |
content |
The amount was parsed from the text of the note because no tag or receipt was present. | Weakest. A human-readable figure with no structured backing. |
t_tag / none |
The event was recognized as a boost, but no amount could be determined. | Displayed with no sats figure. |
Limitations and Disclaimers
The constraints below are material to how the figures on this site should be interpreted, and they are worth reading in full.
A boost note is a claim, not a receipt. Nostr and Lightning are independent systems. A boost note contains no cryptographic link proving that a payment was attempted, that it settled, or that any recipient received it. The note is the sending application’s assertion that a boost occurred, signed with the sender’s key. The amounts shown here are a strong social signal; they are not audited settlement data.
Amounts Reflect Intent, Not Delivery
A boost is split across every recipient named in the value block, and individual legs fail routinely when a node is offline or no route can be found. The sats that actually arrive can therefore be less than the total the note claims. The figure generally reflects what was attempted rather than what was delivered.
The Record Is Incomplete
This index contains only those boosts that an application chose to publish to Nostr and that reached a relay included in the scan. Keysend boosts, streaming sats and every application that does not publish to Nostr are absent entirely. See Keysend Boosts above; this is the most significant limitation on the data.
Identity Is a Key, Not a Verified Person
The booster is whoever controls the signing key. In Fountain’s case that is frequently an application-managed key rather than the individual’s primary Nostr identity, and some boosts are anonymous. Display names and avatars are self-declared profile data; no identity here is verified, and nothing prevents two npubs from claiming the same name.
Podcast Metadata Can Be Missing or Incorrect
Titles, artwork and air dates are drawn from the Podcast Index and keyed by GUID. Feeds that are not present in the Index display limited information, and some episode GUIDs cannot be resolved at all, as the specification permits any opaque string and many feeds use a URL. The boost is still counted; it simply cannot be presented with metadata.
History Is Bounded by Relay Retention
The index reaches back only as far as relays still hold these events, approximately October 2024. Boosts older than that have aged off the network and are unrecoverable. Relays are under no obligation to retain anything.
Deletions May Persist Briefly
If a boost note is deleted on Nostr, a copy may remain in this index for a period before it clears.
All Indexed Data Was Already Public
OnlyBoosts publishes nothing private. Every event indexed here was openly broadcast to public relays by the application that sent it, which is what publishing to Nostr means. This site gathers and organizes that data; it does not disclose anything that was not already accessible.
Frequently Asked Questions
Why is my boost not listed?
In most cases because the application sent it over keysend and never published it to Nostr, which is how the majority of boosting works. Nothing was lost; there was simply no public note to collect.
The remaining possibilities are that the note reached only relays outside the scan, that it predates relay retention, or that it carried podcast tags but no detectable payment signal and was discarded during classification.
How current is the data?
An incremental scan runs roughly every fifteen minutes, so a boost note typically appears here within minutes of being published. A daily pass queries a wider set of relays and picks up anything the incremental scan missed.
The site itself reads a static snapshot that is regenerated on the same cycle, which is why the feeds load without querying relays from your browser.
Does OnlyBoosts take custody of any funds?
The index does not. It takes no custody of funds and processes no payments; it reads notes that already exist publicly on Nostr.
Boosting from this website is a separate feature. When a boost is sent from here, the site reads the value block from the show’s own RSS feed and pays those recipients directly from your wallet. The sats go where the podcaster’s feed specifies.
How does a podcast app get its boosts included here?
Publish a kind 1 note when a boost is sent, carrying the NIP-73 podcast tags (podcast:guid for the show and podcast:item:guid for the episode) along with a payment signal. An amount tag denominated in millisats is the strongest option; a t tag identifying the note as a boostagram is also recognized.
That is the entire integration. There is no registration, no API key and no permission required from this site; the notes are collected on the next scan. That is the advantage of building on an open standard rather than a platform.
Why do the rankings look wrong for a show I know is doing well?
Because the rankings measure boosts published to Nostr rather than boosts sent. A show whose audience uses keysend-only applications can be very well supported and still barely register here. The figures should be read as a floor, not a total.
Why is my boost listed when I never posted anything to Nostr?
Because the application you boosted from published the note on your behalf. Some podcast apps create and manage a Nostr key for each user and publish a boost note automatically when a boost is sent; the note is signed with that key and broadcast to public relays, where it is readable by anyone who requests it.
That happened before this site observed anything, and OnlyBoosts adds no private data to it. If publishing on your behalf is not the behavior you expected, that is a reasonable question to raise with the application’s developers.
Is the underlying data available to build on?
Yes. The index is served as plain JSON over an open endpoint, and this website reads exactly the same files that are available to anyone else. The data was public before it was collected here, and organizing it does not make it proprietary.
Something here is incorrect. Where should it be reported?
Use Report a bug in the menu. It publishes a note that is monitored and opens an issue on the repository. Incorrect metadata, a misattributed boost or a show that should not be listed are all appropriate to report.