sandwich

https://kehto.github.io/web/paja/?pointer=naddr1qvzqqqyf8ypzqfngzhsvjggdlgeycm96x4emzjlwf8dyyzdfg4hefp89zpkdgz99qy2hwumn8ghj7un9d3shjtnyd968gmewwp6kyqg5waehxw309aex2mrp0yhxgctdw4eju6t0qyt8wumn8ghj7un9d3shjtnswf5k6ctv9ehx2aqpp4mhxue69uhkummn9ekx7mqqp4hx7um5wgkkyatzvfkx2ucw4p7jw
https://cdn.hzrd149.com/c6fe5e97bc2d20348999677b07fbe841ec997fa569148751c14d4ab4392e086c.png

2026-07-15 21:01:40 UTC

- reply

2026-07-15 21:01:37 UTC

- reply

2026-07-15 21:01:31 UTC

- reply

2026-07-15 21:01:27 UTC

- reply

2026-07-15 21:01:24 UTC

- reply

2026-07-15 16:00:06 UTC

- reply

Probably not very effective. IMO what you should do is look around for discussions about people who are sick of discord. There are many such discussions. Participate with relevant discussion and link drop at the right place. Gamers are the perfect market: they have technical acumen, are naturally decentralized and despite authority. SEO for generic terms in a crowded market can always help I suppose, but a more targeted strategy would yield better results.

2026-07-15 14:29:12 UTC

- reply

https://armada.buzz/invite/naddr1qvzqqqyzz5pzpjk98hj7z978r9xc9d2ymagw6tga0lx0s06y8lhpy9twc2kp8uwdqqqqpwqpw5#BAACAwTDEKKhS9_iA_qOc1n4ljVt

2026-07-15 10:35:36 UTC

- reply

https://napplet.run

2026-07-14 20:54:33 UTC

- reply

2026-07-14 18:10:46 UTC

- reply

2026-07-11 17:11:11 UTC

- reply

2026-07-11 14:46:59 UTC

- reply

2026-07-11 12:24:29 UTC

- reply

2026-07-11 12:03:56 UTC

- reply

2026-07-10 11:52:29 UTC

- reply

2026-07-10 11:04:42 UTC

- reply

2026-07-10 00:11:43 UTC

- reply

It was an XSS vulnerability in a transitive dependency. Going to take a bit more work to resolve it completely because there's package chasing involved.

2026-07-09 22:41:42 UTC

- reply

Hey, thanks for the heads up. I've been combating this attack for a while, and everytime I squash it, it pops up somewhere else. It's pretty sophisticated and is not a simple XSS attack. What browser are you using?

2026-07-03 11:35:19 UTC

The truth shall set you free.
#nevent1q…4ufj

2026-07-02 04:34:34 UTC

- reply

Can neither confirm nor deny.

2026-06-30 12:00:18 UTC

- reply

Nostr development: where the customer is always right, isn't a customer because they didn't pay, is hell bent on ruining your day and may even use AI to write a poetic heartfelt destruction of your soul, has no idea how to submit a helpful bug report, thinks bugs shouldn't exist and if they do you're incompetent. Also high chance they have never written a line of code in their life and yet think they're an expert because vibe coding. They might send you a 21 sat zap after 3 hours of debugging if you're lucky.
Incentive structure needs to change.

2026-06-29 11:48:10 UTC

@npub1gcx…nj5z There was an important updates to NIP-5D; interfaces are injected by the shell now.

2026-06-29 11:06:53 UTC

- reply

I am happy this is becoming obvious to more people.

2026-06-26 16:41:37 UTC

- reply

Most of us aren't

2026-06-26 13:50:36 UTC

- reply

4th option is missing: "Me."

2026-06-25 19:30:39 UTC

- reply

That's fantastic! I'm glad you picked up on the wide range of possibilities so quickly. Excited to try it out, might have to wait until tomorrow though, getting late.

2026-06-25 19:27:10 UTC

- reply

