NIP-CC: Geocaching Events
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 needs to 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 you takeaway is that NIP-CC is ambitious but early.
Map UX and privacy must be designed together
A geocaching client needs to 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 needs to 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 need to avoid overexposing exact movement history by default.
Read NIP-CC in the wild
NIP-CC puts geocaching into Nostr's signed event world. It shows how location games and treasure-hunt style communities can use portable identity and event records.
Location is sensitive. Clues, finds, coordinates and photos can reveal habits or private places. A playful feature still needs consent and safety language.
What changes when you actually use it
For you, NIP-CC: Geocaching is felt when a specialized experience still remains portable. Games, forums, handlers, static sites and local transports become useful only when another client can understand the same object. The source terms kind 37516, kind 7516, kind 1111, kind 7517, kind 37517, draft are the difference between an open feature and a private app convention.
What changes for builders and operators
For builders, NIP-CC: Geocaching needs cross-client proof. Create an object in one product, open it in another, then test what survives without special server knowledge. That is where an app-specific idea becomes a real Nostr surface.
What the official file makes concrete
The official file is organized around Geocache Listing Event (Kind 37516), Content, Tags, Found Log Event (Kind 7516), Tags, Comment Log Events (Kind 1111), Tags, Geocache Verification Event (Kind 7517). Inspect kind 37516, kind 7516, kind 1111, kind 7517, kind 37517, draft, name, D because these are the pieces most likely to surface as product behavior. Read it beside NIP-22, NIP-19 before treating it as isolated.
NIP-CC: Geocaching earns trust when a second client can understand the same object without a private handshake.
Where it breaks
The failure mode in NIP-CC: Geocaching is private interoperability. The event exists on Nostr, but only the original app knows how to use it. Test a second interface and a second relay before calling the feature portable.
Where this appears outside the markdown
In the ecosystem, NIP-CC: Geocaching is where Nostr stops being only a feed and becomes a surface for specialized products: forums, games, static sites, handlers, local transport or application state. The standard matters only when another client can open the same object without calling the first app for private instructions.
The nearby-standard trap
The nearby-standard trap in NIP-CC: Geocaching is mistaking novelty for interoperability. A clever app-specific event is not a standard until another client can use it. Read NIP-22, NIP-19 to see whether the feature has a path out of its first product.
Language that keeps the feature honest
Good product copy for NIP-CC: Geocaching names portability. It tells you whether another client can open the object, whether a relay or app-specific convention is required, and what might fail when you leave the original product.
What this page does not promise
NIP-CC: Geocaching does not make a niche feature portable just because it uses Nostr events. Portability begins when another client can parse the object, recover the context and show a useful experience without a private API. Read NIP-22, NIP-19 and look for second-client evidence before treating the format as settled.
Read it as a field test
Start NIP-CC: Geocaching with interoperability. If kind 37516, kind 7516, kind 1111, kind 7517, kind 37517, draft cannot travel into another useful interface, the feature is still mostly an app convention. Read NIP-22, NIP-19 and look for public examples before assuming a specialized NIP has become a stable product surface.
Where the standard earns trust
The source links give you places to test the interpretation in public: PR #2365, NIP-22 Comments, NIP-73 External Content IDs, Geocaching.com cache sizes. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-CC source is the anchor for exact wording, and NIP-CC commit history shows how that wording moved over time. The strongest secondary clues here are PR #2365, NIP-22 Comments, NIP-73 External Content IDs. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-CC: Geocaching: first the human promise, then kind 37516, kind 7516, kind 1111, kind 7517, kind 37517, draft, then the implementation record, then the real-world failure case. That order keeps NIP-CC useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Can a second app open the object and make it useful, or does the first product still carry the real meaning?
- Which part is standardized in
kind 37516,kind 7516,kind 1111,kind 7517, and which part remains a convention, server policy or UI choice? - What happens when the app, relay, local transport or handler that created the object is gone?
What to verify before you rely on it
- Find
kind 37516,kind 7516,kind 1111,kind 7517,kind 37517in the official file and check where the UI exposes the same concept. - Read NIP-22, NIP-19 as context before treating NIP-CC as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-CC: Geocaching in that order: Official NIP-CC source for the current wording; NIP-CC commit history for the change record; PR #2365, NIP-22 Comments, NIP-73 External Content IDs for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
