Nostr notes by raul_15

For now, yes, they can be simple web games. But they can be ...

2026-11-09T06:04:36Z

In reply to nevent1q…yr07
_________________________

For now, yes, they can be simple web games. But they can be native games as well.

sandwich (nprofile…pzjr) and hzrd149 (nprofile…e307) can answer in more detail. I'm not much of a gamer haha.

Look no further than: https://napplet.soy by @nprofile…763t ...

2026-11-09T05:23:03Z

In reply to nevent1q…tnde
_________________________

Look no further than:
https://napplet.soy by Schlaus Kwab (nprofile…763t)

Also, an appstore napplet: https://kehto.github.io/web/paja/?naddr=naddr1qqyxg6tnvdhhvetjqgsthdwa5rs42euhnuz5xsrmmssr84hshwes7uj392vpeldj7z0zw3crqsqqpzfee4ex6c

Works great on web, also being built for native shells.
More about napplets: https://napplet.run

Napplets fix this. #naddr1qq…r6gh

2026-11-08T07:03:56Z

Napplets fix this.

quoting
naddr1qq…r6gh

A paint app needs a canvas, some colors, and a way to undo a bad brushstroke. The user probably wants to copy or save the image locally. None of that requires a relay connection or a signing key. If you want to build one, you should be able to spend your time on the editor. And if someone wants to try it, they shouldn't have to trust you with everything else they do.

That's the thinking behind napplets and NIP-5D. A napplet is a small, focused app that runs inside a shell. The shell hosts the app, mediates its requests, and lets the user compose it with other apps. We deliberately put most of the weight on the shell so that building a napplet can stay simple.

Start with the app you want to make

There's already a paint napplet, an image editor called Fotohop, and plenty of games. They don't need to be about Nostr to belong here. Drawing a picture or playing a game doesn't require a social graph or an event to publish.

Fotohop running in the Applesauce napplet loader. Drawing made for this article.

Nostr provides the foundation for publishing and discovering napplets. Inside the app, you can use ordinary browser capabilities for the interface and computation, then ask the shell for any additional capabilities you need. You could build a drawing tool and add sharing later. The limits are the host environment and the capabilities the shell exposes; your app's purpose is yours to choose.

https://cdn.hzrd149.com/95be3bb45b50a27c2279983677250a9773f1784611955d8308b0512ebc8d42cb.mp4

Play Dodgy Duck, an endless voxel crossing game. Watch the gameplay preview

For developers arriving from outside Nostr, that matters. Knowing how to build a useful app should be enough to get started. If the idea needs Nostr features, you can learn the relevant event formats and conventions as you go. Some specialized apps will need quite a lot of protocol knowledge. A paint tool may need none of it.

Why put so much in the shell?

We arrived at this split through research and iteration, including the early prototypes. We looked at the security constraints, the infrastructure developers kept rebuilding, and what users had to understand before they could comfortably try an app. The goal was to make decisions against practical requirements rather than pick an architecture because it sounded elegant.

The balance involves three groups. Protocol developers need somewhere to handle Nostr properly. App developers need a manageable API. Users need a foundation they can trust. Moving protocol infrastructure and privileged operations into the shell gives each group a clearer job: protocol developers work on the shared services, app developers build their apps, and users choose how to put them together.

An app can ask for data and request actions through the shell's capabilities without building its own relay connection manager or signing flow. When someone improves the shell's routing or security, many apps can benefit. Shell developers take on more complexity, but each napplet author has less infrastructure to maintain.

https://cdn.hzrd149.com/ccc178d603389c403521f631f547a163c8748cc3e7609b115c51b010e331859c.mp4

The animated diagram on napplet.run cycles through relay, storage, media, notify, theme, value, upload, resource, and CVM. Requests and responses pass through the shell. Watch the full cycle.

The common contract between a napplet and the runtime providing its capabilities is called the capability seam. NIP-5D defines how it works on the web; individual NAPs define capabilities such as storage, relay access, and resource fetching. The NAP registry describes those contracts. Keeping them separate lets capabilities develop without putting every feature into the core specification, and gives different shells a common contract to implement.

Trust your shell. Distrust the napplets.