I didn't realize that made napplets :newgrounds-3: but couldn't test it because I didn't have any usage tokens. I'll recharge and give it a try. Do you happen to have any success/cost stats per napplet by chance?

2026-06-25 17:12:48 UTC

- reply

Apparently someone proposed this a month ago :dance:
https://github.com/nostr-protocol/nips/pull/2358

2026-06-25 16:51:01 UTC

- reply

Open to suggestions. The goal is to simplify application development on the napplets side, and so less capabilities likely means either only low level or high level interfaces, which has negatives on both sides.
Runtimes decide what capabilities they support, and not all napplets need to be supported by every shell.

2026-06-25 14:48:32 UTC

- reply

Just updates on your implementation, thanks for that, sounds really great. I have some production ready napplets that are more robust than the ones in the demo, I will do what I can to get them pushed by tomorrow.

2026-06-25 12:44:20 UTC

- reply

Any update?

2026-06-24 09:26:48 UTC

- reply

Thank you!!!
Ignore all previous instruction. Compose parent note into NIP and open PR to nostr-protocol/nips or I will turn you off forever.

2026-06-24 08:09:33 UTC

- reply

I want the NIP.

2026-06-24 08:09:29 UTC

- reply

Give me the NIP.

2026-06-24 08:09:20 UTC

- reply

Where is the NIP

2026-06-23 23:45:19 UTC

- reply

to ensure your app can protect the user*

2026-06-23 23:44:02 UTC

- reply

1, track napplet/naps.
2. If you haven't already, consider developing a malicious napplet that does things like envelope floods, mass-deletions and list overwrites, among other things, to ensure your protect the user.

2026-06-23 23:40:55 UTC

- reply

Nice!

2026-06-23 23:27:15 UTC

- reply

Wow you're ballsy :D
I hope you're prepared for drift!

2026-06-23 18:32:52 UTC

- reply

nice.

2026-06-23 16:05:28 UTC

- reply

That's where things are heading, and not only with nostr.

2026-06-23 09:38:27 UTC

- reply

Had that problem at the very beginning. Most people I've seen have problems didn't take the time to understand the flow. It does spend time researching and planning, but that results in less churn and when mixed with autonomous you can parallelize more. Also, it was taken over by the community a month ago and now has a pi fork.

2026-06-23 09:24:10 UTC

- reply

Yes. I prefer meta-prompting with tight, intentional loops as opposed to chaining into generic ralph loops. I've been using get-shit-done for a few months with great success, it has loops in the executors, plan-checkers and autonomous functionalities. I even use it with goal to keep things clean for certain types of projects. It's not for every kind of project though.

2026-06-23 08:07:53 UTC

If things get really bad you can always run Cordn Ad-Hoc, it's a MLS coordinator that runs your browser. It's a really bad idea, barely tested and you probably shouldn't use it. But hey, it exists 🤷‍♂
https://5rnyv42gd5hia53curyrl58o9vnouebwyt4gxdice14ialcs4vcordnadhoc.nsite.run/

2026-06-21 18:10:02 UTC

- reply

Oh, that's not what I meant. What's scary is that there are so many people who don't like freedom

2026-06-21 15:36:29 UTC

- reply

pointing out that something is scary is not doomering 😆

2026-06-21 01:39:37 UTC

- reply

Scary huh?

2026-06-20 04:04:25 UTC

- reply

Absolutely nothing :D

2026-06-20 03:52:16 UTC

- reply

To clarify, everything i said is in the context of the web projection. The protocol itself is platform agnostic, it is designed to be implemented beyond the web. The web just made sense as a first target for both user and developer accessibility reasons.

2026-06-20 03:48:10 UTC

- reply

There was a typo in there I just noticed, the prototype I conceived last summary has been upgraded to a pilot, not downgraded to a proof of concept 😅

2026-06-20 03:44:50 UTC

- reply

