<oembed><type>rich</type><version>1.0</version><title>sandwich wrote</title><author_name>sandwich (npub1ua…q99rx)</author_name><author_url>https://nostr.now/npub1uac67zc9er54ln0kl6e4qp2y6ta3enfcg7ywnayshvlw9r5w6ehsqq99rx</author_url><provider_name>njump</provider_name><provider_url>https://nostr.now</provider_url><html>&#34;Remove APIs, then give them back” skips the crucial difference: who controls access. &#xA;&#xA;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.&#xA;&#xA;Your centralized gateways already introduce an intermediary that can inject app content. What justifies that trust dependency while making explicit capability mediation pointless?&#xA;&#xA;You say it doesn&#39;t make sense, but every time I see you write something about napplets, it is false. If napplets don&#39;t make sense, then why did napplets garner more developer support in one afternoon than 44b has in a year? &#xA;&#xA;Consider understanding a topic before spreading lies about it. &#xA;&#xA;nostr:naddr1qvzqqqr4gupzpem34u9stj8ftlxldl4n2qz5f5hmrnxns3uga86fpwe7u28ga4n0qythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0qyt8wumn8ghj7un9d3shjtnyd968gmewwp6kytcqz44x7e2tgfs5xer9x4455upefag85s2p94pq0eqrac</html></oembed>