That's the footing we want users to have. The system treats napplet code as untrusted because an app can be buggy, carelessly generated, or deliberately malicious. Users shouldn't have to work out which one they're dealing with before the protections apply.

In the web model, the shell verifies the signed manifest and the hash of the app file before running it in a restricted iframe. It then binds incoming requests to the iframe it created. Privileged requests go through shell policy; napplets don't receive signing keys or a general signing and encryption API. The current draft defines that boundary.

Verification establishes which artifact is running, not whether its author means well. The restrictions still have to hold. An iframe sandbox alone doesn't block every network request, either, so shells need appropriate network restrictions. The draft discusses Content Security Policy for that purpose.

This makes the shell a serious responsibility. A bad shell can undermine the model. Broad permissions can weaken the protection, constant approval dialogs can become background noise, and excessive restrictions can prevent useful apps from working. Putting the decisions in one place gives users a place to make an informed trust decision, but shell developers still have to get them right.

That's where napplet/evil comes in. Its deliberately hostile napplets probe sandbox escapes, forged messages, manifest confusion, and access to another app's stored data. A configurable victim shell lets developers weaken protections and observe the consequences. The tests examine what happens when an app claims another app's identity, when a shell renders an attacker-written manifest title as HTML, or when a changed artifact inherits data it shouldn't have.

The project's research roadmap also reports fingerprinting exposure, WebRTC API availability despite the baseline Content Security Policy, and a test where a busy napplet stalled the shell's message handling. These are reported results from its harness, not an audit of every deployed shell. They give developers repeatable ways to challenge the assumptions and check fixes; a passing suite isn't a blanket security guarantee.

Protecting users this way is part of the adoption work. Trying a new app becomes a more reasonable choice when the shell can limit what it does. We want people to enjoy a tool without having to trust its author with everything.

The earlier approach, and NAPP

The NAPP protocol resembles a much earlier approach we explored before writing the napplet spec. We abandoned our own earlier design because it didn't satisfy the adoption requirements we were working toward. The resemblance is in the architecture; NAPP is a separate project.

Both approaches have small apps, a host, and a bridge to shared services. NAPP documents permissions and prompts for sensitive operations, but its bridge exposes NIP-07 signing and encryption methods. NIP-5D deliberately keeps those primitives out of the napplet. We want app developers to request useful operations while the shell handles more of the protocol and security responsibility.

NAPP's application surface is also more Nostr-forward: signing, event-store access, relay helpers, and Nostr actions are prominent. Napplets put Nostr services behind capability contracts alongside storage, media, and resource access. A paint tool or game is as much the point as a feed viewer. NAPP can host non-Nostr apps too; the benefit we're aiming for is making general applications a natural starting point without requiring them to organize themselves around Nostr.

Much like napplet/evil I put together evil-napps to test that model. It probes launcher isolation, forged bridge messages, action routing, shared-store abuse, and signing permissions. Its documentation distinguishes harness demonstrations from findings checked against the reference launcher's source. As with evil napplets, those findings aren't a fresh audit of every launcher. Both models deserve to have their assumptions tested.

Less code to carry around

A focused napplet can leave much of the infrastructure out of its own codebase. That's less code for a person to maintain and less context for a coding agent to consume. An agent building a paint tool can concentrate on drawing, the interface, and the capability contracts it uses.

That smaller scope and shared infrastructure can make napplets cheaper and faster to produce. There isn't a universal token saving or speedup to promise, and an app that pulls in a huge framework or tries to do everything can give much of the advantage back. Runtime costs need the same care: the shell consumes resources, and separate iframes have overhead. A smaller app and less duplicated infrastructure don't guarantee lower total memory use in every setup.

There are shells to try, and gaps to close

This is still alpha. The protocol is changing, and specifications, SDKs, and shells can drift apart. Capability coverage, interoperability, tooling, and the experience of building and using these apps all need work. The intended model and what a particular implementation delivers aren't always the same.

A napplet declares the capabilities it needs, and the shell decides what it can expose. Those declarations aren't permission grants. Optional features need fallbacks, and developers need to check what their chosen shell provides.

