CraysYondar
Yondar is a small but serious experiment: a map where places, owners, follows and nearby conversations are published through Nostr instead of locked inside a platform's location database.
A map is a harder test than a feed
Most Nostr clients ask an easy first question: can this app publish a note and read replies? Yondar asks a harder one: can a person claim a place on a map without handing the whole location database to one company? That is why the little NostrApps summary, "The social map," is accurate but too small. Yondar is about physical places, social trust and geographic context, not only about pins on a screen.
The live app at `go.yondar.me` says the same thing in a more playful voice. It offers sign-in with a NIP-07 browser extension, sign-in with nsec, and quick signup. The FAQ says users can publish places on a decentralized map, see places owned by friends and follows, use GeoChat for posts based on geographic area, and carry the same identity to other Nostr-compatible apps. It also separates the older centralized `yondar.me` from the newer Nostr-powered `go.yondar.me` and says the old web2 PWA was intended to be replaced once the decentralized version reached feature parity.
This is a real product idea, not just a toy category. A standard location platform knows the venue, reviews, owner profile, hours, traffic, search ranking and user movement around the map. Yondar tries to move part of that stack into signed public events. A place can be created by a key. A feed can be filtered to places created by people you follow. A local chat can be scoped to a geohash. A place URL can be shared as a Nostr `naddr`. The ambition is not to beat Google Maps at roads and routing. It is to ask what happens if the social claim around a place is portable.
The operator trail is unusually concrete for a small Nostr experiment. The GitHub organization is `innovatario`, listed by GitHub as InnovatAR Inc in the United States, with the blog URL `https://innovatar.io` and a bio about building the betterverse on Yondar. The Yondar repository describes itself as the monorepo for all things Yondar. The license file reserves the Yondar name, Yondar.Me name, Y symbol and logos as InnovatAR Incorporated trademarks, while licensing the code under Creative Commons Attribution-ShareAlike 4.0 International. That is not a standard software license choice, and readers should notice it: the code can be copied and remixed under that license, but the brand cannot be reused.
Places are Nostr events
The central Yondar object is a Place event. In the source, `src/types/Place.tsx` defines `Kind.Place = 37515`, and `src/libraries/draftPlace.tsx` creates a `kind 37515` event with three key tags: `d`, `g` and `alt`. The content is JSON shaped like a GeoJSON Feature: `geometry.coordinates` contains longitude and latitude, `geometry.type` is `Point`, and `properties` can include name, abbreviation, description, address, Google-style place type, status, website, phone and opening hours.
That design is very deliberate. A `kind 37515` event is in Nostr's addressable event range, so it behaves like a replaceable object scoped by kind, pubkey and `d` identifier. The Yondar code calls its helper `NIP-33`, because the old language around parameterized replaceable events lived there, but current Nostr docs put the `d` identifier and addressable-event rules in NIP-01. Yondar also uses NIP-19 `naddr` links, so a place can become a URL like `/place/
The `g` tag is the bridge between Nostr and the map. In plain terms, the g tag is what lets a signed event behave like something a map can query. Yondar uses the `latlon-geohash` package to encode a cursor position into a geohash, stores that geohash in the Place event, and queries or filters by it later. The NIPs registry points to NIP-52 for the `g` geohash tag, and that matters even outside calendar events because it gives clients a familiar way to find geographically relevant events. A geohash is not magic. It is just a compact spatial prefix, but it is enough for relays and clients to begin sorting location data.
Publishing a Place follows a Nostr-native path. `PlaceForm.tsx` gathers form data, removes empty optional fields, stringifies the GeoJSON-like content, signs the event through either a NIP-07 `window.nostr.signEvent` flow or a locally stored private key, and publishes it to write relays through `nostr-tools` `SimplePool`. Editing a place preserves the `d` tag where possible. Deleting a place publishes a NIP-09 `kind 5` deletion request with an `a` tag pointing to the addressable Place event.
A relay spot check on June 7, 2026 found real `kind 37515` events on `wss://relay.primal.net` and `wss://nos.lol`. The samples included restaurant, cafe and point-of-interest Places with `d` tags, `g` geohashes and coordinates. The Yondar-specific default relay `wss://yondar.nostr1.com` did not open successfully during that same check, and `https://yondar.nostr1.com` returned 410 when probed for relay information. That is not fatal because the app also uses other relays, but it is exactly the kind of infrastructure drift a map client must survive.
GeoChat and the social map
Yondar has two social layers. The first is the follow graph. `MapPlaces.tsx` loads all `kind 37515` events from read relays, then builds a contact list from the user's public key plus contact-list entries. In global mode it renders all Places it receives. In the friends/follows view, it only displays Places whose owner pubkey is in that contact list. That is the product idea in one line: a map where your social graph changes the geography.
The second layer is GeoChat. `GeoChat.tsx` watches either the user's GPS position or the map cursor, calculates a geohash length based on zoom, subscribes to `kind 1` notes tagged with `#g`, and filters expired messages. When a user sends a local message, Yondar creates a normal short text note, adds an `expiration` tag for one week, and pushes geohash tags from the current precision down to one-character prefixes. That means a message can be visible at multiple map scales, not just one exact point.
This is clever because it uses ordinary Nostr text notes for local conversation instead of creating a private chat server. It is also fragile because `kind 1` notes are not inherently private, even if they feel local. The FAQ says GeoChat is based on regions and does not share a precise personal location. That is directionally true if the app only publishes coarse geohashes and if users understand the precision. But a public geohash plus timestamp plus content can still leak context. It can reveal that a user was near a venue, protest, office, clinic, conference or home area. Location privacy is not binary.
The product decision to make GeoChat optional is important. A person can publish a public place without using nearby chat. A person can browse the map without posting. A person can choose global or follows-only display. Those controls are the beginning of a privacy model, not the end. The next level would be clearer geohash precision indicators, obvious warnings before publishing, and maybe support for truly private location sharing if the older announcement roadmap ever returns to encrypted ephemeral location sharing.
Keys, signup and local storage
Yondar supports three entry paths: NIP-07 extension sign-in, nsec sign-in and quick signup. The NIP-07 path is the cleanest for a web app because the private key can stay in a signer extension while Yondar asks for public key and event signatures. `src/libraries/NIP-07.tsx` wraps `window.nostr.getPublicKey()` and `window.nostr.signEvent()`, catching user rejection or missing extension errors.
The local key path deserves more attention. `EncryptAndStoreLocal.ts` stores private-key material under the `storens` key in localStorage, derives an AES-GCM key through PBKDF2 with one million iterations, and stores encrypted data, salt and IV. If the user enters no password, the app explicitly warns that the identity will be stored unencrypted in the browser. That is better than silently storing an nsec, but it still means the browser is holding a valuable secret. A map app that can publish places and local chats should not be casual with account custody.
The issue history shows the maintainers understood the UX problem. Issue #6 asked for nsec login plus ample warnings, and pull request #15 added nsec login and warnings. The login code can also publish a basic Nostr profile, relay list and a short "running Yondar" note for a fresh locally generated identity. That is convenient onboarding, but it also means a quick signup can create public events before a user fully understands Nostr.
The safest way to use Yondar is with a throwaway or purpose-specific key first. That is not a judgment on the team. It is a consequence of the category. You are not only testing a social client; you are testing public claims about locations. If you create a place from your main identity and later decide it was too revealing, a NIP-09 deletion request can ask relays and clients to hide it, but it cannot erase copies from every relay, indexer, screenshot or archive.
Location privacy is the main product
Yondar's FAQ states that GPS location is used to show where you are in relation to places, can help put a new place where you are, is not transmitted, and that the code is open source to prove it. The source supports the first half of that claim: the geolocation hook uses `navigator.geolocation.watchPosition`, and the map uses the live position to center or follow the user. The more subtle question is not whether raw GPS is transmitted automatically. It is what the user chooses to publish after the app makes the map feel natural.
A Place event is public by design. It can include precise coordinates, name, address, phone, website and hours. That is fine for a restaurant, museum, conference venue or public point of interest. It is not fine for a private meetup, a home, a shelter, a sensitive office or a place whose owner has not consented to a public cryptographic claim. The app is strongest when used for businesses, attractions and events that actually want a public presence.
The proof-of-place essay linked through Nostr.com frames the hard problem well: if a physical location is owned in the real world, a digital claim should be tied to the right identity, but permissionless publishing means anyone can claim anything. A signed Place event proves that a key made a claim. It does not prove that the key controls the building. That is why Yondar's follows-only view is more than a feed filter. It hints at a web-of-trust model for maps: I care more about places published or vouched for by people I trust.
This is also why ratings and attestations matter. Yondar's old issues include adding a location/business rating scale and manual ratings. Those were closed, but the broader question remains. A map full of signed place claims still needs reputation, moderation and dispute resolution. Open maps fail when spam overwhelms trust. Closed maps fail when one company owns the truth. Yondar sits in the interesting middle: it can make location claims portable, but it still needs social trust to make them believable.
Infrastructure and maturity
The repository is a Vite, React 18 and TypeScript app using Mapbox GL, react-map-gl, nostr-tools, latlon-geohash, Turf and Sass. It is not a heavy server product. It is a browser app that reads and writes Nostr events and renders a Mapbox map. The live page loads as a PWA, with a manifest describing Yondar as "Your Places. Your Friends. Your world." and categories such as augmented reality, gps, social and private.
The repository was created in June 2023, had its latest GitHub push in April 2024, and showed updated metadata in January 2026. The default branch is `master`, the repository has modest public attention, and GitHub reports the license as `NOASSERTION` because the custom license file mixes trademark reservation with CC BY-SA code licensing. That is enough to call it open source in spirit, but not enough to treat it like a standard MIT or GPL dependency.
The maturity signals are mixed. The live app renders and the FAQ is readable. The code shows real Nostr integrations. Recent public `kind 37515` events exist on relays. But the Yondar-specific relay did not open during the June 7, 2026 spot check, the live homepage produced a JavaScript console error about parsing `undefined` as JSON, and a pull request in April 2024 removed two default relays that no longer worked. The app can still be useful, but infrastructure drift is visible.
There is also a governance signal hidden in issue #13: the repository asks people not to open issues there and points to external instructions. That fits the README's reference to a Nostrocket problem tree, although that particular Nostrocket URL returned 404 during this research pass. For readers, the takeaway is simple. Yondar is a working experiment with a public trail, not a polished consumer map company with a full support surface.
The kind 37515 problem
The most important standards detail is not in Yondar's marketing. It is the fate of `kind 37515`. Arkinox opened Nostr NIPs pull request #927 in December 2023 for a Places NIP. The PR body said it evolved the existing Places implementation on `go.yondar.me`, aimed to bridge OpenStreetMap, schema-style location data and Nostr, and wanted feedback to implement into Yondar. That PR was closed in April 2026 without being merged.
At the same time, the current NIPs repository contains NIP-CC, a draft optional Geocaching Events NIP. NIP-CC also defines `kind 37515`, but for geocache listings, with a different content model and required tags such as `name`, `g`, `location`, `difficulty`, `terrain`, `size` and `cache-type`. That is a live kind-collision risk. A Yondar Place and a NIP-CC geocache listing can both be `kind 37515`, yet they do not mean the same thing.
This does not make Yondar wrong. It shows the cost of shipping ahead of standards. Nostr allows experimentation, and deployed clients often prove a use case before a NIP settles. But once another draft lands on the same kind number, clients and indexers need defensive parsing. If an event has `kind 37515` and GeoJSON-like content with business properties, Yondar can read it as a Place. If it has NIP-CC geocache tags and plain-text content, a geocaching client should read it as a cache. A generic indexer cannot safely say "kind 37515 means places" anymore.
This is exactly the sort of detail a serious profile needs to surface. A user may not care about kind numbers, but they will care if their place does not render in another client, or if a future client mistakes a cafe for a geocache. The user-facing test is simple: publish one Yondar Place, copy the `naddr`, inspect the raw event, and check whether another Nostr tool can tell what it is without Yondar's code.
Business trail and team
Yondar did not start as a Nostr-only idea. InnovatAR's commercial Yondar page describes the older product as web-based augmented reality wayfinding and social gaming for outdoor events and attractions. It talks about locating friends and places, creating beacons, self-guided tours, AR wayfinding, visitor traffic, gamification and deployment at parks or events. The FAQ inside `go.yondar.me` says the older `yondar.me` was the centralized web2 PWA and the Nostr version is the new decentralized direction.
That background explains why the product has unusual vocabulary: beacons, dataspace, augmented reality, Cyberspace Meta-Protocol, places and wayfinding. Yondar is not merely another Nostr client founder trying maps for fun. It is a preexisting location/AR concept being pulled toward open social infrastructure. That makes the app more interesting, because the team knows location and events. It also makes the app harder, because event operators and attractions expect reliability that hobby Nostr relays may not provide.
The personal builder trail points to arkinox. The Yondar announcement from November 1, 2023 names the new map client, links the repo, describes Google Business-style place creation with permissionless Nostr publishing, follows-only filtering, cross-client geochats and future plans for encrypted ephemeral real-time location sharing, augmented reality and Cyberspace protocol integration. The GitHub user `arkin0x` has the name arkinox and links to cyberspace.international. That is enough to connect the public builder trail without inventing a team story beyond the sources.
How to test Yondar
Start without using your main identity. Open `go.yondar.me`, read the sign-in choices, and use a disposable key or a signer that makes every permission request visible. Do not publish a private location in your first session. Use a public venue, a fake test entry if you can delete it immediately, or simply inspect existing Places from the map.
Check the event. A real Yondar Place should be a `kind 37515` addressable event with a `d` tag, a `g` geohash, an `alt` tag that points back to a Yondar place URL, and JSON content with Feature, Point coordinates and properties. Then check relays. Publish to more than one write relay if possible, because the Yondar-specific relay was not reachable in this research pass while Primal and nos.lol did return current Place events.
Test the social filter. Follow or use a contact list, switch between global and follows-only views, and make sure the app is not simply showing every place with the same confidence. For a social map, the follow graph is part of the trust model. If everything looks equally authoritative, the product has not solved the map problem yet.
Test GeoChat with caution. A `kind 1` geochat note with an `expiration` tag is still a public note until relays and clients decide to forget it. Post nothing that would reveal a sensitive movement pattern. Zoom level changes geohash precision, so test how broad the area feels before you type.
Finally, test portability. Copy a place `naddr`, open it outside Yondar if possible, and inspect whether the event remains understandable. The promise of Yondar is not that one site has a nice map. The promise is that places can become signed, portable social objects. That promise is real, but it is still early.
Sources worth opening
This article is based on the live app, the public code, GitHub metadata, relay spot checks and Nostr specs. Start here when you want to verify the details yourself.
- Yondar live app
- Yondar live PWA manifest
- Original centralized Yondar PWA
- InnovatAR website
- InnovatAR Yondar product page
- Yondar on NostrApps
- Arkinox Yondar announcement on Nostr
- InnovatAR GitHub organization metadata
- arkin0x GitHub user metadata
- Yondar monorepo
- Yondar monorepo API metadata
- Yondar monorepo file tree
- Yondar README
- Yondar license and trademark notice
- Yondar package.json
- Yondar repository PWA manifest
- Yondar Nostr relay and profile helpers
- Yondar NIP-07 browser signer helper
- Yondar addressable event helper
- Yondar draft Place event builder
- Yondar Place form and publishing source
- Yondar map Place subscription source
- Yondar GeoChat source
- Yondar beacon display source
- Yondar login and profile source
- Yondar FAQ source
- Yondar Mapbox map source
- Yondar geolocation hook
- Yondar local key encryption source
- Yondar development todos
- Yondar issues and pull requests API
- Yondar issue 6: nsec login and warnings
- Yondar issue 8: interoperability previews
- Yondar issue 10: location/business ratings
- Yondar issue 11: manual ratings
- Yondar issue 13: issue-tracker instructions
- Yondar pull request 15: nsec login and warnings
- Yondar pull request 18: naddr fix
- Yondar pull request 21: default relay cleanup
- Nostr NIPs pull request 927: Places
- Nostr NIPs pull request 927 API metadata
- NIPs repository README and registry
- NIP-01: basic protocol and addressable events
- NIP-07: browser signer API
- NIP-09: event deletion requests
- NIP-19: bech32 encoded entities
- NIP-40: expiration timestamp
- NIP-52: calendar events and geohash tag context
- NIP-73: external content IDs
- NIP-CC: geocaching events and kind 37515 collision
- Yondar Place type source
- Cyberspace Meta-Protocol repository
- Cyberspace repository API metadata
