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; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <CANEZrP24P_m_eWbcs3PJNomG4kFDPUyGE2uQjod9qPmpBS+1mg@mail.gmail.com>
References: <B4D8D241-E758-4806-8B12-C9A78BF1470B@grabhive.com>
	<CANEZrP2c6nsf2z5_hKDfHdO1HEJ+Y+aoiSdfYPMxK_jzrvLEow@mail.gmail.com>
	<54F09675-D6A7-4415-82F1-920248E8188D@grabhive.com>
	<CANEZrP24P_m_eWbcs3PJNomG4kFDPUyGE2uQjod9qPmpBS+1mg@mail.gmail.com>
Date: Fri, 9 Aug 2013 14:14:36 +0200
Message-ID: <CANEZrP1XYyO0aspJ-A-0+_pRDKrtaHZrNTjfOnxBGX8Beiw2Xw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Wendell <w@grabhive.com>
Content-Type: multipart/alternative; boundary=089e011606f4d5dcd804e382b78d
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] SPV client in pure JavaScript?
Precedence: list

--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 <mike@plan99.net> 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 <w@grabhive.com> 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

<div dir=3D"ltr">Oh, I forgot to make it clear - Chrome apps/extensions can=
 make raw TCP socket connections:<div><br></div><div>=C2=A0 =C2=A0<a href=
=3D"http://blog.chromium.org/2012/11/introducing-tcp-listen-new-api-for.htm=
l">http://blog.chromium.org/2012/11/introducing-tcp-listen-new-api-for.html=
</a><br>
</div><div><br></div><div>You would do it as a packaged app:=C2=A0<a href=
=3D"http://developer.chrome.com/apps/about_apps.html">http://developer.chro=
me.com/apps/about_apps.html</a>=C2=A0 because then they&#39;re a lot more s=
imilar to native apps (they get their own windows, run offline, etc).=C2=A0=
</div>
<div><br></div><div>But these aren&#39;t standard APIs. They&#39;re all Chr=
ome extensions. I doubt HTML5 will support USB access anytime soon, for ins=
tance, but packaged apps do.</div><div><br></div></div><div class=3D"gmail_=
extra">
<br><br><div class=3D"gmail_quote">On Fri, Aug 9, 2013 at 2:10 PM, Mike Hea=
rn <span dir=3D"ltr">&lt;<a href=3D"mailto:mike@plan99.net" target=3D"_blan=
k">mike@plan99.net</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">Code that runs inside NativeClient has the same access lev=
el as JavaScript does. It&#39;s just a way to do things faster.<div><br></d=
iv><div>Distribution as a Chrome app via the Chrome store is a fine approac=
h, as long as people understand it&#39;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&#39;t really do apps, at least not at the moment. Also, you&#39=
;re still limited by what APIs Chrome exposes, which are a strict subset of=
 what a real OS provides.</div>

</div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><b=
r><br><div class=3D"gmail_quote">On Fri, Aug 9, 2013 at 2:05 PM, Wendell <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:w@grabhive.com" target=3D"_blank">w@g=
rabhive.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Right, I&#39;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).<br>


<br>
Chrome also has this &quot;Native Client&quot; 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?<b=
r>


<div><br>
-wendell<br>
<br>
<a href=3D"http://grabhive.com" target=3D"_blank">grabhive.com</a> | <a hre=
f=3D"http://twitter.com/grabhive" target=3D"_blank">twitter.com/grabhive</a=
> | gpg: 6C0C9411<br>
<br>
</div><div><div>On Aug 9, 2013, at 1:48 PM, Mike Hearn wrote:<br>
<br>
&gt; JavaScript is turing complete so of course it can be done. The real qu=
estion you&#39;re asking is, can it be done in a web app? I think the answe=
r is I think &quot;no&quot; because web apps aren&#39;t allowed to make raw=
 TCP socket connections.<br>


&gt;<br>
&gt; Now there may be a way around that by using browser-specific things li=
ke extensions or &quot;installable apps&quot; 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&#39;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&#39;t know of a convenient way to &quot;statically link&qu=
ot; Chrome into a regular-looking application.<br>


&gt;<br>
&gt; I personally wouldn&#39;t find such a design compelling. Whilst Java i=
sn&#39;t exactly a great language, JavaScript is significantly worse in vir=
tually all aspects. I don&#39;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=
&#39;s using languages/platforms designed for it.<br>


</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--089e011606f4d5dcd804e382b78d--