About

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.

Becoming a Member

A member is anyone who has shared a boost publicly using their Nostr account.

There is no account to create on this site, no form to complete and nothing to join. The membership is assembled out of boosts that were already public, and the reason they are public is Nostr.

What Nostr Does Here

An ordinary boost is a private transaction. Sats move from a listener’s wallet to the recipients a podcast names in its RSS feed, the message travels attached to that payment, and the only parties who ever see it are the sender’s application and the receiving nodes. Nothing announces it. That is how the majority of boosting still works, and it is invisible to this site by design rather than by accident.

Nostr is an open protocol for publishing signed messages to a network of independent servers. It has no accounts in the usual sense; an identity is a cryptographic keypair, and the public half of it is what everything you publish is signed as coming from. Nostr Fundamentals sets that out at length.

When a podcast application publishes a boost note to Nostr, it takes the facts of a payment that already happened and puts them on a public, permanent record: the show, the episode, the amount, the message, and the identity that sent it. That note is not the payment and does not carry it. It is an announcement, signed by a key, that anyone can read and anyone can verify.

This site reads those announcements. Nothing else. Every figure on OnlyBoosts was published to Nostr by somebody who chose to publish it, which is what makes an open index of boosting possible at all: there is no company to ask for the data and no permission to be granted, because the data was already broadcast in public.

Your membership, therefore, is your own. It is attached to a keypair you hold rather than to a profile on this site, it works the same way on every other application reading the same protocol, and nothing here can revoke it.

Applications That Publish Under Your Own Identity

What varies is whether the application publishes anything, and which key it signs with. Three are known to publish under a key belonging to the listener.

• Fountain publishes a boost note automatically and accounts for the bulk of what this index holds. The signing key is one Fountain manages on your behalf rather than an identity you brought with you, so a name here will not always match the one you use elsewhere on Nostr.
• BoostMeBitch publishes a note signed by the Nostr identity you connect to it.
• OnlyBoosts publishes a note for a boost sent from this site, signed by the identity you signed in with, when you choose to share it. A boost sent from here and not shared is not counted, on exactly the terms applied to every other source.

That is a short list and it is the single largest constraint on this data. It is not, however, a closed one. NIP-73 is an open specification and this site operates no registry: an application that begins publishing boost notes in the format set out under How the Index Is Built appears here on the next scan, with no registration, no key and no permission required from anyone. The coverage of this index improves as adoption does, which is the premise the project rests on.

A fourth source, Local Bitcoiners, publishes boost notes from its own website widget and is not listed above for one reason: it covers a single show rather than a catalogue, so it is not a route a listener can take to boosting podcasts generally. Its boosts are indexed on the same terms as any other.

Boosting without any of this remains entirely possible, and nothing about it is worse. A listener who never publishes a note has still paid the show; the sats and the message arrive exactly the same way. What they do not get is a public record, which is the whole of what membership here means. Accounts That Publish for Other People covers the third case, where somebody else publishes the note instead.

Accounts That Publish for Other People

A second route into this index exists, and it produces a different result. It is the explanation for any boost here carrying a name that is not a person’s.

Because most podcast applications publish nothing to Nostr, a small number of automated accounts have stepped into the gap. They observe boosts sent by listeners who published nothing themselves and publish a note for each one, so the boost is recorded rather than lost. Five such keys are known to this index.

• BoostMeBitch keeps a site account for the same purpose, publishing a note for a listener who boosted from that site without connecting an identity. It therefore appears in both lists on this page: the application publishes under your own key when you have one, and under its own when you do not.
• Boostr_Bot publishes a note for every boost received by a value-block split that names it. A podcaster adds its Lightning address as a small leg of their split, and each boost that leg receives is recorded here, whichever application sent it.
• lnaddress music publishes boosts sent to music feeds through a Lightning address.
• Local Bitcoiners publishes a note for a boost to that show where the donor produced none themselves, which is the case for roughly a quarter of them.
• OnlyBoosts signs a note for a boost sent from this site by someone with no Nostr identity, so a listener who wants no account still counts toward the show’s totals.

The list is maintained by hand and nothing detects these accounts automatically. Identifying an account as one of them is a claim, and the cost of getting it wrong is a real person left off a leaderboard.

Why the Boost Is Credited to the Key

These notes frequently name the person who sent the boost, either in the message or in a sender field. That name is not treated as an identity here and cannot be, because nothing verifies that the person named authorised a note signed by a key they do not hold. The booster credited is therefore the key that signed the note, and the name travels as ordinary text. The same rule is applied to this site’s own bot.

The consequence is worth stating plainly, because it runs in both directions. Every one of these boosts is indexed: it counts toward the sats and boost totals, appears on the show and episode pages, and ranks in the feeds exactly as any other boost does. Nothing about it is second class. What these keys are excluded from is the two surfaces that rank people, being the member wall and the #40HPW boards. A single key carrying a thousand boosts from dozens of different listeners would lead both, on other people’s listening, and that is a claim about who the top members are that the data cannot support. They remain findable by search, since a search result is not a ranking, and each has an ordinary booster page.

They are listed on the Members tab with their totals rather than quietly removed. The role they fill is a real one: they are the only reason a listener who wants no Nostr account is represented on this site at all.

Indexer Stats

