Oh, I forgot to make it clear - Chrome apps/extensions can make raw TCP socket connections: http://blog.chromium.org/2012/11/introducing-tcp-listen-new-api-for.html You would do it as a packaged app: http://developer.chrome.com/apps/about_apps.html because then they're a lot more similar to native apps (they get their own windows, run offline, etc). But these aren't standard APIs. They're all Chrome extensions. I doubt HTML5 will support USB access anytime soon, for instance, but packaged apps do. On Fri, Aug 9, 2013 at 2:10 PM, Mike Hearn wrote: > Code that runs inside NativeClient has the same access level as JavaScript > does. It's just a way to do things faster. > > Distribution as a Chrome app via the Chrome store is a fine approach, as > long as people understand it's just an app platform like any other. It has > pros and cons that must be weighed up. For instance, Chrome for mobile > doesn't really do apps, at least not at the moment. Also, you're still > limited by what APIs Chrome exposes, which are a strict subset of what a > real OS provides. > > > On Fri, Aug 9, 2013 at 2:05 PM, Wendell wrote: > >> Right, I'm not suggesting that we have this wallet in a web app, but >> rather precisely what you are talking about: using special browser >> features, and bundling it. I am fundamentally monoculture-opposed, but >> given Chrome's present installed base, that initial target makes sense to >> me, provided that we could have a one-click installation (as per normal, >> via the Chrome Store). >> >> Chrome also has this "Native Client" plug-in: I know next to nothing >> about it, and this goes off the rails of the Subject, but perhaps an SPV >> implementation there could be a solution to the concerns you expressed? >> >> -wendell >> >> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 >> >> On Aug 9, 2013, at 1:48 PM, Mike Hearn wrote: >> >> > JavaScript is turing complete so of course it can be done. The real >> question you're asking is, can it be done in a web app? I think the answer >> is I think "no" because web apps aren't allowed to make raw TCP socket >> connections. >> > >> > Now there may be a way around that by using browser-specific things >> like extensions or "installable apps" which give your code greater access >> permissions. This approach means you essentially use Chrome as your app >> platform instead of a JVM, the assumption presumably being that more users >> have Chrome than a JVM. The flip side is that users who don't would >> probably balk at the idea of installing an entire browser in order to run a >> wallet app, whereas a JVM can be bundled and the resulting app acts like >> any other. I don't know of a convenient way to "statically link" Chrome >> into a regular-looking application. >> > >> > I personally wouldn't find such a design compelling. Whilst Java isn't >> exactly a great language, JavaScript is significantly worse in virtually >> all aspects. I don't understand why anyone would want to use JavaScript >> outside the browser - you get less safety, less performance, fewer >> features, less mature tools and so on. If the end result is an installable >> app like any other, all you did is cripple yourself vs the competition >> that's using languages/platforms designed for it. >> > >