CraysOlas
Olas is the Nostr client for people who want the network to feel visual first: images, short videos, stories, hashtags, follows, zaps and mobile camera rolls, with enough protocol work underneath to keep the media portable instead of trapped inside a single social app.
A visual Nostr client
Olas is easiest to understand as a camera-roll-first Nostr client. The App Store description calls it a photo and video sharing social network based on Nostr, and that is a fair summary. It is not trying to replace every social client. It asks a more specific question: what happens when Nostr is treated as a network for images, short videos, stories, saved searches, hashtags and zaps rather than mostly as a text timeline?
The answer is a different rhythm. Olas organizes the home view around media events, grid views, reels, stories and visual profile surfaces. It still reads ordinary Nostr identity, follows, reactions, comments and zaps, but the app's center of gravity is visual. A reader is not meant to stare first at a wall of text. The app looks for the image or video attached to the social event and builds the experience around that media.
That makes Olas important even for people who never plan to use it as their main app. Nostr needs specialized clients that prove event portability is more than a slogan. A photo published through Olas should still be a Nostr event, not a locked post inside a private platform. A visual client like Olas tests whether Nostr can support an Instagram-like habit while keeping identity, posts and payments outside one company's database.
Mobile distribution and project identity
Olas is distributed like a normal mobile app. The Apple lookup record checked on June 12, 2026 lists `Olas` from seller `SANITY ISLAND LLC`, bundle ID `com.pablof7z.snapstr`, primary genre Social Networking, secondary genre Photo and Video, a free price, a March 11, 2025 release date, version 0.4.0, two ratings and a 3.0 average for the United States listing. That store record matters because users will usually meet Olas as an installed mobile app, not as a source repository.
The repository tells the next layer of the story. The GitHub project is `pablof7z/olas`, created in November 2024, MIT licensed according to GitHub metadata and Zapstore metadata, and built as a React Native and Expo application. The repository snapshot checked on June 12, 2026 showed 66 stars, 5 forks, 19 open issues and a default-branch commit dated May 26, 2025 that touched feed scrolling, image placeholders, wallet error handling, profile header animation, publish flow navigation and dependency updates. The app configuration lists the app name Olas, the Expo slug snapstr, the custom scheme `olas`, associated links for olas.app, the Android package and iOS bundle identifier, plus camera, media-library, notification, secure-store, video, SQLite and maps-related permissions.
The difference between store version and repository version should be kept in mind. The App Store listed 0.4.0, while the repository app.json listed 0.5.0. That does not mean one is wrong; it means readers should distinguish the released binary they install from the code currently present in the public repository. With a Nostr client, that distinction is not pedantic. Signing, media uploads, wallet behavior and storage can all change between a published mobile build and the newest source.
The feed is filtered around media
Olas does not simply subscribe to every kind-1 text note and hope the interface feels visual. The home screen code builds filters around image and video kinds, including NDK image and vertical-video event types, plus short-video and related video kinds. It also reads kind-1 text notes and reposts when they carry the media clues Olas cares about, such as a `k` tag pointing at image or video kinds, imeta tags or visible image and video URLs.
That choice is a practical compromise. Nostr's media history is messy. Some clients publish dedicated image events. Some publish videos with specific video event kinds. Some attach media URLs to plain text notes. Some add imeta metadata. A strict client that only accepts one format would miss too much. Olas instead builds a media-first view while still giving older and more compatible publishing habits a way to appear.
The for-you filtering logic shows the social product thinking. Olas avoids repeating too many posts from the same unfollowed pubkey in a short window, filters text notes that do not actually carry media, and can restrict video from non-followed accounts. That is not a global algorithm with a corporate ranking promise. It is a client-side attempt to keep a visual feed from becoming spammy, repetitive or off-topic.
Publishing creates portable media events
The publishing code is one of the strongest reasons to take Olas seriously. When a user publishes media to the media-app audience, Olas creates NDK image or video events. It attaches imeta metadata for each media item, including the uploaded URL, thumbnail image where available, SHA-256 hash, original hash when the uploaded hash differs, dimensions, MIME type, blurhash and file size. This is the difference between a mere image URL and a media event that another client can interpret well.
Olas can also publish a kind-1 text event for wider compatibility. In that mode, the post content includes the caption and media URLs, and the event gets imeta tags plus a `k` tag that points to the media kind. That is a useful escape hatch. A dedicated media event may be cleaner for visual clients, but a kind-1 note can be seen by older or more text-oriented clients that do not yet handle every media kind.
The app also signs events with alt text for media-specific events, adds expiration tags when the user sets a lifetime, adds hashtag tags, adds group tags when publishing into a group and can add geohash tags derived from location metadata. These are reader-facing details because they affect where a post appears, how it is searchable, how long it should be considered current and how another client might present it.
Media preparation is not an afterthought
Before upload, Olas runs a media preparation pipeline. The code determines the MIME type, compresses the file, removes EXIF metadata, generates a video thumbnail when needed, calculates blurhash previews, reads dimensions and computes SHA-256 hashes for the media and thumbnail. That is a serious mobile-media workflow. It acknowledges that a photo post is not just a path from camera roll to server.
The EXIF step deserves special attention. Photos can carry location and device metadata that many users do not mean to publish. Olas has a remove-location setting and a media preparation function that attempts to remove EXIF data while preserving location information for optional geohash tagging when the user chooses it. Readers should inspect those settings before posting personal photos, especially from home, work, schools or private locations.
The thumbnail, dimensions and blurhash work make the feed feel faster and more stable. Nostr clients cannot assume a centralized image CDN will do all rendering work for them. If the event carries useful metadata, other clients can reserve layout space, show a preview, render multi-image posts better and avoid expensive probing. Olas is doing the work that makes media portable and pleasant.
Blossom is the upload path
Olas uses Blossom-style uploads for media storage. The active Blossom server defaults to `https://blossom.primal.net` unless the user's Nostr Blossom server list provides another server. Uploads use a Nostr authorization event, encoded into the HTTP Authorization header, to prove the user authorized the upload for a specific file hash. The upload code sends the media file to the server's `/upload` endpoint and records the returned blob descriptor.
That matters because media storage and Nostr events are separate systems. The signed Nostr event says what was posted and by whom. The Blossom server stores the bytes. The imeta tags connect those pieces with URLs, hashes and file information. This is much healthier than pretending the relay stores the photo itself, but it creates a new trust boundary around media hosts.
A reader should check which Blossom server Olas is using before posting important media. A server may have retention rules, size limits, moderation policy, outage risk or deletion behavior. The signed Nostr event may remain available long after the actual image disappears from a storage host. Olas gives the app a good upload model; it cannot make every media server permanent.
Reels, stories and short-lived media
Olas includes a reels screen that subscribes to short-video and video kinds, sorts recent events, ensures one event per pubkey in the current list and plays the visible video while pausing the rest. The implementation uses Expo Video, thumbnails and a full-screen feed pattern familiar from short-video apps. Again, the interesting part is not that Olas can play video. It is that it tries to do this with Nostr events rather than a private video graph.
Stories add another layer. The story code looks for story events, portrait video or image events in a recent timeframe, live events, expiration tags and imeta data. The story editor can upload story media through Blossom, generate imeta metadata, create NDK story events, set expiration tags and attach stickers. That puts Olas closer to the mobile social habits people already know: temporary visual updates, full-screen media and lightweight decoration.
Temporary media is still hard on Nostr. An expiration tag expresses intent; it does not force every relay and every client to erase the event. A story may feel temporary inside Olas while still being a signed public event that other infrastructure can copy or ignore differently. Readers should treat expiring posts as softer than platform deletion and avoid publishing sensitive media just because a story interface looks ephemeral.
Signer choices are broad for a mobile app
Olas supports several signing paths. The onboarding screen can create a new private-key signer, accept an nsec, accept a `bunker://` remote signer through NIP-46 and use Android NIP-55 signer apps when available. The app also warns in the signup flow when the user appears to be typing an nsec into the username field, which is a small but valuable safety guard.
The NIP-55 permission list is especially revealing. Olas asks signer apps for event-signing permissions covering image events, short-video events, Cashu wallet events, Cashu wallet backup and transaction events, Cashu mint lists, Nutzaps, replies, reactions, reposts and deletion requests, plus NIP-44 encryption and decryption. This is a wide permission set because Olas is not only a feed reader. It publishes media, signs social actions and interacts with wallet-related events.
For important identities, readers should prefer a signer path that they understand. A generated key inside the app may be convenient for a new account. A pasted nsec is direct but sensitive. A NIP-46 bunker keeps the long-term key elsewhere but introduces session and relay considerations. An Android NIP-55 signer can be a better mobile boundary when the signer app shows clear approvals. The right choice depends on how much value the identity controls.
Local storage keeps the app usable
Olas uses both SecureStore and SQLite. SecureStore holds settings such as feed choices, privacy toggles, advanced mode, default zap settings and other small pieces of local state. SQLite backs the app database, including unpublished events, NIP-60 wallet proofs, blacklisted words, saved searches, relays, NWC zap records, private follows, mint information, mint keys, payments, pubkey flares and image cache state.
The NDK initialization uses an SQLite cache adapter named `olas`, initializes it and then constructs an NDK instance with explicit relay URLs, relay blacklists, the outbox model enabled, a client name and a NIP-89 client coordinate. If no stored relay set exists, Olas adds defaults including `wss://relay.olas.app/`, `wss://purplepag.es/` and `wss://relay.primal.net/`. That gives the app a working network starting point while keeping relay state editable.
This local layer matters for mobile reliability. A phone app needs to remember which relays to connect to, which uploads are pending, what the wallet state is, which searches the user saved and which images are cached. Nostr can make posts portable, but a good mobile app still needs boring local state. Olas has enough of that state that users should also know how to reset, unlink wallets and recover if a local database becomes stale.
Zaps are woven into the media experience
Olas treats zaps as part of social interaction. The reactions and payment stores track zap receipts, Nutzaps, pending payments and zap counts by the current user. The zap hook builds an NDKZapper, adds pending payment state, supports delayed zaps that can be canceled, records NWC invoices for later matching and can use Nutzaps as a fallback when the active wallet is a Cashu wallet.
The settings include one-tap zap defaults and a YOLO zap mode where the user can zap by swiping a lightning icon, with a configurable growth factor. That is a very mobile-social interpretation of Lightning payments: less invoice ceremony, more immediate reaction. It also increases the importance of spending limits and clear wallet state. A fun zap gesture should never be confused with unlimited wallet authority.
Readers should test zaps slowly. Connect a small wallet, set a tiny default amount, send a test zap and verify the payment in the wallet history. If using NWC, check that the connected wallet's permissions and budgets match the gesture-heavy interface. If using a Cashu wallet or Nutzaps, understand the mint and token state before holding meaningful value inside the app.
Olas includes wallet surfaces, but it is not mainly a wallet
Olas has more wallet code than many social clients. It can create a NIP-60 Cashu wallet, defaulting to mints such as Coinos and Minibits, publish the wallet event, back it up, publish a Cashu mint list and start wallet monitoring. It can also connect external wallets through NWC, including deep-link flows for wallet apps such as Primal or Alby when supported on the device.
The wallet screen can display a balance, transaction history, NWC wallet information, send and receive flows, Lightning and ecash receive options, QR scanning and wallet settings for mints, relays, tokens and Nutzaps. The wallet monitor keeps known proofs from a NIP-60 wallet in the local database and migrates old wallet events where needed. That is real wallet functionality, not just a zap button.
Still, Olas should be approached as a media app with wallet features. Its main promise is visual social publishing, not long-term custody. A dedicated wallet may give clearer backup, budget, recovery and audit behavior. Olas can make zaps and ecash-native social payments feel integrated, but readers should keep meaningful balances in tools whose primary job is wallet safety.
Search, hashtags and the 365 habit
Olas leans into hashtag discovery. The app ships predefined saved searches such as `#olas365`, `#photography`, `#family`, `#food`, `#nature`, `#music`, `#art`, `#travel` and `#memes`. Text search uses NIP-50-style search through `wss://relay.nostr.band`, while hashtag searches subscribe to image and vertical-video events tagged with the relevant topic.
The `#olas365` surface is particularly revealing. It treats posting as a daily visual practice, showing media by day and encouraging a long-running photo challenge pattern. This is the kind of social habit that makes a specialized client matter. A generic feed can display a hashtag. A visual app can make the hashtag feel like a gallery, challenge and memory record.
Search remains relay-dependent. If a saved search is thin, it may be because the topic is quiet, because relevant posts are on other relays or because media metadata is inconsistent. Olas helps by using image and video event kinds and media-bearing text notes, but it cannot discover what no relay returns. Readers should treat search results as a view through selected relays, not as a complete catalog of Nostr.
Profiles and bookmarks stay close to the visual model
Profile views in Olas subscribe to a user's image, video and short-video events, not merely to all text notes. That makes profiles feel like visual portfolios. The profile components include banner, name, about text, tab behavior, stories and profile editing hooks. For photographers, artists, travelers, families and creators who post mostly media, this shape is more natural than a generic chronological text list.
Bookmarks use image curation sets and related list behavior, including kind 3006 filters tagged for image kind 20. That matters because a visual bookmark feed should remember media posts as media posts, not just as generic event IDs. Olas can build a personal saved gallery out of signed Nostr list events when the underlying client and relays support the relevant list behavior.
The portability story is promising but not perfect. A profile's media posts, follows, curation sets and reactions may be legible across clients that understand the same event kinds. Some apps will show only a fallback note. Some will ignore story or media metadata. This is the current state of Nostr media: powerful when clients agree, uneven when they do not.
Testing tells you where the product is headed
Olas includes a substantial Maestro end-to-end test setup. The test flows cover app launch, navigation, search, profile views, wallet behavior, transactions, image upload, new stories, sticker behavior, mention stickers, text overlays, preview behavior, header scroll behavior and profile deep links. That is not normal for a throwaway prototype. It shows a mobile app that is trying to stabilize real user workflows.
The tests also reveal the important surfaces. Olas cares about getting from launch to feed, from search to profile, from profile link to profile screen, from camera roll to preview, from story editor to published story, from wallet to transaction and from scrolling to a stable animated header. These are practical mobile details. They shape whether a visual social client feels alive or brittle.
Readers should not confuse tests with guarantees. A test suite can pass and a relay can still be down, a wallet can still fail, an upload host can still reject a file or a signer can still be confusing. But tests are a useful signal. They show which behaviors the maintainers consider important enough to automate and watch.
Risks to understand before posting
The first risk is media persistence. A photo uploaded through Blossom and referenced by a Nostr event may be copied, mirrored, cached, screenshotted or kept by relays and clients. Expiration tags and story interfaces express intent, but they do not create platform-style deletion across the whole network. Do not post sensitive images because the interface feels casual.
The second risk is location. Olas has remove-location behavior and geohash tagging logic, but users should still check settings and test with harmless media. Phone photos can carry more context than the picture itself suggests. If you want to post from private places, make sure location metadata is removed and avoid captions or tags that reveal what the image metadata no longer does.
The third risk is money. Olas can connect NWC wallets, create NIP-60 Cashu wallets and use Nutzaps. That is exciting for media creators, but it increases the app's responsibility. Keep wallet balances small, use mints and wallet apps you understand, set conservative zap defaults and verify receipts. A visual client can make payments delightful; it should not make payment risk invisible.
Who Olas is best for
Olas is best for Nostr users who want to post and browse visual work without treating every photo as a text-note attachment. Photographers, families, artists, travelers, meme posters and people following visual challenges such as `#olas365` will understand the appeal immediately. It makes Nostr feel less like a feed of protocol objects and more like a mobile gallery.
It is also useful for builders studying media on Nostr. The code shows how to combine Expo, React Native, NDK, SQLite, SecureStore, camera permissions, media-library access, image preparation, Blossom upload authorization, image and video events, imeta, stories, relays, NIP-55, NIP-46, NWC, NIP-60 and Nutzaps inside one app. That is a rare amount of practical surface in one public mobile codebase.
Olas is less ideal if you want a text-first client, a conservative wallet, a desktop-first workflow or a finished-feeling social platform that hides all protocol roughness. Its value is more specific and more interesting: it is a serious attempt to make visual Nostr social life feel natural on a phone while keeping enough protocol structure for the photos, videos, zaps and identities to remain portable.
Sources worth opening
The best reading path starts with the live Olas site, App Store record, NostrApps listing and public GitHub repository, then follows the app configuration, NDK initialization, publish code, media preparation, Blossom upload code, signer onboarding, wallet code, zaps, SQLite migrations, stories, reels and the relevant Nostr and wallet specifications.
- Olas official site
- Olas App Store listing
- Apple iTunes lookup record for Olas
- Olas GitHub repository
- Olas May 26, 2025 feed, image loading and wallet handling commit
- Olas README
- Olas app configuration
- Olas package file
- Olas Zapstore manifest
- Olas maintainers file
- Olas NDK initialization
- Olas app layout
- Olas home feed
- Olas feed component
- Olas media renderer
- Olas publish event builder
- Olas publish upload action
- Olas post media types
- Olas media preparation
- Olas uploader source
- Olas Blossom helpers
- Olas Blossom client
- Olas active Blossom server hook
- Olas login screen
- Olas login input
- Olas signup screen
- Olas app settings store
- Olas SQLite migrations
- Olas wallet hook
- Olas wallet utility
- Olas wallet settings screen
- Olas NWC settings screen
- Olas NWC deeplink screen
- Olas zap hook
- Olas payment store
- Olas NWC zap database
- Olas zaps settings
- Olas reels screen
- Olas stories hook
- Olas story event builder
- Olas story upload action
- Olas send screen
- Olas receive screen
- Olas Maestro test README
- NostrApps listing for Olas
- No Bullshit Bitcoin Olas v0.1.4 note
- Nostr NIPs repository
- NIP-55 Android signer application
- NIP-57 Lightning zaps
- NIP-60 Cashu wallet
- NIP-61 Nutzaps
- NIP-65 relay list metadata
- NIP-92 media attachments
- NIP-94 file metadata
- Blossom specification repository
- NDK repository
- Cashu protocol
- Maestro mobile testing
