applesauce v7 is impossibly fast.

More lies about napplets from those who have clearly never read the protocol. View quoted note → Some background: I have contributed to nsites almost since the beginning, I am one of the first developers for it, helped shape the NIP, helped get the NIP adopted, was the one who popularized both versions of the spec, was the one who chased everyone down and got them to update their implementations when V2 rolled out and still maintain the most popular nsite tooling to this day. I love nsites, but that does not mean they are without problems: 1. Gateways can inject whatever they want into nsites, and by extension napps. It is not possible with popular browsers to verify that the content served by the gateway are the same hash as the blobs requested. This would be like having a checksum for `bitcoind` you are not able to verify. 2. Launchers like 44billion.net address this clear flaw by only supporting their own gateway: IE Centralization. Does nobody remember why we are here to begin with? 3. You can move this all native, but then the adoption strategy falls apart. The beauty behind nsites is the ability to share something quickly, without a download, so once this pivot is required for secure access the beauty begins to fade. These realities make nsites unideal for any task related to identity or handling sensitive material. By trusting a gateway, you are trusting it to not inject malicious code or extract information. nsites are still well-suited for read only or nostr-adjacent implementations with limited reach. It is not by accident or some subjectivity of mine that napplets are what they are. napplets are at this point the result 16 months of evidence-based R&D, from some of nostr's most prolithic developers. Unlike detractors, it is not funded by an American NGO but by our love for the nostr protocol. It's not based on vague philosophical objectivity about what "simplicity" means. It is informed by the design of kernels and previous attempts at sandboxed applications. 1. Napplets don't use gateways, the shell pulls a single blob from a blossom server and verifies it. 2. The single-file is a "positive incentivization loop," not a weakness. By putting everything in a single file, developers are incentivized to optimize their applications. They are incentivized to limit bloat, and to be concise. This is good for everyone, especially users. 3. Web APIs are where the majority of vulnerabilities in browsers occur. The misconception that napplets add "needless complexity" is not an argument against napplets, but an admission of ignorance about web technologies. The complexity is removed where it matters: For the app developers. The security exists where it matters: For the user and their data. Protocol intelligence is exercised where it should be: Behind a shell. 4. napplets work equally as well in the browser as they do native. This is an intentional design decision, not an irrational personal subjectivity. Over the last 2+ decades, Browsers have evolved around and for the TLS, client-server paradigm. It is this paradigm that nostr challenges. It is for this reason why we face so much resistence with nostr in the browser: it's designed on assumptions nostr inherently rejects. napplets are informed by this understanding, with as few compromises as possible, and in the interest of the user. If you want to understand the decision path behind napplets, I wrote an article: View article →

napplet shell examples from Applesauce v7

Applesauce Examples