You can already explore different takes on the shell in Amethyst, Myco, noStrudel, Grimoire, and napplet.soy. Paja is a developer shell for loading napplets and inspecting their behavior. These projects are at different stages, with different capability support.

The Applesauce napplet store example shows a live list of apps discovered from Nostr relays. Browse it to see what people are making.

The Applesauce store example discovers napplets from relays. This screenshot is a snapshot; the live list changes.

Developers are working to close the gaps through the SDK and tooling, runtime work, and other implementations linked from the NIP-5D discussion. Those projects give us somewhere to test the design and improve it. Their existence doesn't make the protocol mature yet.

Make it together

napplet.soy's Studio gives you an interface for building in the browser: describe an idea, play the preview, and ask for changes. You connect a Nostr account and your own AI provider, then review the result before publishing. Its local tools let you work in your own editor or coding agent too.

napplet.soy Studio: ask for changes on the left and try the game on the right. Screenshot supplied by the author.

You can also build on someone else's work. The remix and contribution workflow lets you make your own version of a napplet or propose improvements to the original. For projects with Git source, a proposal includes a playable preview. The author can compare the original and proposed versions, inspect the code changes, discuss them, and merge locally. Publishing the updated app is a separate step.

Say someone makes a game you like, but the controls are awkward on your phone. You could remix it, improve the touch controls with your agent, and send back a version the author can actually play. Other people can try and discuss the proposal on the site. That gives the conversation something concrete to work with before the author decides what to release.

Try making something small

Run npx skills add napplet/web, open your coding agent, and ask it to use the napplet-make skill. Try: “Use napplet-make to build a simple paint napplet with a canvas, a color picker, and an undo button.”

Pick one small thing you'd like to use. Ask the agent to verify it and preview it in Paja, then try it yourself.

Nowhere will you find a group of people as cracked as they are at ...

2026-09-20T10:37:40Z

Nowhere will you find a group of people as cracked as they are at Sovereign Engineering (nprofile…0yke)

I built mapplets, a composable maps napplet that allows anyone to customize maps using Nostr and Blossom.

Until next time ❤👣

quoting naddr1qq…lm2x

The last week of every cohort we take a ride on the Pirate Ship off Madeira, to see whales, swim in the Atlantic and talk about the pirating we did the past six weeks and the pirating beyond. We pass the mic around asking each participant for highlights of the cohort which is encapsulated in the No Solutions episode "Drinking from the Firehose".

The first response set the pattern for the ride, "Napplets, FIPS, runtimes, shells. More FIPS, more napplets, more shells. FIPS over audio. Zazafication. Better friendships, jams, walks, barbecues."

balas (nprofile…znag) , who was at SEC-01, had one word; "pain", and said this cohort felt closer to the first one than any since, everyone figuring it out from scratch again.

hzrd149 (nprofile…tfpf) commented:

A year ago we were talking about where we want to be and what tech we want to have, and there were always missing gaps. Now there don't seem to be many..

Totem is a case in point. Totem is a modular hardware platform running napplets on devices that connect in a mesh. We first imagined it at SEC-03, then shelved it for two years, not because people lost interest but because you could not build it right yet. Gzuuus, who has spent more time at Sovereign Engineering than any human alive said, "Totem never died, it was waiting for FIPS and napplets and runtimes to exist." This summer Totem got built, it had a friend and the two talked to each other.

SEC-08 ran 20 July to 28 August. Six weeks of pure unadulterated YOLO++ with half alumni and half new faces. After the focused sprints of SEC-06 and SEC-07 we went back to open exploration: mesh networking, maps, merchant payments, package distribution, a desktop pet, and a multiplayer game stuffed into one HTML file.

Do you even FIPS yet?

Native FIPS, public-key-addressed application traffic with no IP stack in the way, was reserved for FIPS v2. By the end of this year at the earliest. Then you put jcorgan (nprofile…sjfc) and jeffg (nprofile…n0n6) in the same room and it is a one-week problem.

The native datagram API eliminates HTTP, TLS, TCP and IPv6 out of the equation. No more npub.fips hostnames. The npub is the endpoint, and it looks close enough to a Berkeley socket. JeffG benchmarked it while wiring it into Wok and the relay got 8 to 58% faster depending on message size. By demo day Wok spoke native FIPS and White Noise was FIPS only. Encrypted group chat with no IPs, and no DNS.

