CraysTreasures
Treasures is what happens when Nostr leaves the feed and walks into a park with a phone, a map and a printed QR code. The app is still young, but its design choices are unusually revealing.
The cache is the signed object
Treasures is not a social feed with a map widget bolted to the side. Its central object is a geocache: a hidden physical thing, or at least a physical place, described by a signed Nostr event. The app asks a simple but strange question: what if a cache listing did not live inside one platform's private table? What if the title, description, location, difficulty, terrain, size, hint, images, preferred relays and verification key were public event data that any compatible client could read?
That is why Treasures feels more consequential than its playful surface suggests. A normal geocaching app can make a listing look portable while keeping the real state in one company's database. Treasures moves the main record into Nostr events. The map is the interface, but the event is the product. A cache owner signs a listing. A finder signs a log. A QR code inside the physical cache can prove that the finder actually reached the place. Relays become the shared terrain where that history is stored and rediscovered.
The live site presents itself plainly: hide and discover geocaches on the decentralized Nostr network, share locations, log finds and explore the world. Its web manifest classifies the app as games, travel, lifestyle and social, with a standalone PWA display and a portrait-first orientation. That is a good summary of the user experience. Treasures is meant to be opened on a phone, outside, with a map in one hand and a real object somewhere nearby.
The GitLab README gives the more technical version. It lists an interactive map, adventure logs, QR code verification, compact QR URLs, Nostr login, no email registration, location search, zaps and offline PWA support. It also says the source is AGPLv3. The important word there is not only open. It is inspectable. For an app that handles locations and proof of physical presence, being able to read the code is not a nicety. It is part of the trust model.
Why this is not just a map
Open the implementation and the product shape gets clearer. The current source tree is a React and TypeScript app built with Vite, Tailwind, shadcn/ui, Radix components, TanStack Query, Leaflet, React Leaflet, Nostrify and nostr-tools. It also carries Capacitor dependencies and an Android project path, which means the project is not only thinking as a static web toy. It has mobile packaging in view.
The live HTML preconnects to CARTO base-map hosts and Esri's ArcGIS tile server, then loads a Vite bundle. The code uses Leaflet for map rendering and includes map controls for near-me behavior, search results, user location, cache markers and selected cache views. The map layer matters because Treasures is not merely asking relays for posts. It is translating geohashes into a spatial user experience: a nearby list, a marker cluster, a detail card and a route someone can follow with their body.
That changes the privacy model. Nostr events are public by default. Relays can copy them. Search relays can index them. If a listing uses very precise coordinates, the app may be helping people find a cache, but it is also publishing a location that can be scraped, mirrored and correlated. Treasures tries to work inside that reality rather than pretending it does not exist. Its coordinate utilities generate multiple geohash precision levels, and the NIP-GC document tells clients to validate precision before accepting submissions. That is useful for map queries, but it is also an exposure decision.
The app's default relay set is explicit in source: Ditto, Damus, nos.lol and Dreamith, with Ditto and Dreamith also used as search relays. There is a relay manager for normal read/write relays and a separate search relay settings panel that can publish kind 10007 search relay lists. This is a rare place where a casual user can see one of Nostr's hardest product problems. If your relays do not have the events, the world appears emptier than it is. If your search relays are weak, a cache can exist and still feel lost.
Treasures also adds a NIP-89 client tag when publishing from production HTTPS. That tag identifies the event as coming from Treasures and points to a handler address on `wss://relay.ditto.pub`. This is small, but it is useful. It lets other clients and indexers understand which software created a cache or log, instead of treating every signed event as a contextless blob.
The protocol trail is messy
The most important technical detail is that the geocaching standard is still moving. The public NIP-CC page on nips.nostr.com describes a draft optional geocaching NIP and, in the raw document I checked, defines kind 37515 as a geocache listing and kind 37516 as a geocache log entry. Treasures, however, ships its own `NIP-GC.md` in the app repository and its production bundle uses a different set: kind 37516 for geocache listings, kind 7516 for found logs, kind 1111 for comment logs, kind 7517 for verification events, kind 30001 for bookmark lists, kind 37517 for adventure or curation lists and kind 31234 for drafts. It also keeps kind 37515 as a legacy geocache kind.
That discrepancy is not a scandal. It is what draft standards look like before several clients have beaten them into shape. But it is a practical warning. If you publish a Treasures cache today, do not assume every future geocaching client will read it perfectly unless it supports Treasures' NIP-GC dialect or the standard converges around the same kind numbers and tags. Interoperability is not a slogan; it is a test you run.
Treasures' own NIP-GC is more expressive than a bare cache listing. A cache event includes a `d` tag, a `name`, one or more `g` geohashes, difficulty `D`, terrain `T`, size `S`, cache type `t`, optional `n` modifiers, hint, mission, images, preferred relay tags and a verification public key. Found logs use kind 7516 with an `a` tag pointing back to the cache. DNF, notes, maintenance and archive comments use NIP-22 style kind 1111 comments with root and parent tags. Verification uses kind 7517, signed by a cache-specific verification key.
The result is more like a small spatial protocol than a single app feature. You can imagine another client that only shows the map. You can imagine a relay that specializes in a city or trail network. You can imagine an archive that counts DNFs and maintenance notes. You can imagine a wallet-oriented client that highlights caches whose owners receive zaps. That is the point of doing this on Nostr: the record can escape the first interface.
Physical proof changes the game
The cleverest Treasures idea is the verification QR. The cache owner can generate a verification key pair and print a QR code for the cache. The URL can carry either a standard `#verify=` fragment with an `nsec`, or a compact `/c/...` payload. The README describes a 70-byte compact payload containing the cache owner's pubkey, a short d-tag and the verification private key. The QR dialog warns that this URL contains the private verification key and should not be shared publicly.
That is a strange sentence for normal users, but it is exactly the right sentence. The verification key is supposed to be found by physically reaching the cache. If somebody photographs the QR and posts it online, the proof collapses. If a finder scans it in place and signs a verification event, Treasures can embed a kind 7517 verification event inside a found log. The app then has stronger evidence than a text note saying "found it."
This is where Treasures becomes more than a decentralized clone. A signed note proves that a key holder said something. It does not prove that they stood under a bridge or opened a box in a tree. A cache-specific verification key is still not perfect proof, but it ties the claim to an object that was meant to be physically accessible only at the cache. That lets Treasures support first-to-find treasures, art drops, key quests and one-off physical rewards in a way a generic social client would not.
The app's `first-to-find` modifier is especially telling. In the NIP-GC draft, the first valid verified found log becomes the provisional exclusive claim. Later, the cache owner can publish a revised listing with an `F` tag locking the winner's pubkey, because event timestamps are author-supplied and can be forged. That is an adult protocol detail. It accepts that public event systems need correction mechanisms, not just enthusiasm.
There is also a Good Deed NIP draft in the repo. It defines kind 5777 for first-person attestations of helpful or pro-social acts, with optional `a`, `e`, `i`, `p`, `t` and location tags. Treasures' NIP-GC says a mission completion can be recorded as a Good Deed event. That points toward a broader design space: not just "I found this cache," but "I completed a place-based task, left something better, or performed a challenge connected to this location."
The operator and code trail
The public operator trail is unusually clear for a small Nostr app. The Soapbox announcement from June 9, 2025 says Treasures was built by Chad Curtis using MKStack and frames it as a decentralized alternative to centralized geocaching platforms. The same announcement appears as a Team Soapbox Nostr note, with Team Soapbox's npub and a mention of Chad's Nostr profile. AlternativeTo lists Chad Curtis as the developer and describes the app as open source under AGPL-3.0. The GitLab project sits at `chad.curtis/treasures`, was created May 28, 2025 and has an active commit history.
That last phrase is not decoration. At the time of this pass, the GitLab API showed recent commits on June 6, 2026, including version 2.6.1 and BOQM Austin work. The live source also contains an Android package path `to.treasures.app`, a service-worker-style offline story through PWA dependencies and Capacitor integrations for camera, clipboard, filesystem and keyboard. Treasures is not abandoned catalogware.
The Soapbox orbit matters because Treasures is not isolated. MKStack is Soapbox's AI-assisted framework for building Nostr clients, and the MKStack page lists Treasures among apps made with the framework. The stack includes Nostr login patterns, NIP-07 browser signing, relay management and common UI building blocks. That explains why Treasures looks like a complete product rather than a one-file proof of concept. It also means the app inherits the strengths and risks of framework-generated Nostr software: fast iteration, reusable patterns, and the need to audit what the framework hides.
The login path is worth reading closely. `useCurrentUser` supports `nsec`, `bunker` and `extension` logins. In plain English, that means Treasures can use a raw private-key login, a NIP-46 bunker or a NIP-07 browser extension. The safer path for most readers is a signer or bunker that makes approvals visible. A geocaching app does not need permanent blind signing power over your whole Nostr identity. It needs the specific events you choose to publish.
The app also contains zaps. Its dependencies include `@getalby/sdk`, the UI has a `ZapButton`, and the README says users can send Lightning zaps to cache creators and finders. That is culturally important even if most users never send much value. It makes a cache not only a place, but a small reward economy: a good hider can be tipped, a finder can receive recognition, and a local adventure can have a payment trail without becoming a corporate marketplace.
Risks worth taking seriously
Treasures has the normal Nostr risks and then adds physical-world risk on top. A public key is pseudonymous, not magically private. If you publish a cache near your home, workplace, favorite walking route or private property, you may be telling strangers more than you intended. If you log finds in a tight pattern, you may reveal habits. If you upload photos, EXIF location data, faces, street signs or interior details can give away more context than the geohash does.
Deletion is also not normal app deletion. Nostr has deletion request events, and Treasures has delete flows, but relays are independent. A cache that was seen by one relay, indexer or screenshot can persist elsewhere. That is not a reason to avoid the app. It is a reason to treat cache publication like public writing, not like a note in a private database.
The QR proof system has its own failure modes. A verification QR is useful only while the private key remains physically controlled. If somebody leaks it, steals the printed code, clones the cache container or shares the compact URL in a group chat, fake verified finds become possible. If a cache is vandalized, moved or archived late, old events can keep making it look active. Treasures addresses part of this with maintenance, archived tags and owner updates, but the social layer still depends on people reporting the truth.
Map providers are another quiet dependency. The live page preconnects to third-party tile hosts, and the app uses browser geolocation, IP fallback and map tiles to give a near-me experience. That is convenient, but it means your browser, device and network may expose information outside Nostr before any event is signed. Users who care about location privacy should test what loads, what permissions are requested and what they are comfortable sharing.
There is also a moderation question. Geocaches are not just words. They can point people toward unsafe terrain, private land, culturally sensitive places, illegal drops or harassment targets. A decentralized cache network cannot rely on one central company to screen every listing. The safer future is likely a mix of relay policy, reputation, user filters, local community norms and visible maintenance history. Treasures is early enough that this is still being invented in public.
How to test Treasures
The right test is not to publish your first cache at your front door. Start by browsing. Open the map, check which relays are enabled, search a location you know, and inspect how a cache detail page presents the owner, description, logs, images, difficulty, terrain and relay hints. Then check whether the same event can be found from another Nostr tool or relay-aware client. If it cannot, decide whether that is because the standard is still young, the relay set is too narrow or the event is app-specific.
If you create a test cache, use a harmless public location, broad safety judgment and a throwaway practice object. Look at the signing prompt. Confirm the event kind. Confirm that the `g` tags match the precision you intended. Confirm whether the app includes relay tags and a client tag. If you generate a verification QR, handle it like a secret until it is physically placed. Print it only when you understand that the URL carries a private verification key.
For builders, the best reading path is code first, marketing second. Start with `NIP-GC.md`, `src/utils/nip-gc.ts`, `src/stores/useGeocacheStore.ts`, `src/hooks/useCreateLog.ts`, `src/utils/verification.ts`, `src/lib/appRelays.ts` and the live bundle. Compare that to NIP-CC. The gap between those documents is exactly where implementation risk lives. It is also where an opportunity lives: a second compatible client would make Treasures more than one product. It would make Nostr geocaching a small protocol area.
For normal users, the short answer is simpler. Treasures is worth trying if you like outdoor games, open protocols and experiments that touch the real world. It is not worth using casually if you do not want public location data tied to your Nostr identity. Bring curiosity, but bring caution too. This is one of the rare Nostr apps where the bug report might be digital and the consequence might be standing in the wrong place.
Sources worth opening
Start with the app and source tree, then compare the app-specific NIP-GC document to the public NIP-CC draft. That comparison explains most of the product.
- Treasures official app
- Treasures PWA manifest
- Treasures live JavaScript bundle
- Treasures live CSS bundle
- Chad Curtis / Treasures on GitLab
- Treasures README
- Treasures package.json
- Treasures AGPLv3 license
- Treasures commit history
- Treasures NIP-GC draft
- Treasures NIP-GD Good Deed draft
- Treasures NIP-GC utility code
- Treasures geocache store
- Treasures log publishing hook
- Treasures verification utilities
- Treasures verification QR dialog
- Treasures app relay defaults
- Treasures login hook
- Treasures publish hook
- Treasures relay list manager
- Treasures search relay settings
- Treasures map component
- Treasures location picker
- Treasures geolocation hook
- Soapbox announcement
- MKStack overview
- Team Soapbox Nostr announcement
- Treasures on NostrApps
- Treasures on AlternativeTo
- Stacker News Treasures post
- Nostr Compass tracking note
- NIP-CC Geocaching Events
- Raw NIP-CC draft
- NIP-01 basic protocol flow
- NIP-07 browser signer
- NIP-22 comments
- NIP-33 parameterized replaceable events
- NIP-57 Lightning zaps
- NIP-65 relay list metadata
- NIP-89 recommended application handlers
- Leaflet map library
- TanStack Query
- Nostrify
