I mean, take a website, remove all its html files and leave just the index.html one, remove all web apis like bluetooth and fetch and you get a napplet. Then reimplement these web apis you previously removed access to inside a parent website so to make them available to the napplet. Like... why? Before you pivoted it to nostr **web** applets it made more sense.

Replies (1)

"Remove APIs, then give them back” skips the crucial difference: who controls access. The shell uses existing browser APIs to provide shared services under per-napplet permissions. That lets users compose independent tools without granting each one direct access to everything. Not every API is proxied over the message bus, a shell can grant CSP and sandbox loosening via NAP-SHELL, though we have deferred this functionality in the early stages. It was one of the first capability contracts written, which you would know if you actually read the protocol. Your centralized gateways already introduce an intermediary that can inject app content. What justifies that trust dependency while making explicit capability mediation pointless? You say it doesn't make sense, but every time I see you write something about napplets, it is false. If napplets don't make sense, then why did napplets garner more developer support in one afternoon than 44b has in a year? Consider understanding a topic before spreading lies about it. View article →
↑