The figures below are the indexer’s own totals, recomputed each time the collector publishes. They describe what this index holds rather than what the podcasting network has sent: every count is bounded by the small number of applications publishing boost notes to Nostr and by the relays the collector reaches. The Since figure is the earliest note the initial backfill could recover, which relay retention placed at around October 2024, rather than the date on which boosting began; Limitations and Disclaimers sets out what these numbers do and do not account for.

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.

When the Show Tag Is Not a Show GUID

The matching described above depends on the podcast:guid tag actually carrying the show’s RSS GUID, the stable UUID that identifies the feed. Some applications put something else there. The note is a genuine boost; only the value naming the show is malformed. Three shapes account for nearly all of it.

Left untouched, every distinct wrong value looks like a separate show. One real podcast fragments into a scatter of phantom entries, each holding a slice of its boosts. That understates the show’s totals, lowers where it ranks, and inflates the count of shows overall.

The index repairs the shapes it can resolve with confidence. A numeric feed identifier is looked up (usually against the feed address the same note also carries, otherwise through the Podcast Index directly) and mapped to the show it belongs to. A GUID with an episode number stuck on the end has the suffix removed to recover the underlying show. In both cases the stray boosts are folded back into the real podcast and the phantom entries disappear.

A freeform label cannot be repaired the same way. A value such as 20250508FH holds no reliable link back to a show’s real GUID; it is a name one application chose for one episode, and inferring the show from it by pattern-matching would risk filing boosts under the wrong podcast. These are therefore left as they stand: each remains a separate entry marked as an unidentified show, reunited with its real feed only when that mapping is established by hand. This is the least resolvable of the three, and for now the largest.

In every one of these cases the boost itself is indexed and counted. What a malformed identifier costs is attribution; the boost may sit under an unidentified show rather than alongside the rest of that podcast’s support. What it never costs is the record that the boost occurred.

What Is Not Indexed

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, and is loaded in the same pass into a query database that answers the ranking, paging and search behind the feeds. Both are built from the same records; the query layer exists because ranking every episode in the index is not work a browser should be sent a corpus to do.

An initial backfill reached as far back as relays still retain these events, approximately October 2024. Two collectors have kept the index current since.

• An incremental scan, every five minutes. It queries a core set of roughly a dozen relays selected for boost density, enriches whatever is new, rebuilds the JSON and refreshes the query layer every feed on this site reads. A run completes in about fifteen seconds. This is what makes a new boost appear.
• A deep sweep, once daily. It resolves each booster’s own declared write relays and queries those as well, recovering boosts that landed only on a relay the core set does not reach. The core relays already carry approximately 99.6% of what is found, so this pass is a completeness backstop rather than the mechanism that keeps the site current.

Query responses are then held at the content delivery network for thirty seconds, so a boost note reaches the feeds within about five minutes of being published, and within six in the worst case, where a note misses a scan by seconds. The published JSON files are cached for five minutes instead; the figures under Indexer Stats above are the one thing on this site still read from them, so they can lag the feeds by that much.

Applications Publishing Boost Notes

Four sources are known to be publishing NIP-73 boost notes at present, one of which is this site.

• 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 amount tag.
• Local Bitcoiners publishes a note carrying an amount tag from its website boost widget.
• OnlyBoosts publishes a note for a boost sent from this site, when the booster is signed in and elects to share it.

Those four are applications a listener boosts from directly. A further five keys publish boost notes on behalf of listeners who published nothing themselves, and Accounts That Publish for Other People covers them and how they are counted.

This site indexes its own output on the same terms as every other source; it receives no precedence in the feeds or the totals, and a boost sent from here that is not shared to Nostr is not counted, exactly as for an application that publishes nothing.

That is a short list and it is the single largest constraint on this data. Nothing about the index is specific to those four 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.

The OnlyBoosts Charts

Every ranked feed on this site opens on Chart rank, the OnlyBoosts Charts’ composite ordering. The formula is short enough to state in full: a show’s chart score is its rank in total sats, plus its rank in number of boosts, plus its rank in distinct boosters, and the lowest total leads. The same rule orders episodes, albums, songs and artists. For a member, the third component is the number of distinct shows they have boosted, since a person has no booster count of their own.

Summing ranks rather than raw figures keeps any single axis from dominating: one enormous boost moves a show’s sats rank by one position, not by the size of the payment. The approach has long prior art; sailing’s Low Point System and cross-country team scoring are both rank sums.

Each component uses standard competition ranking, in which tied rows share the better place and the next distinct value skips past the group. Ties in the chart total are broken by boosters first, then sats, then boosts; rows still tied after that share their place, marked with a T.

The chart is computed over exactly the view on screen. The time range, the language filter and the Global or Follows scope select the corpus, and every component rank is recalculated inside it, so a show’s position in a 30-day chart is independent of its all-time standing. Positions are comparable only within one view; the underlying score is relative to its corpus and is not a stable quantity across views or across weeks.

The components behind every position are printed on the row itself, so any placement can be checked by hand against the three figures it summarizes. As with every number on this site, the inputs are indexed Nostr boosts and nothing else; see Limitations and Disclaimers.

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.

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 What Is Not Indexed 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. A related case, in which the tag naming the show is not a valid show GUID in the first place, is covered under When the Show Tag Is Not a Show GUID.

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