FIPS was in the air again;

sandwich (nprofile…jml3) sent FIPS over sound. FipWave modulates packets into audio and two laptops hold a conversation across a room with nothing but chirps. Somebody on the pirate ship proposed dolphins next.

fips-exit-gate, fips-shield, fips2go and a FreeBSD port ( fr34aky (nprofile…vwwj) ) - reaching the legacy internet, filtering application-level abuse, putting Android and FreeBSD on the mesh.

JeffG's fips-mac installs and runs a FIPS node on a Mac and shows the mesh from the menu bar. Johnathan's fipsctl gives you the command-line view.

hzrd149 added FIPS support to nostr-relay-tray, putting your desktop relay on the mesh.

Arjen (nprofile…8d6t) demonstrated LUKS over FIPS, remotely unlocking an encrypted NixOS drive.

hzrd149's FIPS Pong bridged a game across three machines through a browser tab. His own review: "completely useless, but it worked."

nprofile1qy2hwumn8ghj7ctww35hqunfd4skctnwv46z7qgwwaehxw309ahx7uewd3hkctcqyrn45xzuqxwsjpyatl9su2dzejdl6qtwcrmd3yhunrm0lcqcrfyq6hetmjk (nprofile…tmjk) and julien (nprofile…xyae) worked on CruxCoach, which syncs a group's climbing playlist over a local BLE/FIPS mesh without internet access. The app itself can be shared over the same mesh. J also used Android's accessibility features to extract the user's MoonBoard logbook, because the MoonBoard needs to be liberated from its enshittification.

Napplets, runtimes and shells

Nostr is easy to use badly and hard to use well. Key handling, signing, relay selection, caching, encryption, expiry, and on and on. Every client implements all of it, and most implement some of it wrong.

Sandwich spent the past year working on NIP-5D, the napplet protocol. A napplet is a sandboxed, single-purpose app that asks a host shell to handle signing, relay access and storage. It never holds your key, never picks your relays, and doesn't know anything about storage. The hard, security-critical work is handled by the shell.

So to write a Nostr app, you don't have to be a Nostr developer i.e. you. Nostr already hands you self-signed structured data and a client was only ever the presentation layer, but until now, we kept making people rebuild the whole Nostr protocol to build clients. Now, a napplet can be shared over Bluetooth via FIPS, or fit inside a link along with its state which can be run on any of the napplet shells.

gsovereignty (nprofile…r7e4) 's RocketShell is a web runtime for NostrRocket.

yo (nprofile…nyzf) 's Uzel is a native Debian napplet runtime. PABLOF7z (nprofile…fg8w) 's nampplets provides a native Rust runtime for macOS.

hzrd149's Napplet Portal provides a server-backed host you can reach from your phone.

Rage of Empires (Gsovereignty and Yo) - decompiled AoE from the Windows binary and packed into a single 83 MB HTML file, multiplayer running once as a napplet and once as an nsite. As put by a participant, "I thought it was dumb. After a few days I got it. We can reverse engineer so many of the applications from the last generation."

Arjen's Myco is a meta sneakernet app over FIPS mesh to share apps and communications. Sherry (nprofile…ulqg) and Arjen worked on file sharing, think AirDrop over the mesh, and André brought it to the desktop with myco-desktop.

Nostrocket (Gsovereignty and Jeroen ✅ (nprofile…zddk) ) - G started this years ago around an absurdly ambitious question: how do you build a system resilient to psychopaths? Jeroen revived it this cohort, rebuilt as composable napplets. If you are curious, and you should be, go egg them on.

Nappagochi (Sherry) turns your Nostr activity into the changing life of your Nostr pet.

Anon&Mato (Balas) generates a playable world from your npub. It is beautifully created.

XR napplets (Sandwich) - remember Google Glasses? This is napplets on AR glasses! Think HUDs.

Blossoming Hashtrees

We didn't just FIPS, we Nix'd over Blossom(ing) Hashtrees. This one came off a walk, which is the least surprising sentence in this report. A Nix guy and a Blossom dude went up the hill, and came down with Nix packages over Blossom.