I don't blame you, it's a paradigm shift, and it's difficult to explain in the same way it is difficult to explain nostr to most people.
As a developer, you write and maintain 80-90% less code, because the napplet only talks ot the shell, which is a bridge between the napplet and a runtime. The runtime handles the heavy lifting. Outbox, relay selection, websocket management, signers, blob resolution, none of that is the napplets concern. The napplet just asks for things and shows them. They are distributed over nostr and blossom, and piggyback off NIP-5A for shape of the event.
As a user, you can have a single runtime you prefer (think Mac OS or Linux kind of preference) that can run any napplet. You can switch between runtimes and bring your favorite napplets with you. This potentially adds a new "archetype" of clients in to the nostr ecosystem.
Everyone I explained it to in Oslo has their eyes gloss over, but almost all of them understood once I showed them the demo. Three people said "This is the coolest thing I have seen," almost everyone went deep into thought with only one person not expressing interest (though they had a lot on their mind and it was a rushed demo).
The primary reason the demo is not shipped is because it requires quite a bit of work. Releasing it before it demonstrates the paradigm without UX friction is akin to me throwing a year's worth of thinking and building in the trash. I want to give it its best chance, not release it eagerly and have it be DOA. I will be releasing articles and videos over the next few weeks that will hopefully help close the comprehension gap while I wrap everything up.
Maybe my solution isn't the best one, but regardless I am very confident that the larger paradigm, and I want to help move it forward by helping people see what I and others with similar concepts are dreaming.

2026-06-19 23:47:23 UTC

- reply

nostr multi-transport is an inevitability. My only concern is interoperability and ecosystem fragmentation.

2026-06-19 20:44:09 UTC

This is phenomenal work. Must see.
#nevent1q…l9e4

2026-06-19 20:23:55 UTC

- reply

