CraysEmojito
Emojito is not trying to become a full social client. Its job is narrower and more revealing: create, browse and bookmark custom emoji sets so your reactions can move through Nostr instead of being trapped inside one platform's private sticker drawer.
The joke has structure
Custom emoji looks unserious until you watch a community use it for a week. Then it becomes obvious that these tiny images are not just decoration. They are a shared accent. They are inside jokes, status signals, soft applause, mockery, membership, memory. A good custom emoji set can say "we know each other" faster than a paragraph.
That is why Emojito deserves a real article instead of the old catalog sentence. The app is not another general Nostr client. It is a small workshop for one social layer: the reaction language that grows around a group. NostrApps describes Emojito in plain terms as a web app to create custom emoji sets, with the highlight that those sets can be used on supported clients. The older public page metadata said the same thing in a more playful voice: stir up your reactions with custom emoji.
The important word is supported. Emojito does not magically make every Nostr app render your favorite GIF or meme face. It creates Nostr data that other clients can understand if they implement the relevant NIPs. That difference matters. A normal platform emoji pack lives inside one company's database. Emojito's idea is closer to: make the set a signed Nostr object, let people bookmark it, let clients read it, and let the culture move with the users instead of the other way around.
If you have ever been in a Discord, Slack, Telegram or forum group where the custom emoji carried half the tone of the place, you already understand the product. Emojito asks what that would look like if the emoji set were not locked to the platform account that uploaded it. It is a small question, but it touches something large: who owns the little rituals of an online community?
How Emojito wants you to use it
The app's own flow is beautifully short: create or find an emoji set, bookmark it, react. That is the whole loop. No grand manifesto is needed. You either want to make a pack, collect a pack, or use a pack in places where Nostr clients support custom emoji.
The source code makes that flow concrete. The home view shows featured packs such as SUSHIYUKI, Reacts and Nostopus, then asks Nostr for application handler events that advertise support for emoji sets or emoji lists. That last part is a nice piece of protocol thinking. Instead of pretending Emojito lives alone, the page tries to show which other apps say they can handle the same data. In a healthy Nostr ecosystem, that is exactly the point: one tool creates the object, another tool renders it, another tool may help you browse or edit it.
The new-set screen is just as direct. You give the set a name, add shortcodes, pick images, preview the result and save. Under the hood, save does not mean "send this to Emojito's private database." The code constructs an emoji set event, signs it through the user's signer, publishes it, then routes you to the encoded address for the set. If you own the set, the UI exposes edit behavior. If you like someone else's set, the UI exposes a bookmark action.
That bookmark action is not a browser favorite. It updates your Nostr emoji list, which means your chosen set can follow your public key. Again, this is the thing to notice. Emojito is useful because it turns a very social object into something that can be signed, referenced and discovered. You are not just copying a funny image URL; you are pointing at a set that has an author, a name, tags and an address.
The events under the smile
The protocol center is NIP-30 and NIP-51. NIP-30 defines custom emoji tags: a shortcode and an image URL that clients can use when a post contains the matching shortcode. NIP-51 then gives us list and set kinds. Kind 10030 is the user's preferred emoji list, and kind 30030 is an emoji set. If you want the product sentence in one breath, here it is: Emojito helps people create kind 30030 sets and bookmark them through kind 10030 lists so clients that support NIP-30 can render those shortcodes as images.
That sounds technical, but it is not abstract. Imagine you create a set called "Crays Kitchen" with shortcodes for a chef kiss, a tiny espresso machine, a dramatic table flip and a club-specific reaction GIF. The event does not need to carry the image files themselves. It can carry the names and URLs. A client reads the set, sees the shortcode, fetches the image and displays it where the text contains the matching marker. The event is small; the cultural effect can be big.
Emojito's code follows this shape closely. The new emoji set component builds a set with a stable identifier, a title and a list of emoji tags. The emoji set view reads those emoji tags, renders their images, shows the author and lets a signed-in user open, bookmark, unbookmark or edit when they are the creator. Reactions on the set itself can also be shown, including regular reactions and zaps. That makes the set feel like a Nostr object, not a settings screen.
There is also a subtle portability lesson here. A custom emoji event is not valuable because every image URL is eternal. It is valuable because the relationship between the shortcode, the image and the author can be expressed in open data. If the image host dies, the emoji breaks. If a client ignores custom emoji, the emoji disappears into text. But the object is still understandable in a way a closed-platform sticker pack usually is not.
The builder trail
The public listing for Emojito points to the author key npub107jk7htfv243u0x5ynn43scq9wrxtaasmrwwa8lfu2ydwag6cx2quqncxg. The Nostr profile behind that key uses the name verbiricha, describes the account as an avant-garde Nostr dev and points to Grimoire. That fits the code trail: the repository that matters here is verbiricha/ngine, a TypeScript Nostr application framework under the MIT license.
Inside that monorepo, Emojito appears as apps/emojis. The package is a Next.js app and the package file names the working parts plainly: Next 14, React 18, Chakra UI, Nostr Development Kit, NDK cache Dexie, TanStack React Query, nostr-tools, react-intl and @ngine/core. The root monorepo uses pnpm and Turbo. This is not just a link directory with a logo; there is a real app surface in the source.
The repo facts are worth reading with the right temperature. GitHub shows verbiricha/ngine as a public TypeScript project created in December 2023, MIT licensed, with a small number of stars and forks, and its last push recorded in January 2025. The package itself is marked private, which in npm language means it is not meant to be published as a package. It does not mean the source is hidden. It means the app lives inside the framework repo.
The public domain story is messier. NostrApps still links to emojito.meme, search results preserve an older crawl of the live page, and the code's metadata sets the base URL to that same domain. But when checked on June 6, 2026, the domain returned Vercel's deployment-not-found response. That is not a reason to erase Emojito from the hub. It is a reason to be honest: the project has a real Nostr and code trail, but the live deployment is not something we should present as reliably available today.
Where it gets practical
The best use case is a community that already has its own tone. A public Nostr group, a dev circle, a music scene, a meme-heavy relay, a venue community, a DAO chat, a fan base, a zine crew: all of them can benefit from a shared pack that travels with people. You do not need Emojito if you only want the Unicode smiley everyone already has. You need it when the reaction belongs to your crowd.
For creators, the interesting part is identity. A musician could publish reaction GIFs for fans. A conference could publish event-specific emoji. A software project could turn release rituals into a pack. A local venue could use a custom set for regulars. Because the set is tied to a Nostr author and an address, it has a better chance of becoming part of the public social memory around that creator than a file tossed into one chat room.
For app builders, Emojito is a small test of interoperability. Can your client parse NIP-30? Can it let a user pick from bookmarked sets? Can it display kind 30030 groups without making the composer feel heavy? Can it avoid ugly broken images when a URL fails? Can it show enough context that users know whose set they are using? These are not giant features, but they are the details that make Nostr feel less like raw protocol and more like an inhabitable place.
For Crays, that is why the app belongs on the product shelf. We care about tools that turn a public key into social agency. Emojito does that at the smallest scale: a reaction. You sign a set, you share it, another client may use it, and the group gets a tiny piece of portable language. Small, yes. But culture is often made of small repeated signals.
The careful part
There are three things to check before you depend on Emojito or any tool like it. First, client support. If the apps used by your people do not render custom emoji or emoji sets, the pack becomes a clever object that nobody sees. That is why the source code's supported-apps section matters: the app itself knew this feature needed an ecosystem around it.
Second, media durability. A kind 30030 set can point to image URLs, but the images still live somewhere. If the host deletes them, blocks hotlinking or disappears, the set turns into names without pictures. A serious community pack should use media hosting it understands and can maintain. Nostr makes the reference portable; it does not make every image immortal.
Third, moderation and taste. Custom emoji can be delightful, but it can also carry copyright problems, harassment, spam, shock material or tracking-heavy image URLs. A client that renders everything without context can surprise its users. A community that publishes a pack should think like a publisher: who made these images, where are they hosted, are they safe to show, and what happens when someone tries to weaponize the joke?
Read Emojito with that adult caution and it becomes more valuable, not less. The app shows how Nostr can carry the soft, messy, funny parts of social life without needing one platform to own them. Even if the current public deployment needs repair, the idea is strong: your reaction language should be something your community can create, sign, share and carry.
Sources worth opening
Start here if you want to verify the project yourself. The official domain is included because it is the public project URL, but as checked on June 6, 2026 it was not serving the app.
- Official Emojito domain
- Emojito on NostrApps
- verbiricha Nostr profile mirror
- verbiricha npub on njump
- verbiricha/ngine on GitHub
- Emojito source folder in ngine
- Emojito home flow source
- New emoji set source
- Emoji set source
- NIP-30 Custom Emoji
- NIP-51 Lists and Sets
- Nostrbook on kind 30030 emoji sets
- verbiricha note about NIP-30 custom emoji
- NIP-25 reactions
- NIP-27 text note references
- Nostr protocol NIPs repository
- NIP-01 basic protocol flow
- NIP-05 DNS identifiers
- NIP-07 browser signer capability
- NIP-10 text note threading
- NIP-11 relay information document
- NIP-19 bech32 encoded entities
- NIP-44 versioned encryption
- NIP-46 remote signing
- NIP-56 reporting
