{"type":"rich","version":"1.0","title":"sandwich wrote","author_name":"sandwich (npub1ua…q99rx)","author_url":"https://nostr.now/npub1uac67zc9er54ln0kl6e4qp2y6ta3enfcg7ywnayshvlw9r5w6ehsqq99rx","provider_name":"njump","provider_url":"https://nostr.now","html":"\"Remove APIs, then give them back” skips the crucial difference: who controls access. \n\nThe 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.\n\nYour centralized gateways already introduce an intermediary that can inject app content. What justifies that trust dependency while making explicit capability mediation pointless?\n\nYou 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? \n\nConsider understanding a topic before spreading lies about it. \n\nnostr:naddr1qvzqqqr4gupzpem34u9stj8ftlxldl4n2qz5f5hmrnxns3uga86fpwe7u28ga4n0qythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0qyt8wumn8ghj7un9d3shjtnyd968gmewwp6kytcqz44x7e2tgfs5xer9x4455upefag85s2p94pq0eqrac"}