Nix addresses everything by hash. Blossom stores blobs by hash. Do you see it now? It was obvious, but the left foot, right foot rhythm was required for left brain, right brain juices to flow and synchronise. By Friday we had Nix packages distributed with no registry.

nixstr-cache (hzrd149) and Narwal with its publisher (Julien)- resolve Nix packages over Nostr and Hashtree, blobs pulled from Blossom, served to an ordinary Nix client. The packages arrive through a standard Nix binary cache interface, so you can keep using nix build. Nostr announcements identify the publisher, and Nix checks the cache signatures against the keys you trust. It barely worked by Friday - very promising, the correct state for a Friday before the BBQ.

Hashtree explainer (hzrd149) - if you always wanted to know what a hashtree is, it's IPFS without the rest of IPFS.

During the Hashtree talk, someone asked whether a map of the Earth could use one root, with smaller areas fetched as you zoomed in. raul_15 (nprofile…n6s8) and Franchovy (nprofile…f5yf) went and built Mapplets. They used a modified hashtree for the map and Nostr events for the map data, including Madeira's bus routes. Map tiles load as you zoom, and private overlays are shared with the people you choose.

Just works

Our favourite Poncha bar in Funchal knows us as the Bitcoin people. Its payment terminal had been broken for weeks, so we kept paying in euros. One week a bunch of participants decided to team up and fix the UX.

Just Works ( Thomas (nprofile…3mq9) , Yo and Zaza (nprofile…4fq8) ) was built. Just Works just creates beautiful nsites that just work. It has info, menu, schedules, reviews, news, PoS, payments, etc. and keys.justworks ( Gzuuus (nprofile…h9pq) ) handles the keys underneath.

Just Works takes every establishment in the area. Scrapes their site and their socials, generates a pretty nsite from it, links back to the legacy profiles so their customers still recognise them, gives them an npub, a QR code and a point of sale, and then it puts all of them on the just works map. And you can just start tipping them because you love your local dive bar so much. The owner ends up with a profile, a site, key management and a pile of sats waiting to be claimed.

It also looks good - which is not a sentence we get to write often. Work this far down the stack and you tell yourself beautiful is somebody else's job, right after the protocol is right. Zaza sat down with people one project at a time and showed them otherwise, ran a workshop and by the last demo day almost everything had been Zazafied.

Then we had Granola ( Breno Brito (nprofile…52y5) ), an idea since 2024. At SEC-08 he found people to build it with. It coordinates Cashu atomic swaps over Nostr. Other work explored escrow and dispute resolution in anonymous marketplaces.

Meza ( Gigi (nprofile…tf6v) )- lets you zap a highlighted passage and split the payment between its author, the person who highlighted it, and Boris, the reading app.

600 Billion Timelock TCG ( FLX (nprofile…w87z) and Breno) on Nappelin makes every card in a booster pack a Cashu token, with NUT-22 blinded tokens keeping your hand private. Coloured coins on Cashu, for a card game.

Clankers, data, and the strange stuff

Agents got treated as ordinary users of the network this time. They discover things, pay for things, remember things, and generally make great teammates.

whisperhash (nprofile…773h) 's Nostrology exposes Nostr ecosystem metrics over MCP, maps marketplace growth by geography, and accepts Cashu payments for Nutzap data queries. An agent finds a dataset, pays for a query and gets its answer.

Nectar explores structured, attestable datasets on Nostr.

si-eval explores auditable model evaluation for tasks such as key handling and privacy.

MDK and White Noise agents (JeffG)- used agents to generate thousands of test scenarios for MDK and built White Noise/Marmot connectors for the major agent tools. Other experiments involved shared memory in White Noise groups and short “mantras” intended to improve small models' tool calls.

Rahul explored agents helping with real-life tasks through Mappy, then put an agent inside a napplet with Kipina.

fips.email (Thomas) - accepts email addressed to your npub and forwards it as an encrypted NIP-17 message to your DM relays. He built it for agents, though people can use it too. No FIPS involved. People just love FIPS.

Mist (Julien) lets you explore Nostr conversations in clusters.

