CraysWherostr
Wherostr is the Nostr client to open when the question is not only who posted, but where the note belongs. It turns geohash tags, map filters, mobile location, zaps and live activity metadata into a small location-aware social surface.
A social feed with a map in the middle
Wherostr answers a different question from the usual Nostr client. A normal timeline asks what your relays have seen from the people you follow, the tags you search or the event ids you open. Wherostr asks where those notes belong. It keeps the familiar social pieces: profiles, text notes, reposts, quotes, comments, likes, zaps, follows, mutes and note menus. Then it adds a map, geohash filters and location-aware posting.
That shift changes how the product should be judged. Wherostr is not trying to compete with the most polished full-feed clients on every social feature. It is closer to a local discovery experiment: a way to find Nostr posts near a place, attach a place to a note, jump from a note to the map, search by tag or location and treat geography as part of conversation. The app manifest uses a simple description: Where are Nostr people?
The public repository supports that reading. The app uses Next.js, MapLibre GL, NDK, a browser Dexie cache, geohash encoding and mobile PWA packaging. The interface is built around a main pane and a fixed map. On desktop, the panel and map can sit beside each other. On mobile, the query state decides when the map takes over the screen. Wherostr is small, but it is specific.
How location enters a Nostr note
The key mechanism is the `g` tag. When an author enables the location option while composing, Wherostr can get GPS coordinates or let the author choose from the map. It encodes the latitude and longitude as a geohash, stores that value in a hidden field and then writes a sequence of `g` tags onto the event, from more precise to less precise prefixes. That lets the app filter by a place without needing a separate database of private coordinates.
The note itself can remain an ordinary text event. Wherostr uses text notes for create, quote and comment actions, repost events for reposts and regular event tags for replies or mentions. Location is metadata attached to the note, not an entirely separate posting system. If the author chooses to append a map link, the content can also include a Wherostr URL, a DuckDuckGo Maps URL and a Google Maps URL for the selected coordinates.
This makes Wherostr interoperable in the ordinary Nostr sense: other clients can still see the note as a note. The map part is richer in clients that know what to do with `g` tags. The downside is that location metadata is not hidden. A geohash can be decoded. Even if it is only approximate, it can become sensitive when combined with timestamps, photos, profile identity and repeated posting habits.
The map is a filter, not only decoration
The map does real work. Wherostr's main pane reads the query string, extracts tag filters, geohash filters or bounding-box filters and subscribes to text and repost events that match those filters. For a geohash query, the app decodes the geohash into a map area. For a bounding box, it converts the box into geohash prefixes. It then merges ordinary tag or following filters with location filters and plots events that carry suitable `g` tags.
On the visual side, Wherostr uses MapLibre with a dark MapTiler street style. When matching events arrive, the app turns the best available geohash on each event into a GeoJSON point, adds those points to a map source and displays them with a pin symbol. Clicking a pin opens the event. Clicking the travel/map action on a note can also move the map to that note's coordinates.
That model is easy to misunderstand. Wherostr is not proving that the author was physically at the place. It is reading tags the author or client attached. A post can be honest, approximate, stale or deliberately misleading. The value is social context, not location attestation. Readers should treat the map as a browsing layer over public Nostr events.
The search language is small but useful
Wherostr's search box points readers toward hashtags and places. Internally, the query parser recognizes `t:` for tags, `p:` for a public key, `g:` for a geohash and `b:` for two geohashes that form a bounding area. Those pieces let the app switch between a global feed, a followed-person feed, tag discovery and location discovery without inventing a heavy search engine.
The location search is especially important on mobile. A reader can search a place-shaped query, jump to the map and use the map as the navigation surface. The app also supports hash-based links: a URL fragment that looks like a geohash can redirect into the map query, while Nostr bech32 values can redirect toward note, event, profile or address pages. That makes Wherostr a small URL router for Nostr and place references.
The limitation is reach. A place search only finds events on the relays Wherostr is using and only when those events carry location tags. If a city looks quiet, it may mean nobody posted there, the relevant events are on other relays, the posts used different geohash precision or the local community simply does not use Wherostr-style tagging. Empty map space is not proof that Nostr has no people there.
Signing choices are blunt
Wherostr supports three account modes: NIP-07 browser signing, nsec private-key entry and read-only npub. The NIP-07 path uses an external browser signer, which is the safer default for a web app because the private key stays with the signer. The npub path lets a reader inspect profiles and feeds without signing. The nsec path creates a private-key signer inside the app and stores session data in localStorage.
That last detail deserves attention. The code stores the session object locally, and for an nsec login it includes the nsec value. That makes direct nsec entry a high-risk convenience. It may be useful for a test identity, but it is not the posture most readers should use for their main Nostr key. A malicious browser extension, compromised device, shared computer or future app bug could make that storage decision expensive.
Use Wherostr with a signer if you can. If you only want to explore the map, use a read-only npub. If you must test nsec login, use a throwaway key. The app's location layer is interesting enough on its own; it does not need your most valuable identity until you trust the environment.
Relays and cache shape what the map can see
Wherostr's Nostr context builds an NDK instance with a Dexie cache named `wherostr-cache`. It can use relays from the environment, then update the relay set from a user's relay list when a profile is available. If a user's relay list has relay URLs, Wherostr can switch to those. Otherwise it falls back to the configured defaults. Live streams use a separate relay set drawn from nostr.wine, nos.lol, relay.damus.io and relay.snort.social.
This matters because a map is only as good as the events it can read. Nostr does not have a single global query endpoint. Wherostr subscribes to relays, receives events, deduplicates them and keeps a cache in the browser. The app can fetch older items, show new items after end-of-stored-events and merge location results with tag or following filters, but it still depends on relay coverage.
The local cache is useful for speed and offline-ish continuity, but it also means the browser can hold a local record of public events, profiles and activity Wherostr has fetched. That is not the same as private key storage, but it is still local data. On shared devices, clear site data when you are done. When debugging stale map results, remember that relays and cache can both be involved.
Profiles, follows and mutes are ordinary Nostr behavior
Wherostr does not reduce people to map pins. It fetches user profiles, validates NIP-05 names when present, shows profile images, banners, website links, about text and Lightning addresses, and lets signed-in users follow, unfollow or mute accounts. It reads contact-list events, publishes updated contact-list events and fetches mute-list events for the signed-in user.
That is important because location discovery without social controls would become noisy quickly. A public map can attract spam, repeated promotional posts and low-quality coordinates. Follow and mute controls give the reader some agency. Wherostr also filters muted authors out of note-related views and live lists, so the mute list is not only decorative.
The product still depends on Nostr norms. A profile can lie. A NIP-05 name can disappear. A relay may serve old metadata. A user can post an inaccurate place. Wherostr gives you the normal Nostr identity tools, then overlays place. It does not solve trust by showing a map.
Posting supports media, proof of work and public links
The composer has more going on than a text box. It can accept image, video and audio files through a dropzone and uploads them to nostr.build's v2 file upload endpoint. It can paste uploaded URLs into the note body. It can toggle location. It can add proof-of-work by using a browser worker and a difficulty value. It can add map links to the note body when a geohash is present.
The proof-of-work toggle is a small nod to NIP-13 style spam resistance. It does not make a note trustworthy, but it can make spam more expensive and let other clients display or filter by difficulty if they care. Wherostr also displays proof-of-work difficulty on notes when it sees a nonce tag.
The media path is more sensitive. Uploading to a file service is not the same as attaching a private local file. A media URL can be copied, mirrored and viewed by other clients. If the media itself contains location clues, and the note also carries a geohash, the privacy loss compounds. Before posting from a real place, test with harmless media and approximate location values.
Zaps use WebLN first
Wherostr includes zap actions on notes. The action bar fetches related zap receipt events, totals the zap amount and disables the zap button when the author profile lacks a Lightning address or LNURL field. The zap form asks for an amount and optional comment, calls the event's zap helper and then sends the invoice through a WebLN provider.
That means the immediate zap flow is browser-wallet shaped. A user needs a WebLN-capable wallet or extension available in the browser. The app also includes a wallet settings page with Alby's Bitcoin Connect component and a Nostr Wallet Connect heading, but the checked zap implementation itself uses WebLN's requestProvider and sendPayment path. Readers should not assume a complete wallet manager simply because NWC appears in the settings.
A practical setup is modest: connect a wallet with a tiny budget, zap a known profile, confirm the invoice in the wallet and inspect whether the recipient's profile has the right Lightning metadata. Zaps are useful in a location client because they can reward local reports, meetup notes or event updates. They are still real payments.
Live activities are a second, smaller product surface
Wherostr also contains a live section. It subscribes to kind 30311 live activity events, looks for live or ended status tags, streaming URLs, recording URLs, image tags, starts and ends timestamps, current participant counts and host pubkeys. It displays live and ended streams in a grid, and individual stream cards link to addressable Nostr events.
The stream creation form can publish kind 30311 events with a d tag, start and end timestamps, streaming and recording URLs, status, title, summary, image, current participant count, p host tag and topic tags. The stream URL validator expects HLS-style `.m3u8` streams, and the ended-recording path uses ReactPlayer's capability checks. The app also embeds zap.stream chat and can publish kind 1311 chat messages tied to the live activity address.
This is not the same as Wherostr hosting the video stream. It is publishing and reading live activity metadata, then pointing at stream URLs and chat surfaces. That distinction matters. The video infrastructure, chat iframe and Nostr relays are separate pieces. Wherostr makes them visible in one interface, but it does not make them one trust domain.
The mobile packaging is real
Wherostr is available as a PWA-shaped web app and has store listings on Apple's App Store and Google Play. The repository includes a large manifest with Windows and iOS icon sets, standalone display mode, dark background color and mobile startup assets. The Next.js config uses static export, unoptimized images and next-pwa registration in production.
The Apple listing identifies Wherostr from MAPBOSS COMPANY LIMITED and shows version 1.3.3 in the checked listing. The Google Play listing describes it as a decentralized social network and showed an update date of December 29, 2024 during research. Those store pages are useful signals because Wherostr is not only a developer demo in a GitHub repo; it has been packaged for ordinary mobile install paths.
Store presence does not remove the need for caution. Mobile location prompts can feel routine. A user may approve GPS because the app is map-based and then forget that the resulting event is public Nostr data. The mobile version can make the experience more natural, but that is exactly why location discipline matters more.
Maintenance signals are mixed
The repository checked for this article had its latest commit on November 5, 2023, with a relay-connection fix. The mobile store listings are newer, and the Google Play page showed a late-2024 update date. That creates a mixed picture: the public code is inspectable and specific, but the repository does not show the same recent development cadence as some larger Nostr clients.
The dependency stack also reflects its era. It uses Next.js 13.4, React 18, MUI 5, NDK 2.0.5, @snort/system, MapLibre 3, next-pwa, nostr-tools and WebLN. None of that makes the app unusable. It does mean readers should test current signer behavior, mobile store behavior, map loading, relay connection, wallet prompts and live activity rendering before relying on Wherostr for a meetup, event or local information flow.
Small Nostr apps can be valuable even when they are not constantly changing. Wherostr's idea is still useful: notes can have place, and place can become a discovery surface. The maintenance question is whether the current implementation remains stable enough for the reader's use case.
What to test before using it seriously
Start in read-only mode. Open a public profile, search a tag, search a geohash if you know one and compare the results with another Nostr client. Then sign in with a NIP-07 signer and publish a harmless note without location. Confirm it appears on your normal relays and that another client can read it.
Next, test location with approximate data. Choose a public place, not your home, and post a note with location enabled. Inspect the raw event if you can. Look for the `g` tags, note content and any map links. Then open the note from Wherostr and another client. This shows you what Wherostr adds and what other clients will still see.
Finally, test the risky edges separately: upload a harmless file, zap a tiny amount through WebLN, try the map view on mobile, clear site data and sign back in. If you plan to use live activities, publish a private test stream metadata event or inspect an existing one first. Wherostr combines several public surfaces, so small tests are better than surprises.
Who Wherostr is best for
Wherostr is best for people who want Nostr to notice place: meetups, local communities, travel notes, field reports, event discovery, city tags, outdoor updates and social browsing that starts with a map instead of a timeline. It is also useful for builders who want to see a practical implementation of geohash tagging, MapLibre rendering and NDK subscriptions in a real Nostr app.
It is less appropriate for private location sharing. Nostr events are public by default, and Wherostr's location feature is built around public tags. If the post should not be tied to a place, do not attach a place. If the place should be rough, use a rough location. If the account should stay separate from your movements, use a separate identity.
The app's value is in its restraint. It does not try to be every Nostr client. It takes the ordinary social pieces and asks what changes when location is first-class. That makes Wherostr worth listing, worth testing and worth approaching with the privacy discipline that map-based social software always deserves.
Sources worth opening
Start with the live app, mobile store pages and repository, then read the code paths for signing, map filters, geohash tagging, posting, zaps, media upload, live activities and wallet connection.
- Wherostr live site
- Wherostr web manifest
- Wherostr App Store listing
- Wherostr Google Play listing
- Wherostr GitHub repository
- Wherostr package file
- Wherostr Next.js configuration
- Wherostr root layout
- Wherostr main page
- Wherostr app constants
- Wherostr Nostr context
- Wherostr account context
- Wherostr app context
- Wherostr map context
- Wherostr map view
- Wherostr main pane
- Wherostr create event form
- Wherostr posting options
- Wherostr filter parser
- Wherostr location extractor
- Wherostr upload helper
- Wherostr event action modal
- Wherostr note action bar
- Wherostr note menu
- Wherostr text note renderer
- Wherostr profile card
- Wherostr subscription hook
- Wherostr Nostr hooks
- Wherostr wallet settings page
- Wherostr live page
- Wherostr stream button
- Wherostr live chat component
- MapLibre GL JS
- Nostr Development Kit
- NDK Dexie cache adapter
- Nostr.build file hosting
- Alby Bitcoin Connect
- WebLN guide
- NIP-07 browser signer capability
- NIP-10 text note threading
- NIP-13 proof of work
- NIP-25 reactions
- NIP-53 live activities
- NIP-57 Lightning zaps
- NIP-65 relay list metadata
- NIP-94 file metadata
