Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V7laf-0000xV-7e for bitcoin-development@lists.sourceforge.net; Fri, 09 Aug 2013 12:14:45 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.43 as permitted sender) client-ip=209.85.219.43; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f43.google.com; Received: from mail-oa0-f43.google.com ([209.85.219.43]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1V7lab-0003Fa-OG for bitcoin-development@lists.sourceforge.net; Fri, 09 Aug 2013 12:14:45 +0000 Received: by mail-oa0-f43.google.com with SMTP id i10so6853578oag.30 for ; Fri, 09 Aug 2013 05:14:36 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.95.198 with SMTP id dm6mr295887oeb.44.1376050476339; Fri, 09 Aug 2013 05:14:36 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.84.231 with HTTP; Fri, 9 Aug 2013 05:14:36 -0700 (PDT) In-Reply-To: References: <54F09675-D6A7-4415-82F1-920248E8188D@grabhive.com> Date: Fri, 9 Aug 2013 14:14:36 +0200 X-Google-Sender-Auth: 0zeyDVz2mt88_mOf_6LY5oVqNSY Message-ID: From: Mike Hearn To: Wendell Content-Type: multipart/alternative; boundary=089e011606f4d5dcd804e382b78d X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1V7lab-0003Fa-OG Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] SPV client in pure JavaScript? X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 12:14:45 -0000 --089e011606f4d5dcd804e382b78d Content-Type: text/plain; charset=UTF-8 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. >> > > --089e011606f4d5dcd804e382b78d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Oh, I forgot to make it clear - Chrome apps/extensions can= make raw TCP socket connections:


You would do it as a packaged app:=C2=A0http://developer.chro= me.com/apps/about_apps.html=C2=A0 because then they're a lot more s= imilar to native apps (they get their own windows, run offline, etc).=C2=A0=

But these aren't standard APIs. They're all Chr= ome extensions. I doubt HTML5 will support USB access anytime soon, for ins= tance, but packaged apps do.



On Fri, Aug 9, 2013 at 2:10 PM, Mike Hea= rn <mike@plan99.net> wrote:
Code that runs inside NativeClient has the same access lev= el as JavaScript does. It's just a way to do things faster.

Distribution as a Chrome app via the Chrome store is a fine approac= h, as long as people understand it's just an app platform like any othe= r. It has pros and cons that must be weighed up. For instance, Chrome for m= obile 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 <w@g= rabhive.com> wrote:
Right, I'm not suggesting that we have this wallet in a web app, but ra= ther precisely what you are talking about: using special browser features, = and bundling it. I am fundamentally monoculture-opposed, but given Chrome&#= 39;s present installed base, that initial target makes sense to me, provide= d that we could have a one-click installation (as per normal, via the Chrom= e Store).

Chrome also has this "Native Client" plug-in: I know next to noth= ing about it, and this goes off the rails of the Subject, but perhaps an SP= V implementation there could be a solution to the concerns you expressed?
On Aug 9, 2013, at 1:48 PM, Mike Hearn wrote:

> JavaScript is turing complete so of course it can be done. The real qu= estion you're asking is, can it be done in a web app? I think the answe= r 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 li= ke 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 us= ers 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&qu= ot; Chrome into a regular-looking application.
>
> I personally wouldn't find such a design compelling. Whilst Java i= sn't exactly a great language, JavaScript is significantly worse in vir= tually all aspects. I don't understand why anyone would want to use Jav= aScript 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.


--089e011606f4d5dcd804e382b78d--