We worked on hardware too. Totems running napplets in shells connected in a self-healing mesh of other Totems over FIPS. Participants had flown in with cases of tools and equipment to build. Even so, they could not build the things they really wanted, because Madeira has no makerspace. This inspired two of the participants to start one, ready to fund it themselves. Nodesignal_Podcast (nprofile…6t7h) and other donors piled in behind them, now Nostr Office is giving the lab a home.

People came here to build things and left behind a place for building things.

Talks and workshops

Everyone's AI setup - a fixture now. Every participant shows how they actually work: harnesses, prompts, tools, learnings, etc. No two setups match. You steal two things on day three, then have six weeks to refine and upgrade.

In the spirit of Bitcoin (Gigi) - What does it mean to build it in the spirit of Bitcoin? What is the spirit of Bitcoin? Nobody can define the spirit of Bitcoin in a sentence, but you know it when someone violates it.

Nostr anti-patterns (Gigi) - the old internet is a habit, and habits follow you. The talk was about habits of the old internet and anti-patterns in Nostr, when deliberately avoided, allow us to be liberated from.

Other talks: A primer on Marmot (JeffG), Construction on Nostr (Felix), Everything is a Stream (hzrd149), TEEs (Gzuuus), History of Maps (FLX), and Messaging Protocols (JeffG and Gzuuus)

Cohort Experiments

We skipped the break week this time. By week four everyone was feeling it. SEC-05 had a detox week at that point, and we will probably bring it back.

In week five, Johnathan paired everyone up and asked them to announce their demos three days ahead. Participants appreciated this and took on more complex problems together. We have tried this before and want to keep refining it.

For one week, demos lasted just a minute. You had to decide what people needed to see and get straight to it. The discussions afterwards were better too, because the demos left more questions unanswered. Someone suggested shortening them throughout the cohort, from six minutes in week one to one minute in week six. We want to try that. G also built the Demo Day Command Center to keep us within our allotted time, which provided plenty of entertainment.

The final week was deliberately quieter. After five weeks of building, Gzuuus suggested leaving more time to take it all in and talk to each other. We rarely get six weeks in the same room with these people, and wanted to make the most of the time left.

Walks and barbecues are still the highest leverage R&D we do. Solvitur ambulando.

Paths forward

We didn't know what Sovereign Engineering really was when we started. We set out with a direction, an unshakable belief to "fix the internet". We didn't know how, and most of the tools did not exist. Eight cohorts on, ideas like Totem can finally be built. There is still plenty to figure out, but we can now build things we could only talk about only a year back.

Cohort after cohort of experimenting taught us what works, what doesn't, and how to run the loop that keeps producing ideas like these. Nix and Blossom happened on a walk. Spending six weeks together gives people time to understand each other's work, try something unlikely, abandon it and try again.

But six weeks is a lot to ask. People have jobs they cannot leave and children in school. Some have spent twenty years finding out how systems fail in practice, and we would love to have them here. Wanting to come does not make it possible.

So alongside the six-week cohorts, we are exploring shorter formats. Maybe a week in a mountain hut, working on one question and building towards a demo.

People have also asked about cohorts in other parts of the world. We want to explore that and work with people building local-first hardware/software and mesh networks who might never have considered coming to SEC.

If six weeks is why you have never applied, tell us what you could make time for. If you want to help organise something where you live, come talk to us.

Closing notes

SEC-08 ran on participants going full tilt for six weeks with no breather, and on the captains: Arjen, Gsovereignty, Thomas, Sandwich, Johnathan and Gzuuus, who each steered the ship for a week and took it seriously. Thank you to Zaza for showing us that our work could look beautiful, to SuperPopLimon (nprofile…haqa) for the BBQs and Ponchas, to the ladies at the Cowork for hosting us, to andreloja (nprofile…kxan) for the space and dealing with the unglamorous parts of running Sovereign Engineering, and to Gigi (nprofile…tf6v) for the heart he keeps putting into this.

Head over to the projects page, pick something off this list. Try it, break it, go tell the person who made it. Then come build with us.

The pieces be scattered, laddies, but they be ours. Lash 'em together an' sail.

More: sovereignengineering.io | No Solutions