NIPs by PolleramaCommunity NIPs, surfaced by trustConnect
npub1q3sle0kvfse...

Custom Constellations

Published Jun 28, 2026
kind 30621 · Custom Constellation

Custom Constellations

This NIP defines a user-drawn constellation in the stars.

Kind 30621 — Custom Constellation

An addressable event (kind 30621) representing a single constellation drawn by a user. Because it is addressable, the author may edit/replace it by republishing with the same d tag.

Tags

TagValueRequiredNotes
dslug identifieryesStable identifier for this constellation (per author).
titlehuman-readable nameyesShort display name (e.g. "The Winter Cat").
edge<from_star>, <to_star>1+One edge of the figure. Exactly three elements: ["edge", from, to]. Each endpoint is a Hipparcos catalog number encoded as a decimal string (e.g. "32349" for Sirius). See Star references below.
althuman-readable descriptionyesNIP-31 fallback for non-supporting clients.

The content field is a freeform plaintext description / story / legend for the constellation (may be empty).

Star references

Stars are identified by their Hipparcos catalog number (HIP), not by name. The wire format is the HIP integer encoded as a decimal string with no prefix, no padding, and no whitespace (e.g. "32349" for Sirius, not "HIP 32349" or " 32349 ").

HIP numbers are used instead of names because traditional star names collide (e.g. "Algenib" historically referred to both γ Pegasi and α Persei, "Gienah" to both ε Cygni and γ Corvi), are localized, and get renamed by the IAU. HIP numbers were frozen in 1997, are unambiguous, and cover every naked-eye star.

Example

{
  "kind": 30621,
  "content": "Two bright eyes watching over the winter sky.",
  "tags": [
    ["d", "winter-cat"],
    ["title", "The Winter Cat"],
    ["alt", "A custom Birdstar constellation: The Winter Cat"],
    ["edge", "32349", "37279"],   // Sirius → Procyon
    ["edge", "37279", "37826"],   // Procyon → Pollux
    ["edge", "37826", "36850"],   // Pollux → Castor
    ["edge", "36850", "24608"],   // Castor → Capella
    ["edge", "24608", "21421"],   // Capella → Aldebaran
    ["edge", "21421", "24436"],   // Aldebaran → Rigel
    ["edge", "24436", "32349"]    // Rigel → Sirius
  ]
}

Validation

A client receiving a 30621 event should:

  1. Verify that d and title tags exist and are non-empty strings.
  2. Collect all edge tags. A valid edge tag has exactly three elements —

["edge", from, to] — where from and to each match /^\d+$/ and parse as a positive integer. Tags not matching this shape are ignored.

  1. Resolve each edge's HIP numbers against the local star catalog. Edges

referencing HIP numbers not in the local catalog are silently dropped rather than failing the whole constellation.

  1. Ignore the event entirely if it has zero resolvable edges after

validation.

Rationale

  • **Why not e tags?** The single-letter e tag is a reserved core Nostr

tag meaning "event reference" (see NIP-01, NIP-10). Overloading it with star references would pollute relay indexes and mislead any generic client or tool that inspects the event. edge is an unambiguous multi-letter tag whose meaning is local to this kind.

  • Why an edge list (not a single polyline)? Real figures branch and

loop — Orion has a belt with legs and shoulders, the Big Dipper is a cycle with a handle. A single ordered path cannot express branching without duplicating stars. An edge list is the natural representation for arbitrary figure topology (trees, cycles, disconnected components).

  • Why Hipparcos numbers, not star names? Traditional names are

ambiguous, localized, and subject to IAU renaming. HIP numbers are unique, permanent, and recognized across every astronomy catalog.

  • Why addressable? Authors can iterate on a drawing over time without

creating duplicate events.