CraysYakiHonne
YakiHonne is not just a feed client. It is a web and mobile workspace for publishing notes, articles, videos and curations, managing relays, experimenting with Smart Widgets and moving sats through Lightning, NWC, Cashu and Nutzaps.
The client that wants the whole desk
YakiHonne is easy to underestimate if you only glance at the landing page. The official site calls it a decentralized social and payment client on Nostr and Bitcoin, and the live web app opens with the sort of left-rail you expect from a serious publishing tool: Home, Media, Relay Orbits, Explore, Articles, Smart widgets, Messages, Notifications, Search, Download app, Post new and Log in. That menu tells you more than a slogan. YakiHonne is trying to be the place where a creator writes, posts, watches media, curates other people's work, keeps a wallet nearby and controls which relays carry the material.
That is a very different promise from "here is a Nostr feed." A feed client can be judged by scrolling, replies and muted accounts. YakiHonne has to be judged by a larger set of jobs: whether a long article is understandable outside YakiHonne, whether a video survives after the tab is closed, whether a curation event can be read by another client, whether a zap uses standard Nostr receipts, whether a mobile share sheet actually publishes the media you intended, and whether the relay tools give power users enough control without burying new users.
The public distribution trail is unusually broad for a Nostr client. There is a web app at yakihonne.com with a PWA manifest, an Apple App Store listing, a Google Play listing, and fresh open-source repositories under the YakiHonne GitHub organization. The current official web repository was created in October 2025, is MIT licensed, uses Next.js 15 and React 19, and had recent activity in May 2026 when checked for this page. The current official mobile repository is a Flutter app, also MIT licensed, with recent May 2026 activity. Older repositories such as the previous mobile app and web app are archived, which is the right signal to look at the new `web-app` and `mobile-app` repos rather than copying old assumptions from stale code.
The operator trail is also clearer than many small Nostr apps. The Apple listing names JUSTHONNE TECHNOLOGY SDN. BHD. as seller and shows YakiHonne as a Social Networking app. Google Play lists JustHonne Technologies and a Malaysia developer profile. That does not automatically make the app safer, but it gives readers a concrete entity trail instead of a faceless URL. For a client that touches identities, posts, DMs, media and payments, that matters.
NostrApps describes YakiHonne as a Nostr social client for posting, engaging and managing many content types with Bitcoin support. Its feature summary matches what the app and repositories show: web and mobile apps, short notes, long-form writing, videos, curations, social reactions, zaps, bookmarks, interests, dashboard views, search, Relay Orbits and miniapps through widgets. The product is wide on purpose. If Primal feels like a polished social reader, Habla feels like a writing surface and noStrudel feels like a power-user lab, YakiHonne sits somewhere between a creator studio and a protocol playground.
What actually lands on Nostr
The serious way to read YakiHonne is to ask what it publishes, not what it markets. In the current web code, long-form articles are not stored as a private YakiHonne-only object. Article pages use `kind 30023`, the NIP-23 long-form content event. That is the right standard for essays, because it gives an article a stable addressable identity through tags such as `d`, `title`, `image`, `summary` and `published_at`, and lets other Nostr clients discover the same object without scraping a website.
YakiHonne's curation surface is more specialized. The web code handles `kind 30004` for article curations and `kind 30005` for video curations, then pulls referenced posts such as `kind 30023` articles and video-oriented events. The app also works with `kind 34235` video posts. That is why the app feels less like a simple timeline and more like a set of shelves: articles, videos and collections are different Nostr objects with different reading behavior.
Comments are another useful clue. The 2026 web changelog added NIP-22 comments, and NIP-22 defines `kind 1111` comments for replying to external and addressable content in a way that is not limited to classic text-note threading. That is exactly the kind of standard a publishing client needs. If a reader comments on an article, a video or a curation, the comment needs enough context to survive across clients and relays. A plain reply can work in simple cases, but richer media and addressable events need better anchors.
YakiHonne also stays close to the familiar social primitives: short notes, replies, likes, reposts and zaps. NIP-57 uses `kind 9734` zap requests and `kind 9735` zap receipts, so a zap is not just a button animation inside one app. It is an event trail other Nostr tools can inspect. The web app's wallet files reference zap receipts, WebLN, Alby and Nostr Wallet Connect. The mobile app changelog also mentions sats gift packets in messages and later NWC improvements. In other words, the payment layer is not bolted onto a static blog; it is woven through the social actions.
A spot check against YakiHonne's own relays on June 7, 2026 found real Nostr events for `kind 30023`, `kind 30004`, `kind 30005`, `kind 30033`, `kind 34235` and ordinary note replies. Some events carried a `client` tag for YakiHonne; some video events came from other Nostr clients. That distinction matters. The relays are not merely a private warehouse for YakiHonne-generated data. They are Nostr relays, so the right question is whether a standard event can move through the wider network and remain useful in other contexts.
The best news here is that YakiHonne appears to lean on Nostr's addressable-event model instead of inventing a closed publishing database. The harder truth is that broad event support creates broad compatibility work. A long-form article, a curation, a video event, a Blossom media object, a NIP-22 comment and a zap all have different failure modes. If one client renders only the headline, another misses a referenced video, and a third ignores the comment relation, the protocol still works, but the human experience feels broken. YakiHonne is betting that one client can make enough of that complexity legible.
Relays, Orbits and the YakiHonne infrastructure
Relay Orbits is one of the product's strongest ideas because it pulls infrastructure out of the basement. Most people learn Nostr as "keys, clients and relays," then spend months treating relays as mysterious background plumbing. YakiHonne puts relay browsing and relay favorites in the app, which is healthy for creators. A writer or video publisher should know where their posts are published and which relays a reader might use to find them.
The official web README says YakiHonne runs `wss://nostr-01.yakihonne.com` and `wss://nostr-02.yakihonne.com`, free for creators to publish, based on strfry. Their NIP-11 relay information documents back that up. On June 7, 2026, both returned relay metadata identifying them as YakiHonne strfry relays. `nostr-01` reported support for NIPs 1, 2, 4, 9, 11, 12, 16, 20, 22, 28, 33 and 40 and a strfry version string; `nostr-02` reported a similar profile. The relay description says they are mainly for long-form content creators.
That relay choice is not accidental. strfry is a C++ Nostr relay implementation widely used by operators who want performance and control. By running its own relays, YakiHonne can provide a better default home for long-form and media-adjacent events than a random public relay that may prune, rate-limit or ignore larger creator workflows. But it also means readers should not confuse "Nostr" with "YakiHonne relays." If your identity and content matter, publish to more than one relay, inspect the events outside YakiHonne and keep a relay list you understand.
The web app source lists a broader relay set as platform defaults, including `wss://nostr-01.yakihonne.com`, `wss://nostr-02.yakihonne.com`, `wss://relay.damus.io`, `wss://relay.nsec.app`, `wss://nos.lol` and `wss://monitorlizard.nostr1.com/`, with additional server-side generation relays such as `wss://relay.primal.net`. The source tree also includes content, inbox, search, outbox and favorite-relay settings. That is exactly the kind of relay vocabulary a serious client needs. NIP-65 relay lists, outbox relays and search relays are not glamorous features, but they decide whether your work can be found.
One useful caution from the relay check: YakiHonne's relays answered normal `REQ` subscriptions but did not accept `COUNT` during the spot check, returning an unknown-command error. That does not make the relays bad. COUNT support is NIP-45, and not every relay exposes it. It does mean that a user or researcher should not assume all relay analytics tools will work against these relays. If you are auditing reach, use real subscriptions and client-side inspection instead of relying on a single relay count command.
Smart Widgets are the strange part
Smart Widgets are the part of YakiHonne that feels most experimental and most worth watching. A widget is not just a post. It is a small interface that can be created, published and embedded in a host client. The public Smart Widgets pages and docs describe a builder, action-tool widgets and a host/client communication model. The GitHub organization backs this with `smart-widget-handler`, `smart-widget-builder` and `sw-dynamic-api` repositories.
The `smart-widget-handler` README describes a JavaScript/TypeScript library for communication between a host app and a client widget through `window.postMessage`, including Nostr account metadata and event handling. The `smart-widget-builder` README describes creating and publishing Smart Widgets to relays, configuring relays, signing events and searching Nostr events. The dynamic API boilerplate combines Express, Puppeteer, nostr-tools and the builder library. That is a real stack, not a decorative feature tile.
In the YakiHonne web app itself, the Smart Widget editor signs `kind 30033` events with metadata tags such as `d`, `l` and `icon`, and requires a user signing path through local keys, an extension or a bunker. That combination is important. A widget system becomes dangerous if it blurs the line between rendering interface and signing events. The host can display a widget, but the user's key should still be protected by explicit signing boundaries.
The upside is easy to see. A creator could publish a poll-like tool, a media curation surface, a zap action, a mini app for collecting submissions or a custom reading widget without asking one platform to add the feature globally. That fits Nostr's culture: ship a small thing, publish it as an event, let clients decide how much they support. The downside is equally real. Portable interface is not the same as portable trust. A widget can be visually persuasive while still depending on a particular host, remote script, server endpoint or signing request pattern. Readers should inspect what a widget asks to sign before treating it as harmless content.
This is the kind of feature that may age very well or very messily. If YakiHonne can make widgets auditable, permissioned and interoperable, it becomes more than a client. It becomes a way to package small Nostr-native tools. If the widget ecosystem turns into opaque embedded web apps, then the protocol gains another layer of confusion. The current code shows serious effort, but the category still deserves sharp eyes.
Media, Blossom and files that have to survive
Media is where Nostr clients often reveal whether they understand the protocol or only understand timelines. Relays are good at Nostr events. They are not meant to be a universal media CDN. A creator who publishes images, covers, thumbnails, video clips and article media needs file storage, metadata and a way for other clients to find the file later. YakiHonne has clearly spent time here.
The current web changelog added a dedicated Blossom file-management page, icons for Blossom options, Blossom URL fixes, HLS video playback and `imeta` support for uploaded files. The source tree includes Blossom pages, upload components, file viewers and a `useBlossomManagement` hook. The mobile app's 2026 changelog likewise mentions Blossom upload views, Blossom server management, internal Blossom item opening and thumbnail fixes. This is not just a button labelled "upload." It is an ongoing product surface.
Blossom matters because it separates the Nostr event from the binary file. NIP-B7 explains how Nostr clients can use Blossom for media, and NIP-94 gives a file metadata event shape. NIP-96 historically described HTTP file storage integration, but the NIPs now mark it as deprecated and point readers toward Blossom/NIP-B7 for modern work. YakiHonne's file handling sits right in that transition zone: old Nostr media patterns still exist, but Blossom is becoming the clearer path for clients that care about portable files.
The risk is simple: a Nostr event can outlive the file it references. An article event may be visible while its cover image is dead. A curation can still list a video while the video host stops serving the bytes. A Blossom server can disappear, refuse a file or require authentication. That does not make media on Nostr a bad idea. It means the storage layer has to be part of the publishing workflow, not an afterthought. When you test YakiHonne, upload something small, inspect the event metadata and then open the media from another client or a plain browser session.
YakiHonne is strongest when it makes these file decisions visible. A creator should be able to know which Blossom server is being used, whether the event contains `imeta`, whether the URL is portable, and whether a video is just embedded from a source that another client might ignore. The presence of Blossom management in both web and mobile is a good sign, but the proof is always in cross-client survival.
Wallets, zaps, Cashu and the small-money layer
YakiHonne's Bitcoin support is not a decorative "tip jar" line. The web app depends on Alby SDK, WebLN, Nostr Wallet Connect and Cashu libraries; the source includes Lightning wallet, NWC wallet and Cashu surfaces; the mobile app includes wallet manager code, Cashu wallet views and NWC-related assets. The app store descriptions position YakiHonne as a social payment client, which is accurate enough to take seriously.
The standards involved are distinct. NIP-57 defines the zap flow and its `kind 9734` and `kind 9735` events. NIP-47 defines Nostr Wallet Connect, which lets a client request wallet actions through Nostr-style encrypted messages instead of holding a user's wallet directly. NIP-60 describes Cashu wallets, and NIP-61 describes Nutzaps, the ecash-style zap path. The web changelog explicitly mentions ECash support, Nutzaps, wallet restoration, QR code payments and wallet selection. The mobile changelog mentions sats gift packets in messages and NWC multi-relay work.
This is exciting because Nostr publishing and small payments belong together. A reader can zap an article, a video, a note, a widget or a creator. A publisher can receive value without waiting for ad networks or a platform subscription system. In the best version, the client simply becomes the place where social intent and payment intent meet.
But wallet features deserve less romance than the average Nostr demo gives them. YakiHonne's own mobile issue tracker includes a report where zaps appeared to fail while sats were repeatedly taken. That is exactly the kind of edge case users must respect. A payment UI can be wrong about final state. A wallet can send even when the social client reports an error. A relay can miss the receipt. A NWC connection can have too much permission. The practical advice is boring and correct: test with small amounts, use spending limits, prefer wallets that show independent transaction history, and do not let a social app become the only truth about your money.
Cashu and Nutzaps add another layer. Ecash can be useful for small, flexible value movement, but it introduces mint trust, token handling, restoration paths and UX complexity. YakiHonne shipping those surfaces is ambitious. It also means the app must explain itself clearly to non-experts. If a user cannot tell the difference between a Lightning wallet, NWC, a Cashu mint and a Nutzap, the product has more education work to do.
Mobile apps, permissions and privacy
The mobile app matters because Nostr publishing is not only a desktop writing habit. People share photos, clips, links and voice-like media from phones. YakiHonne's current mobile app is built in Flutter and uses its own `nostr_core_enhanced` package, along with Amber integration, secure storage, webview components, audio/video packages and Sentry. The code tree includes Nostr parsers, Nostr repositories, Blossom logic, Cashu wallet management and wallet views. This is a substantial client, not just a web wrapper with an icon.
The store listings are worth reading with precision. Apple shows version 2.0.5, updated May 14, 2026, category Social Networking, free, with App Privacy stating Data Not Collected. Google Play also shows a May 14, 2026 update, 1K+ downloads, JustHonne Technologies as developer and a Data Safety section stating no data shared with third parties and no data collected. That is useful app-store telemetry information. It does not mean your Nostr posts are private. Public Nostr events are public by design, and relays can keep what they receive.
The mobile permissions tell the practical story. Android requests internet access, notifications, record audio and boot-related notification support, and defines handlers for `nostr`, `nostr+walletconnect` and a long list of Nostr web domains. iOS defines URL schemes for `nostr`, `nostr+walletconnect`, `nostrwalletconnect` and share media, plus associated domains for yakihonne.com. Its plist includes camera usage for QR codes, microphone usage when recording video, photo library usage for profile pictures and article covers, location wording tied to Exif data, background modes and document/share handling.
None of those permissions are shocking for a mobile publishing client. They are exactly what you would expect from an app that scans wallet QR codes, records media, shares files, handles Nostr links and opens NWC connections. The important part is user expectation. A reader who only wants to write text notes may not need the same permissions as a creator using video and mobile sharing. An app can be privacy-respecting at the store-telemetry layer and still ask the user to publish irrevocable public events. Those are different claims, and the article reader should keep them separate.
Private messaging is another place to be careful. NIP-17 uses NIP-44 encryption and gift wrapping for private direct messages. YakiHonne's mobile issue tracker includes a report about deleting received NIP-17 DMs not working on Android. That does not prove messages are unsafe; it proves the product is still working through real edge cases. In Nostr, deletion requests, local storage, relay persistence and client UI can diverge. If a message is sensitive, do not assume a delete button has erased every copy everywhere.
Maturity, risk and what to watch
YakiHonne is active, ambitious and unfinished. That combination is normal in Nostr, but readers should name it clearly. The web repository had open issues when checked, and the mobile repository had dozens. Recent issues include crashes on open, muted-user notification problems, deleted events still appearing, missing posts in the feed, a request for NIP-51 list support, a quote-note behavior bug and the NIP-17 DM delete problem. Some of those are ordinary client bugs. Some touch trust, privacy, or money.
The upside is that the code is public and recent. The web and mobile repositories are under the YakiHonne organization, the current app line is separate from archived older repositories, the changelogs are detailed, and the project is shipping real Nostr features rather than merely talking about decentralization. The 2026 changelogs mention NIP-22 comments, relay invitations, relay reviews, scheduled notes, custom feeds, auto-translation, Blossom management, HLS video playback, ECash, Nutzaps, QR payments and NWC fixes. That is the rhythm of an app team pushing through hard surfaces.
The risk is the same as the strength: too much surface area. A simple client can polish one workflow. YakiHonne has to make article publishing, video, curation, relays, widgets, messages, zaps, Cashu and mobile permissions feel coherent. A bug in one area can make users distrust the rest. A creator who publishes an important article may not care that Smart Widgets are clever if relay publication fails. A wallet user may not care that Relay Orbits are powerful if a zap status is confusing. Broad products need unusually careful UX because every tab borrows trust from every other tab.
So the right stance is neither hype nor dismissal. YakiHonne is one of the more complete attempts to make Nostr feel like a creator operating system. It has real code, real app-store distribution, real relays, real media work and real payment features. It also has enough moving parts that a serious user should test it deliberately before making it the center of a publishing workflow.
How to test YakiHonne
Start with a test key or a signer that lets you see every permission request. Open the web app, connect through a NIP-07 extension or another supported signing path, and publish one low-stakes text note. Then inspect whether another client can find it on the same relays. If it only feels real inside YakiHonne, you have learned something important.
Next, publish a short long-form article. Look for a `kind 30023` event, a stable `d` tag, title metadata and any image metadata. Open the article from a different NIP-23-aware client or relay tool. Then test a curation or video flow if that is your use case, paying attention to `kind 30004`, `kind 30005`, `kind 34235` and NIP-22 `kind 1111` comments. The standard does not help if the event is technically valid but practically invisible.
Test relays separately. Add or favorite a relay in Relay Orbits, publish to the YakiHonne relays and at least one non-YakiHonne relay, and watch where the events appear. Remember that `wss://nostr-01.yakihonne.com` and `wss://nostr-02.yakihonne.com` are useful creator relays, not a substitute for understanding your own relay list. If a relay tool expects COUNT and these relays do not answer it, use a normal subscription check.
For media, upload something small and non-sensitive. Confirm where the file is stored, whether Blossom is involved, and whether the event carries enough file metadata for another client to render it. Then close YakiHonne and open the file URL outside the app. Nostr media that cannot survive outside the first client is not really portable media.
For wallets, move slowly. Connect NWC with strict limits, zap a tiny amount, and compare YakiHonne's UI with your wallet's own transaction history. If you test Cashu or Nutzaps, use a small balance and understand which mint is involved. The goal is not to distrust YakiHonne. The goal is to make the social app prove it can handle money without becoming the only witness.
Finally, install the mobile app only after reading the permissions in context. Camera, microphone, photos, notifications, share intents and NWC URL schemes make sense for a media and payment client, but they are still permissions. If you mostly read and write, you can choose a narrower setup. If you publish from your phone, YakiHonne gives you a lot of power in one place. That power deserves a careful first hour.
Useful Nostr context
These pages help compare long-form publishing with media, zaps and adjacent writing tools.
- Media: The broader publishing and creator media shelf.
- Habla: A nearby long-form Nostr publishing tool.
- Shakespeare: Another long-form editor and publishing reference.
- NIP-57 zaps: Payment context for reader-supported writing.
Sources worth opening
This page leans on the live product, app stores, GitHub repositories, relay metadata, source files and Nostr specs. These are the sources worth opening before you trust the summary.
- YakiHonne official web app
- YakiHonne PWA manifest
- YakiHonne mobile app links
- YakiHonne Smart Widgets page
- YakiHonne Smart Widgets docs: getting started
- YakiHonne Smart Widgets docs: builder
- YakiHonne Smart Widgets docs: action-tool widgets
- YakiHonne on NostrApps
- YakiHonne on the Apple App Store
- YakiHonne on Google Play
- YakiHonne GitHub organization API
- YakiHonne GitHub repositories API
- YakiHonne web-app repository
- YakiHonne web-app repository API
- YakiHonne web-app README
- YakiHonne web-app changelog
- YakiHonne web-app package.json
- YakiHonne web-app relay list source
- YakiHonne web-app signing and encryption helpers
- YakiHonne web-app article source
- YakiHonne web-app curation source
- YakiHonne web-app Smart Widget editor source
- YakiHonne web-app Lightning wallet source
- YakiHonne web-app NWC wallet source
- YakiHonne web-app Blossom upload source
- YakiHonne web-app Blossom management hook
- YakiHonne web-app Lightning wallet hook
- YakiHonne mobile-app repository
- YakiHonne mobile-app repository API
- YakiHonne mobile-app README
- YakiHonne mobile-app changelog
- YakiHonne mobile-app pubspec
- YakiHonne Android manifest
- YakiHonne iOS Info.plist
- YakiHonne mobile Nostr functions repository
- YakiHonne mobile Blossom logic
- YakiHonne mobile Cashu wallet manager
- YakiHonne mobile issue 77: zap status/payment risk
- YakiHonne mobile issue 76: muted-user notifications
- YakiHonne mobile issue 57: deleted event visibility
- YakiHonne mobile issue 55: feed posts missing
- YakiHonne mobile issue 81: NIP-51 lists request
- YakiHonne mobile issue 78: NIP-17 DM delete behavior
- YakiHonne smart-widget-handler repository
- YakiHonne smart-widget-handler README
- YakiHonne smart-widget-builder README
- YakiHonne Smart Widget dynamic API README
- YakiHonne nostr_core_enhanced README
- Archived YakiHonne mobile app repository
- Archived YakiHonne mobile app README
- YakiHonne relay 01 NIP-11 information
- YakiHonne relay 02 NIP-11 information
- strfry relay implementation
- Blossom specification repository
- NIP-23: long-form content
- NIP-22: comments
- NIP-07: browser signer API
- NIP-17: private direct messages
- NIP-44: versioned encryption
- NIP-46: remote signing
- NIP-47: Nostr Wallet Connect
- NIP-57: Lightning zaps
- NIP-60: Cashu wallets
- NIP-61: Nutzaps
- NIP-65: relay list metadata
- NIP-89: recommended application handlers
- NIP-94: file metadata
- NIP-96: HTTP file storage integration
- NIP-B7: Blossom media