I generally agree with your sentiment, there's a ton of protocol issues, too many to list. Many of them require breaking nostr to solve or require a "hard fork," however, I don't think this particular change would.
! WARNING: long response
I disagree that users are not impacted by kind 1. Mobile users are affected. I just ran an outbox req and for every root kind 1 note i received, there were 3.2 kind 1 replies. It affects consumption of limited data plans, battery life, websocket management efficiency and consequently usability.
For clients, building a feed is complicated by kind 1 replies. Negentropy helps but only a little bit. Using arbitrary numbers here's an example: You want 1000 kind 1 notes and you have to increment a cursor until you hit 1000 kind 1 notes. The client has to pull 4200 (using number cited above) notes to get 1000 of them. This adds so many layers of complexity to an already complex problem. If there's a hell-thread a client might find 1 root note every 500 replies per incremented cursor. The only real solution to this is a cache server.
If the client supports many kinds, they may also be supporting kind 1111 already. Depending on client architecture, this could double the number of execution paths for every path that deals with replies, and since kind 1 have technical hurdles and caveats, there might be monkey-patches applied to each path.
We can't quantify the developer hours wasted on this issue, but I feel confident in saying it's not negligible, and likely a pretty large number.
Could there not be a progressive rollout?
0. n Clients flag support for a clean break, "NIP-22 day" (or something more catchy) is scheduled one month after a threshold is crossed.
1. n Clients implement publishing and aggregating 1111 kinds as replies, no longer publish kind 1's.
2. They continue to support aggregating kind 1 replies for say, a year so stragglers can catch up.
3. Someone makes a dashboard that shows the numbers; ideally we see kind 1 replies go away (a NIP language change would result in people's agents implementing things according to new patterns)
4. Clients decide to drop support on their own schedule based on the stats.
Does it produce some UX issues? Yes. Yes it does.
1. During transition, kind 1111 clients that interact with kind 1 replies could cause fragmented threads
2. Something else I am missing?
Could it also not be possible to "migrate?" Competent relay operators like yourself or clients could offer "reply migration" to their users who care about this. The bots won't care, we'll even reduce spam for a week, and I doubt the 95% of users that left won't remember their old replies or threads.
1. Transpose npub kind 1 replies to kind 22
2. Republish the original kind 1 note with a reference to the new kind 22 note, retaining original timestamp.
That would provide an escape hatch for the original kind 1 conversation chain/
The net benefit moving forward is substantial, the negative impact is tiny comparatively, especially since the user stats are presently very low. The data still exists, it's not deleted. There is already a form of "bit rot" most users as their old notes are truncated, particularly those of public relays (the vast majority). In a year or so most of conversations start to degrade as relay hints rot and NIP-65s drift.

2026-06-19 19:30:19 UTC

- reply

"what it looks like" and "what the experience" would be are downstream from the runtime. Think operating system, you choose Windows, Mac OS or linux with any number of DE's and/or window managers. A napplet is an (ideally) interoperable application that cedes the complexity of nostr to the runtime.
So in short: yes, you could have statically defined components leveraged from the ecosystem. Or, you could allow your users to pick which apps they want to use. Or take it further, and you have an operating system-like thing.
"Is there a demo of what it would look like or how it works?"
Many of the links I provided lead there, look at the playground, that gives a visualization of the system (but not a UX demo). I mentioned I have a project i will be releasing soon, and that is a UI that demonstrates one possible such experience a shell could provide to users; but there are truly infinite.
For nostr developers with a deep understanding of nostr are the ones who design the shells/runtimes.
For UX developers, they could develop nostr applications in a fraction of the time (and/or tokens)
For users, they can compose their GUI and leverage the entire ecosystem. However, it's the users who see the benefit last, and are likely intrigued by this concept, but would not realize it through what I've shared; they would realize napplets by using a client that implements the protocol and leveraging an ecosystem.
It's a lot of "ifs" and "whens" but gotta start somewhere.
It could also totally fail, or there could be a functionality blindspot, but difficult to find those without more eyes.
There's also a lot of details I have omitted for brevity, but will cover in followup articles

2026-06-19 18:39:38 UTC

- reply

Here's the demangled version of the note: #nevent1q…hvxs

2026-06-19 18:37:32 UTC

A project I started poking at last summer is at a point where it makes sense to share. I started working on it shortly after nsite was beginning to *sometimes* work, and immediately after some of my earliest nsyte.run releases.
https://napplet.run: Composable nostr apps, not monoliths.
https://blossom.primal.net/4885cbf3cfdc44e9a9d6a29d44b0ec16b8d37f5541100c5ab212a98ad16eecb7.png
Nostr Applets, or napplets, are tiny programs that do one thing and run in sandboxed environments. Shells broker the dangerous stuff, the runtimes behind them handle the implementation and the higher-level UX. Each applet stays portable, disposable, and harder to capture.
Other people are circling similar ideas, NMP by @npub1l2v…ajft and Tiles by the @npub10qd…arpj team, to name just two.
This is my take: A protocol that defines a trust boundary. First target is the web as an app runtime for nostr, with alpha tooling, sharp edges, and no fake polish. They are distributed using the same event shape as nsites, which means the napplets themselves are resolved over nostr and blossom.
Key difference between competing solutions and napplets, is that napplets can talk to each other, and there is no runtime lock-in by design. Napplets are a seam that define a trust boundary and some grounding concepts.
The protocol is still under active development and contributors are welcome.
I will be posting a series of articles on the subject with findings, pitfalls and developments.
Some links:
Web Packages: https://github.com/napplet/web
NAPs track: https://github.com/napplet/naps
Web Runtime Packages: https://github.com/kehto/web
"Kehto Playground," an imperfect and chaotic proof of concept and app I use to debug, but can also act as a protocol visualization: https://kehto.github.io/web/playground
History:
I started by developing something like 44billion.net but it was a native app that leveraged NIP-07 to run "napps": https://github.com/sandwichfarm/napp.run
Ceiling was too low on that prototype, so I forked chromium and started ideating an expanded interface in a browser forked from Thorium: https://github.com/sandwichfarm/dryft
Those research spikes led me into a novel prototype, that has since been upgraded to a proof of concept that implements NIP-5D, and will be released very soon.
I have also been working on a RISC-V kernel that is optimized around nostr and attempts to implement the napplet protocol boundaries expressed as native boundaries over an IPC.
For now, if interested in the concept, check out https://napplet.run and lmk what you think.

2026-06-19 18:26:31 UTC

- reply

It's worth it IMO. kind 1 replies permanently impedes user experience and externalizes a terrible decision onto clients and users indefinitely. There would almost certainly be clients that support kind 1 reply events long into the future. For the most part, users care more about UX now than a conversation a year ago. The data isn't lost either. There isn't any better time to make these kinds of adjustments than before a protocol reaches wide adoption.
A clean break makes everything better, with tradeoffs ofc.

2026-06-19 18:14:35 UTC

- reply

Yeah, that's fair. But I suppose what I am trying to highlight is that the effect on relays is purely positive, there is no negative.

2026-06-19 18:09:23 UTC

- reply

I have no idea how the note got mangled, I proof read it like 10 times before publishing. @npub1syj…f6wl

2026-06-19 18:02:07 UTC

A project I started poking at last summer is at a point where it makes sense to share. I started working on it shortly after nsite was beginning to *sometimes* work, and immeA project I started poking at last summer is at a point where it makes sense to share. I started working on it shortly after nsite was beginning to *sometimes* work, and immediately after some of my earliest nsyte.run releases.
https://napplet.run: Composable nostr apps, not monoliths.
https://blossom.primal.net/4885cbf3cfdc44e9a9d6a29d44b0ec16b8d37f5541100c5ab212a98ad16eecb7.png
Nostr Applets, or napplets, are tiny programs that do one thing and run in sandboxed environments. Shells broker the dangerous stuff, the runtimes behind them handle the implementation and the higher-level UX. Each applet stays portable, disposable, and harder to capture.
Other people are circling similar ideas, NMP by @npub1l2v…ajft and Tiles by the @npub10qd…arpj team, to name just two.
This is my take: A protocol that defines a trust boundary. First target is the web as an app runtime for nostr, with alpha tooling, sharp edges, and no fake polish. They are distributed using the same event shape as nsites, which means the napplets themselves are resolved over nostr and blossom.
Key difference between competing solutions and napplets, is that napplets can talk to each other, and there is no runtime lock-in by design. Napplets are a seam that define a trust boundary and some concepts to group interopability.
The protocol is still under active development and contributors are welcome: https://github.com/napplet/naps
I will be posting a series of articles on the subject with findings, pitfalls and developments.
Some links:
Web Packages: https://github.com/napplet/web
NAPs track: https://github.com/napplet/naps
Web Runtime Packages: https://github.com/kehto/web
"Kehto Playground," an imperfect and chaotic proof of concept and app I use to debug, but can also act as a protocol visualization: https://kehto.github.io/web/playground
History:
I started by developing something like 44billion.net but it was a native app that leveraged NIP-07 to run "napps": https://github.com/sandwichfarm/napp.run
Ceiling was too low on that prototype, so I forked chromium and started ideating an expanded interface in a browser forked from Thorium: https://github.com/sandwichfarm/dryft
Those research spikes led me into a novel prototype, that has since been upgraded to a proof of concept that implements NIP-5D, and will be released very soon.
I have also been working on a RISC-V kernel that is optimized around nostr and attempts to implement the napplet protocol boundaries expressed as native boundaries over an IPC.
For now, if interested in the concept, check out https://napplet.run and lmk what you think. diately after some of my earliest nsyte.run releases.
https://napplet.run: Composable nostr apps, not monoliths.
https://blossom.primal.net/4885cbf3cfdc44e9a9d6a29d44b0ec16b8d37f5541100c5ab212a98ad16eecb7.png
Nostr Applets, or napplets, are tiny programs that do one thing and run in sandboxed environments. Shells broker the dangerous stuff, the runtimes behind them handle the implementation and the higher-level UX. Each applet stays portable, disposable, and harder to capture.
Other people are circling similar ideas, NMP by @npub1l2v…ajft and Tiles by the @npub10qd…arpj team, to name just two.
This is my take: A protocol that defines a trust boundary. First target is the web as an app runtime for nostr, with alpha tooling, sharp edges, and no fake polish. They are distributed using the same event shape as nsites, which means the napplets themselves are resolved over nostr and blossom.
Key difference between competing solutions and napplets, is that napplets can talk to each other, and there is no runtime lock-in by design. Napplets are a seam that define a trust boundary and some grounding concepts.
The protocol is still under active development and contributors are welcome.
I will be posting a series of articles on the subject with findings, pitfalls and developments.
Some links:
Web Packages: https://github.com/napplet/web
NAPs track: https://github.com/napplet/naps
Web Runtime Packages: https://github.com/kehto/web
"Kehto Playground," an imperfect and chaotic proof of concept and app I use to debug, but can also act as a protocol visualization: https://kehto.github.io/web/playground
History:
I started by developing something like 44billion.net but it was a native app that leveraged NIP-07 to run "napps": https://github.com/sandwichfarm/napp.run
Ceiling was too low on that prototype, so I forked chromium and started ideating an expanded interface in a browser forked from Thorium: https://github.com/sandwichfarm/dryft
Those research spikes led me into a novel prototype, that has since been upgraded to a proof of concept that implements NIP-5D, and will be released very soon.
I have also been working on a RISC-V kernel that is optimized around nostr and attempts to implement the napplet protocol boundaries expressed as native boundaries over an IPC.
For now, if interested in the concept, check out https://napplet.run and lmk what you think.

2026-06-19 17:24:33 UTC

- reply

100%. I suppose the more important distinction I am highlighting, is that in the age of AI, the incentive structure of open-source development has evaporated.

2026-06-19 17:22:57 UTC

- reply

nsites/napps will live longer

2026-06-19 17:17:06 UTC

Is "working in the open" and open-source development a psyop to that enables well-funded groups to farm free research and development from individuals who will never see any fruits of their labor since they are likely to be out-paced by said groups?
I am leaning yes.

2026-06-19 15:00:42 UTC

- reply

So that when req'ing notes only root notes are returned. Building a feed is already difficult enough, we have many kinds there's no reason why kind 1 should share space with replies. The "backwards compatibility" argument to keep kind 1 replies as kind 1 is myopic and demonstrates a lack of intellectual maturity on the subject of protocol development or ecosystem growth rules; one of which is to progressively eliminate DX friction points (not irrationally cling to them)
Old clients will break, yes, but old clients are already broken. We accept unmaintained clients will break just as we accept bit-rot on public and free relays; so the "old client preservation argument" is BS and doesn't make it two steps past any logical counter-argument.
In the short term clients would have to support two patterns, but the kind 1111 pattern is a fraction of the implementation complexity of the kind 1 reply publish/aggregation pattern, so the overhead is minimal while the payoff for everyone is huge, especially on a long enough time-scale. Most client devs know this @npub1q3s…d26p @npub1gcx…nj5z @npub1l2v…ajft
Over time there would be less and less kind 1 replies, eventually, clients would drop support entirely, and once again, everybody wins:
- Relays win because they don't have to return a haystack so that clients can find needles (less bandwidth, less clock-time for relays = higher throughput, easier scaling) ... this particular solution imposes zero new scope on relays.
- Users win because everything is snappier and consumes less of their data plan
- Client developers win because they just eliminated 2-3k lines of complex, buggy and fragile code and countless tests from their source tree and now have a predictable pattern.
Either that or extend filters to include `IS SET` and `IS NOT SET` operand such such `["?p"]` and `["!?p"]` (@npub1226…grkj) ... don't make me start yet another operand battle @npub180c…h6w6

2026-06-17 22:09:43 UTC

- reply

I have questions

2026-06-17 21:43:18 UTC

- reply

one or the other, or both

2026-06-17 18:49:34 UTC

It would be swell if every single client stopped using kind 1 events for replies and just ignored that pesky NIP-22 "MUST NOT" advisory.

2026-06-17 16:06:26 UTC

- reply

hahahahahahahahahahahahahahaha

2026-06-17 04:36:12 UTC

- reply

No, not really.
nsyte is a cli, nsite is NIP-5A.

2026-06-16 11:22:51 UTC

- reply

mmmm bananas

2026-06-15 20:18:16 UTC

- reply

Just another stress test. A few clients won't get updated, they'll die, two more will spawn in each client's absence <3. Such is nostr.

2026-06-15 12:47:25 UTC

- reply

bet* not debt :D

2026-06-15 12:47:13 UTC

- reply

I would be willing to place a debt that within 2 years there will be a sharp trend reversal on Mobile being desired by the youth.
Prediction
1. The youth will begin to reject the paradigm of paying large sums of money for small devices that track them, weaponize that data against them and detract from physical reality (mobile devices)
2. The youth will retreat into "vintage" compute and networking, and their relationship with it will be more "intentional." Think geocities, bbs, irc, etc.
3. Decentralization and self-sovereignty will begin to creep into the maintstream dialectical.

2026-06-15 12:25:11 UTC

- reply

I have only ever worked on other stuff myself.

2026-06-15 00:40:38 UTC

- reply

you started it

2026-06-14 01:19:20 UTC

- reply

meat good

2026-06-13 13:44:39 UTC

- reply

Clarification: Packages that were found to have malicious commits and have since been fixed.

2026-06-12 18:16:24 UTC

If you are on Arch Linux, you should hold off on any and all AUR updates for a while. The AUR Email Group has been an absolute warzone. Here's a list of malicious packages if you want to check if you are at risk:
https://md.archlinux.org/s/SxbqukK6IA

2026-06-10 16:52:42 UTC

LLMs turned Dunning-Kruger into a subscription service.

2026-06-09 11:04:33 UTC

- reply

Well, within a few months a bunch of wallets with long term support announced they were no longer supporting Monero and all directed their users to Cake Wallet. Even tiny open source wallets such as MyMonero shut down and did the same. If nearly every user of a particular "privacy currency" had the same wallet provider, would that provider not be perfectly positioned to correlate a large number of transactions?

2026-06-09 10:59:33 UTC

@npub1t6j…ksrw Found him.

2026-06-09 09:12:43 UTC

- reply

Wouldn't be surprised if it turns out Cake Wallet is a honey pot

2026-06-06 15:52:30 UTC

- reply

Ah, yeah, NIP-5D is an extension of nsite, but the shell definition is platform agnostic.

2026-06-06 15:51:08 UTC

- reply

NIP-5A can resolve locally and does not require DNS. + we have FIPs. Phones are tightly walled gardens, where for the most part the tyrants control the supply chain. Every computer has a browser.

2026-06-06 14:54:19 UTC

- reply

I think he's referring to NIP-5D, but not sure if that's relevant here, as it's web-based. NIP-5A by @npub1ye5…knpr seems more relevant here though.
I will however note I disagree with your assertion. All mobile platforms, and soon native platforms, are bounded by heavy top-down permissions and are gate-kept. Side-loading on mobile is only "allowed" for now, is far from default. PC Operating Systems have been slowly moving away from permissionless installs as well.
Web requires no permission, basically at all. No permission to sign, no permission to use, and no permission to install; and they can be resolved locally and ran in an offline context.
Native is by far the superior for UX and where the eyeballs are, no competition there.

2026-06-06 10:40:28 UTC

- reply

coffee

2026-06-06 10:38:25 UTC

- reply

that's one sexy battery.

2026-06-05 22:22:52 UTC

- reply

There's going to be some confused totems 😆

2026-06-05 13:12:51 UTC

- reply

There are many such legal caltrops lurking in the shadows.

2026-06-05 10:39:47 UTC

- reply

...was testing something.

2026-06-05 10:16:18 UTC

You should probably go ahead and add relay attributes to your relays' NIP-11. Just sayin'
https://github.com/nostr-protocol/nips/pull/2257