CraysSlidestr
Slidestr is what happens when someone reads Nostr as a public media stream instead of a text timeline: notes, picture events, file metadata, reposts, reactions, zaps, follows and relay choices are collapsed into one fast visual browser.
A media lens, not a media silo
Slidestr's best idea is simple: Nostr already contains images and videos, but most clients still make you experience that media as a text feed with attachments. Slidestr turns the model around. The image or video becomes the first object you see. The note, author, tags, reactions and payment affordances become supporting context around the visual thing.
That sounds cosmetic until you open the app. The live site is a black, fullscreen Progressive Web App. Its manifest names `slidestr.net`, uses a black theme and background, sets `display` to `fullscreen`, and starts at `/`. The front page does not behave like a magazine landing page. It redirects into a route made from default hashtags: `artstr`, `catstr`, `coffeechain`, `dogstr`, `flowerstr`, `foodstr`, `gardenstr`, `grownostr`, `nostr`, `photography`, `photostr`, `picstr`, `plebchain`, `travelstr` and `zapathon`. That first route tells you the product's worldview. It is not trying to replace every Nostr client. It is trying to make public tagged media feel like a gallery.
The interface has a few visible pieces: a close/back control, a login control, a page title such as "Mixed hashtags," a masonry image grid, video thumbnails, a bottom control area and a play button whose browser title reads `play slideshow (G)`. In a local browser check of the live app, the page loaded dozens of media elements after connecting to relays. Some were regular images, some were videos, and many thumbnails came through `images.slidestr.net` as webp-resized proxy URLs.
That is the correct way to read Slidestr. It is not a new storage protocol. It is a Nostr media reader with opinions. It asks relays for events, chooses which event kinds are visually relevant, extracts URLs, hides things it considers unsafe or unwanted, and gives the user a picture-first path through a public social graph.
The default room is a hashtag wall
The default feed is not random. The source repository exposes `defaultHashTags`, and the live app currently uses the same cluster of public tags that the homepage redirects to. Those tags cover art, pets, food, gardening, Nostr culture, Bitcoin culture, photography and travel. Slidestr therefore begins with the most legible kind of open-network browsing: not "follow everyone," not "algorithmic discovery," but "show me visual public notes matching these hashtags."
The production bundle makes the query shape even clearer. The filter builder starts with `kinds:[1,20,1063]` and a limit of 300. Kind 1 is the ordinary short text note. Kind 20 is the NIP-68 picture event. Kind 1063 is the NIP-94 file metadata event. Reposts can be included by adding kind 6. When a tag route is active, the filter uses a `#t` tag query. When a follows or list route is active, it can query authors instead. When there are no specific authors or tags, it falls back to a recent time window.
That is a compact design decision with big consequences. Slidestr does not require every photographer to publish a perfect picture event before they appear. A normal kind 1 note with an image URL can work. A NIP-68 picture event with `imeta` URL data can work. A NIP-94 file metadata event with a `url` tag can work. The result is messier than a closed photo app, but it is also more realistic. Nostr media is already scattered across note bodies, tags, file events, picture events and ordinary web URLs.
The visible route model is useful too. The open source `App.tsx` defines paths for `/tags/:tags`, `/topic/:topic`, `/profile/:npub`, `/p/:npub`, `/follows`, `/list/:list`, `/global` and raw `/:npub` style profile browsing. That tells you Slidestr was built as more than one public homepage. It is a routeable visual reader for tags, profiles, follows, lists and broader feeds.
The code path is visible
Slidestr has an actual source trail. The app's self-hosted Gitea repository lives under `florian/slidestr` on `git.v0l.io`. The default branch visible during this check was `spike/reduced-view`. The repository title is `slidestr`, while `package.json` still calls the package `nostr-slideshow`, marks it `private: true`, and uses a Vite, React and TypeScript stack. Key dependencies include `@nostr-dev-kit/ndk`, `@nostr-dev-kit/ndk-cache-dexie`, `nostr-tools`, React Query, Jotai, Lodash, React Router and React Swipeable.
The repository history matters because it anchors the product in real engineering work instead of directory folklore. Gitea showed a visible latest commit `chore: latest version` by florian on November 17, 2025. Older file history includes the initial commit in July 2023, experimental zaps in August 2023, experimental masonry view, follow button and lists in February 2024, moved global and NSFW section in March 2024, a new search menu in October 2024 and a memes category in July 2024. The root did not expose a simple `LICENSE` file in this check, so the safest statement is not "open-source under X." It is "source is visible, but license must be checked before reuse."
The source tree is also revealing. Components include `Home`, `Login`, `MasonryView`, `SlideView`, `ScrollView`, `Settings`, `TagEditor`, `AdultContentInfo`, `FollowButton`, `InfoPanel`, `AuthorProfile` and icons for play, fullscreen, heart, bolt, repost and bookmark. The application provider initializes NDK with explicit relay URLs, `purplepag.es` as an outbox relay, outbox model enabled and a Dexie cache named `slidestr2`. This is not a static gallery. It is a Nostr client with relay discovery, local cache, signer state, profile state and actions around the active image.
The production bundle is newer than some of the readable source paths and should be treated as the current behavior source for the live site. It includes `window.nostr`, `getPublicKey`, `signEvent`, Nostr Connect bunker URI handling, a default NIP-46 relay fallback at `wss://relay.nsecbunker.com`, image proxy logic for `https://images.slidestr.net`, URL normalization from `nostr.build` to `cdn.nostr.build`, and the same event-kind strategy around kind 1, kind 20 and kind 1063. That combination is enough to say the app is not just rendering a public feed. It can become an authenticated Nostr session when the user logs in.
Where the files actually live
This is the part most casual users miss. Nostr relays carry signed events. They do not usually carry the expensive media bytes. Slidestr can show an image because some event points to a URL. That URL may be on `image.nostr.build`, `v.nostr.build`, `blossom.primal.net`, `cdn.nostrcheck.me`, Pexels, Twitter/X media, another web host, or a Blossom-style server. In the live browser check, sampled media came from several of those places. Slidestr made them feel like one gallery, but the underlying files were not living in one place.
The app has to normalize that chaos. Its media extraction path strips URLs and hashtags out of display text, collects `https://` URLs, rewrites a few known patterns, ignores Wikimedia wiki pages, detects image extensions such as jpg, png, gif, jpeg and webp, and detects video extensions such as mp4 and webm. For NIP-94 file events, it pulls the `url` tag into the content path. For NIP-68 picture events, it reads `imeta` tags and extracts entries that begin with `url `. That is practical glue, not magic.
The proxy is another real boundary. The production bundle defines `https://images.slidestr.net` as the image proxy. The source `env.ts` shows the same default, with `VITE_IMAGE_PROXY` as an override. The generated thumbnail URL pattern includes resizing and webp output. This makes the app faster and more consistent, especially on a dense masonry grid, but it also means a user is often fetching media through Slidestr-operated infrastructure. The event may be portable. The thumbnail experience is partly operated.
That does not make Slidestr bad. It makes it honest to inspect. Visual clients need thumbnails, caching, resizing, bandwidth control, content warnings and broken-image handling. A client that pretends all media is just a note is lying by omission. Slidestr shows the hard parts because it has to solve them in front of your eyes.
Signing changes the surface
Slidestr can be used passively, but login turns it into a more personal client. The source and bundle show NIP-07 style browser signer access through `window.nostr`, with public key lookup and event signing. The production bundle also contains a Nostr Connect path. It can build a `bunker://` URI, open an authentication window, connect through NIP-46 and persist the bunker account locally. If a profile has NIP-46 relay metadata, it can use that. If not, the bundle falls back to `wss://relay.nsecbunker.com`.
Once a session exists, Slidestr's controls become more meaningful. The source includes bookmark, repost, heart and zap buttons around the active image. Reposts map to NIP-18 style kind 6 behavior. Likes map to NIP-25 reactions. Zaps sit in the NIP-57 Lightning zap world and depend on the viewed author's Lightning metadata such as `lud06` or `lud16`. This is important because a picture wall becomes a social surface: you are not only watching images, you may be signing public reactions to them.
Follows and lists also change the feed. Source routes include `/follows` and `/list/:list`, and the filter logic can build author lists from a contact list or list source. NIP-65 relay metadata matters in the background because Nostr clients need sane relay hints to find a user's events. The visible default relays in source include `wss://relay.damus.io`, `wss://relay.nostr.band`, `wss://relay.snort.social`, `wss://nos.lol`, `wss://nostr.wine`, `wss://relay.primal.net`, `wss://relay.mostr.pub` and `wss://purplepag.es/` for profile/outbox discovery. The production bundle also references Primal, Damus, Nostr.Band, nos.lol, Mostr and other relay endpoints.
The lesson for the user is plain: logging in makes the feed better, but it also makes the actions yours. A public heart, repost, bookmark list entry or zap should be treated as a signed event attached to your key. Use a signer you trust. Read signer prompts. Be especially careful with remote signing because the convenience comes from another Nostr-specific trust path.
The operator trail
The operator trail is thin but checkable. The `.well-known/nostr.json` file at `slidestr.net` maps `_` and `florian` to the pubkey `b7c6f6915cfa9a62fff6a1f02604de88c23c6c6c6d1b8f62c7cc10749f307e81`. It also maps `jinn` to a different pubkey. The public Nostr profile for florian, visible through Nostr gateways, says he is building `nostu.be` and `slidestr.net`, uses `florian@slidestr.net` as NIP-05, points his website to `https://slidestr.net`, and publishes an LNURL address at `npub.cash`. Damus also shows relay hints for that profile, including Slidestr and Nostu relay endpoints.
The Gitea source repository is under the same `florian` account. That does not prove a company, a formal team, a legal entity or a guaranteed support contract. It does prove a strong public builder trail: domain NIP-05, public profile, source repository, visible commits and a live site. That is enough to write about the app without inventing a corporate story around it.
External catalogs place Slidestr in the visual-client corner of the Nostr ecosystem. NostrApps lists the web platform and calls out compact media browsing, images and videos, and fullscreen media. Nostr Compass tracks it as a web project for browsing images and videos on Nostr. A community client index compares it loosely to DeviantArt and links an older `nostr-slideshow` source URL that now 404s, while the live Gitea repository is at `florian/slidestr`. That mismatch is useful history: small Nostr projects move, rename branches and leave old directory entries behind. Always verify the live route and source route yourself.
What can go wrong
Slidestr's largest risk is not a single dramatic bug. It is the ordinary fragility of open media. A Nostr event can survive while the image URL dies. A file can be reachable from one host but slow from another network. A video can play on desktop but fail on a phone. A proxy can make thumbnails fast until the proxy is down. A relay can miss the event that another relay has. A public tag can be full of good photography in the morning and spam by dinner.
Content filtering is another boundary. Slidestr includes a long adult-content tag list, explicit adult and mixed-adult public-key lists, a blocked public-key list, a blocked `loli` hashtag and logic for `content-warning` tags. That is more serious than many small visual clients, and it is good that the logic exists. But it is still heuristic. Public Nostr media is not pre-moderated by a central platform. Tag-based filters depend on authors tagging honestly, clients writing tags correctly and relay data arriving as expected.
There is also the privacy shape of media browsing. A passive visit can still reveal IP address and user agent to the website, media hosts and proxy endpoints. A logged-in visit can reveal your public key and your actions. If you follow your own graph, the app learns which contacts and relays it needs to query. If you use Nostr Connect, you add a remote-signing service or bunker to the path. None of this is special to Slidestr; it is the normal cost of turning an open protocol into a comfortable interface.
The source-code situation should be read with the same practical caution. The repository is visible and useful, but the live bundle should be treated as the current deployed behavior. The root did not expose a clear license file in this check. That means you can inspect how the app works, but you should not assume you have reuse rights until the maintainer has made licensing explicit.
How to test it
Start without logging in. Open the default Slidestr route and wait long enough for relay data to arrive. Check whether the page shows "Mixed hashtags," a masonry grid and a working slideshow button. Open a single image, then inspect where the media URL actually points. If the thumbnail is proxied through `images.slidestr.net`, compare that to the original image URL in the event or browser network panel. You will understand the product faster by following one image all the way down than by reading another directory blurb.
Then test routes. Try a simple `/tags/photostr` route, a broader topic route, and a profile route with a known npub. Compare what Slidestr shows against another Nostr client. If an image appears in one place but not another, ask whether the issue is relay coverage, event kind support, content filtering, broken media hosting or duplicate URL extraction. This is where Slidestr becomes educational. It exposes the messy edges of media interoperability.
If you log in, do it with a signer you already understand. Try one low-stakes public action, such as a reaction on a disposable or test identity, then open the result elsewhere. Do not treat the visual interface as private just because it feels like a gallery. Hearts, reposts, zaps and bookmarks can be signed public or semi-public Nostr artifacts depending on how the app implements them and which NIP applies.
The fair verdict is that Slidestr is a strong niche client. It has a clear job, a visible builder trail, source code, a real deployed app, concrete routing, sane default relays, media-specific filtering, NIP-07 login, Nostr Connect support, reactions, zaps and a fast gallery experience. Its limits are the same limits that make it interesting: media URLs rot, proxies centralize convenience, public tags need moderation, relays shape reality and signer prompts matter. For readers trying to understand Nostr media, that is exactly why Slidestr belongs on the shelf.
Sources worth opening
This article keeps claims close to the live app, the public source trail, browser-visible behavior and the Nostr standards that explain what Slidestr is reading and signing. Start here if you want to verify the current state yourself.
- Slidestr official web app
- Slidestr default mixed hashtag route
- Slidestr web app manifest
- Slidestr NIP-05 nostr.json
- Slidestr deployed JavaScript bundle
- Slidestr deployed CSS bundle
- Slidestr source repository on git.v0l.io
- Slidestr package.json
- Slidestr App.tsx routing and NDK setup
- Slidestr env.ts hashtags, relays and filters
- Slidestr SlideShow.tsx media and action surface
- Slidestr Settings.tsx content controls
- Slidestr media URL extraction code
- Slidestr on NostrApps
- Nostr Compass project index
- Nostr Clients and Other Stuff index
- florian public profile on Damus
- florian public profile on nostr.com
- florian's adjacent PhotoShare repository
- NIP-01: basic protocol flow
- NIP-05: DNS-based identifiers
- NIP-07: browser signer capability
- NIP-18: reposts
- NIP-25: reactions
- NIP-36: sensitive content
- NIP-46: Nostr remote signing
- NIP-57: Lightning zaps
- NIP-65: relay list metadata
- NIP-68: picture-first feeds
- NIP-92: imeta tags
- NIP-94: file metadata
- NIP-B7: Blossom
- Nostrability discussion: video transcoding and media weight
- Nostr Development Kit source
- nostr-tools package
- nostr.build media hosting
- nostrcheck.me media and Nostr services
