Atleast on a browser you can right click and inspect the code and networking. Can't say the same about native apps =]~

Yeah agree. It would have access to the same napps available on the web version, very cool.

I won't argue with the protocol creator: you win hahah I will just add that the choice of using relays was also based on a longer term goal of offering a local backup to all the user data and it will be easier to implement if everything is expected to be a Nostr event.

> [...] The other domains could always make it not use Github and re-prompt your nsec [...] I'm sure you know it but just to make it clear for future readers, the browser automatically isolates passkey storage (and storage in general) by domain. If 44billion.net changes the login iframe to a malicious url, the won't be there. Nothing bad happens per se.

Yes, these are good ideas. These features could be window.nostr.napp optional add-ons. Currently, each app handles its own ws connections and local storage as usual but the good thing is it can always consider there is always only one user, always the same one. No need to code for multi-user. While the 44billion.net is multi-user, the napp sees just one.

A bundle event is already part of the packaging. It references files by their MMR root hash. By using mmr, relays can be sure the publisher isn't lying about the number of chunks and that a chunk is exactly at x position. The chunk size is fixed. So relays can choose to block a chunk if its part of a huge file. Imho blossom isn't needed. Although relays specialized on storing big events could rise, the napp files tend to be so small that we write them to the publisher's outbox relays.

This platform is different. 1) The web app is loaded client side, doesn't touch the server 2) The nsec is handled by this github page https://github.com/44Billion/44b-vault, loaded on an iframe, that runs exactly the same open-source code on the repo. 44billion.net has no direct access to the nsec. It lives as a passkey on the device's secure element. Soon uses will be able to switch to their own 44b-vault fork.

I have to write it down. I'll release a CLI soon that handles packaging and upload, it is just missing some details already present when uploading through 44billion.net's napp store. It uses base93 for file chunks, the most efficient space-wise JSON-safe binary-to-text encoding. The chunks also carry Merkle Mountain Range tree proofs. I guess will love it cause its old NIP-95 on steroids

Known Issues: You won't be able to create an account if using Firefox, Safari < 18 or Bitwarden extension (https://github.com/bitwarden/clients/issues/12590) because they don't fully support passkeys. I don't have a recent Apple device to test on Safari >= 18.

Could it be possible to improve user retention by making Nostr web apps work **without** a browser extension? Help me test this vision by uploading your static (nostr) websites at https://44billion.net. Sign in/up then click on the (n)app icon with a big "N" (a Napp store) where you can upload them. Hint: Before uploading, you could add some code to your napps to support auto-login. You just need to get the logged-in user's pubkey on load by calling `const userPk = await window.nostr.peekPublicKey()`, which returns the pubkey without prompting the user.