👀 😳

Already found a few potential problems and edge cases, impressive

What models/application are you using to do that?

Claude Opus 4.6 and Claude Code in VSCode

claude code cli is better and stays ahead of the vscode plugin. plus a browser based IDE is way more wasted memory and cpu

hehe... the only thing that annoys me about the cli is i have to type backslash enter to make new lines. they still haven't got around to doing a ctrl-enter or shift-enter to make it more natural. and copypasta you end up with all these funny characters in the output. but that's about it for caveats. it's lighter, more featureful and faster. but then i don't generally use nonsense like react or angular or typescript if i can avoid it. i got it to build a tinygo -> browser javascript translator and you'll see the app soon when i finally finish the Marmot MLS messaging module in it, hopefully finally today. uses a novel architecture also, several independent service workers, offloading relay work and identity management work in separate kernel threads, the MLS state machine lives inside the signer. the rendering of kind 1 threads happens in 2 seconds and then the media loads, which is obviously as slow as the network delivery. and yes, i may just be a one man gps ;)

also, i can't recommend enough the use of playwright, or better, Selenium, for end to end UI flow tests. i just had claude working for 2.5 hours autonomously just before. selenium is my pick, because it works with firefox. i'm not even going to waste my time supporting chrome at this point, because of all the ridiculous obstacles on the signer extension which is not optional. chrome shop approval delays, and byzantine UI, took me 2 hours to get through it previously and that's utterly wasted time. firefox on mobile runs signer extensions too, no need for stupid bunkers like amber.

iOS app, ser

can run firefox there too, with the signer. the end. all these frameworks are just obstractions from actually delivering a usable application. including the native apps. same codebase, electron. end of story.

> ok, that's not quite right. but there is an answer to it that again saves you having multiple codebases: Yes, total obstraction. Multiple layers deep. Firefox on iOS cannot run any extensions at all. Apple's proprietary iOS extension system is incompatible with Firefox add-ons. The reason is structural: all iOS browsers must use Apple's WebKit engine, so Firefox for iOS is essentially a WebKit shell, not Gecko. The WebExtension APIs that NIP-07 signer extensions (nos2x, plebeian-signer, etc.) depend on simply don't exist in Firefox-on-iOS. Extensions built for Android Firefox or desktop Firefox do not work on the built-in iOS WebKit-based rendering framework. The DMA was supposed to fix this for the EU. It hasn't. Nearly two years after Apple shipped the BrowserEngineKit frameworks, zero browsers on iOS use alternative rendering engines. Apple's contract and technical restrictions make porting browser engines to iOS "as painful as possible" for browser vendors. Mozilla would need to maintain a separate EU-only Gecko build, abandon existing users of the WebKit version, and meet Apple's testing/security requirements while only being able to test on devices physically located in the EU. Nobody has taken this deal. So your options on iOS for a Nostr signer are: 1. Safari + a Safari Web Extension (if someone builds one, which is a different extension format entirely) 2. A native iOS Nostr client with built-in key management (Damus, Primal, etc.) 3. Orion browser, which has ported the WebExtension API to WebKit and supports Firefox extensions on iOS — this is actually the most interesting path for running a signer on an iPhone, assuming the NIP-07 APIs survive the port The third option is worth investigating. Orion is from Kagi. It's a small wooden horse snuck past Apple's walls while the big browsers argue about the gate. For sm3sh specifically, this means the mobile story on iOS probably can't rely on a browser extension signer at all. The edge-first SW architecture will need to handle key management internally on iOS, or integrate with a native iOS signing app via deep links / universal links / a custom URL scheme. Which is arguably more coherent anyway — depending on a browser extension for a critical security function on a platform that treats extensions as second-class citizens is itself an obstraction. > yay apple. but orion browser... but no. that's gonna be a whole can of worms itself. JESUS CHRIST AS IF YOU NEED TO BE REMINDED WHAT APPLE IS?