NIP-CC: Geocaching Events
NIP-CC brings geocaching to Nostr with addressable cache listings, found logs, comment logs, geohash discovery, difficulty and terrain metadata, verification keys and optional mission-style claim rules.
Geocaching is already a social protocol in the physical world
A geocache listing is a structured public object: a name, location, description, difficulty, terrain, size, type, hint, images and logs from people who found it. NIP-CC maps that existing shape onto Nostr events.
The listing event is addressable kind 37516. Found logs use kind 7516. Non-found comments use NIP-22 kind 1111. Geohash tags make nearby discovery possible without a central platform.
This is one of the more unusual NIPs because it points Nostr toward physical-world activity. The signed event is not the whole experience; the cache is outside.
Cache listings, found logs and verification hooks
A listing includes a d identifier, name, one or more geohashes, difficulty D, terrain T, size S, type t, optional type modifiers, hint, mission text, images, preferred relays and verification pubkey.
A found log references the listing with an a tag and can include images or an embedded verification event. Comments use NIP-22. The spec also includes claim semantics such as first-to-find and mission-style verification.
The NIP borrows familiar geocaching concepts but leaves cache-type support to clients. That keeps the protocol open, but it also means product consistency will depend on implementation choices.
A very recent NIP with rapid expansion
fiatjaf added NIP-CC in May 2026. Chad Curtis updated it in June 2026 to include modern NIP-GC specification material. That makes it one of the freshest pages in the atlas, and it should be treated as a living draft rather than a settled ecosystem.
Because the official file itself points to geocaching.com standards for difficulty, terrain and size concepts, the bridge matters: Nostr supplies signed listings and logs; the field conventions come from geocaching culture.
The useful reader takeaway is that NIP-CC is ambitious but early.
Map UX and privacy must be designed together
A geocaching client should support geohash precision carefully. Too coarse and discovery is useless; too precise and the cache may be spoiled or sensitive locations exposed. Multiple geohash tags at different precision levels can support proximity search.
Found logs should distinguish verified and unverified claims. Images, missions and verification keys can improve trust, but they can also reveal location and user movement.
A good client lets people discover caches, navigate carefully, log finds and read community status without turning private outdoor activity into unnecessary surveillance.
Physical location standards have real-world consequences
A bad cache can send people into unsafe, illegal or environmentally sensitive places. A protocol cannot replace local judgment, land rules or community moderation.
Public logs can reveal travel patterns. Clients should avoid overexposing exact movement history by default.
Direct sources
Use the official file first, then the commit history, implementation references and adjacent standards. NIPs move, and product guidance gets weaker when those source trails are hidden.
