Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1Uyp4G-0002lt-Do
	for bitcoin-development@lists.sourceforge.net;
	Mon, 15 Jul 2013 20:08:20 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.50 as permitted sender)
	client-ip=209.85.219.50; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f50.google.com; 
Received: from mail-oa0-f50.google.com ([209.85.219.50])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Uyp4E-0002as-E7
	for bitcoin-development@lists.sourceforge.net;
	Mon, 15 Jul 2013 20:08:20 +0000
Received: by mail-oa0-f50.google.com with SMTP id k7so16456580oag.9
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 15 Jul 2013 13:08:13 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.97.200 with SMTP id ec8mr44112854oeb.33.1373918892949;
	Mon, 15 Jul 2013 13:08:12 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.23.36 with HTTP; Mon, 15 Jul 2013 13:08:12 -0700 (PDT)
Received: by 10.76.23.36 with HTTP; Mon, 15 Jul 2013 13:08:12 -0700 (PDT)
In-Reply-To: <3E7894A0-06F3-453D-87F8-975A244EBACF@include7.ch>
References: <B87F1213-5BD8-43F5-9744-F69947561ED5@grabhive.com>
	<CANEZrP2xh=m8yWLt-o2UrrUVfU+cUYBuMVxkVFF5mVMtWdRwOQ@mail.gmail.com>
	<C1727B41-AF61-44FA-BE17-5FE4425FDEA8@grabhive.com>
	<CANEZrP0_H9+prDSF92q8a4QzP=fzDM6cTDv0+KcfV9NF9thkmw@mail.gmail.com>
	<3E7894A0-06F3-453D-87F8-975A244EBACF@include7.ch>
Date: Mon, 15 Jul 2013 22:08:12 +0200
X-Google-Sender-Auth: -ZENEvDpmtbvJ3Mtx4RS9Q7xUNE
Message-ID: <CANEZrP2jmWkDbpJEm0vd2CKF-prFNbz_ZeNJfDWtSCKb8k5ZXA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jonas Schnelli <jonas.schnelli@include7.ch>
Content-Type: multipart/alternative; boundary=089e0115f34e90907c04e1926bc8
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: 1Uyp4E-0002as-E7
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Introducing BitcoinKit.framework
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 20:08:20 -0000

--089e0115f34e90907c04e1926bc8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

You can cut down the JVM to be a few megabytes if you're aggressive about
it. But for a desktop app I'm not sure it's really necessary these days. A
few megabytes used to make a noticeable difference to success rates but
bandwidth improved a lot since then.

Portability to android is a given, it's already Java based. IOS is a non
starter until apple is convinced to allow wallet apps into the App store,
language is not the issue there.

There is no point manually rewriting bitcoinj to c++ when j2c does such a
great job already. You would want to at last start from what it generates
even if you fork from there.
On 15 Jul 2013 20:19, "Jonas Schnelli" <jonas.schnelli@include7.ch> wrote:

> The embedded JVM is a way. But the binary will be huge.
> And how about the portability (like iOS and Android)?
>
> If i would have "unlimited resources" and like to make a "perfect native
> client" i would see two solutions:
> a) add SPV features to bitcoind and go on with BitcoinKit.framework (mayb=
e
> first SPV features are only available through "API's" and not for bitcoin=
d
> as runnable binary)
> b) rewrite bitcoinj in c++ (*auto-port the unit-tests* and try to rewrite
> line by line to c++)
>
> also a mix of a) and b) is possible. Like extending bitcoind with the
> SPVBlockstore, bloom filter, etc. from bitcoinj (rewritten in c++). The
> wallet birthday must also be added somehow.
>
> both a) and b) (or the mix) is a lot of work and might take much longer a=
s
> Mike's JVM idea.
> But it then might end up in a stable, portable and extendable pice of cod=
e.
>
> </jonas>
>
>
>
> Oracle provide an OSX JVM and will do so for the forseeable future, it's
> also open source, so the community could carry on if they stopped. The
> primary problem with the Oracle JVM is lack of retina support for Swing,
> but if you'd write a Cocoa UI yourself then it doesn't matter of course a=
s
> Java won't handle any GUI stuff. Retina support for JavaFX2 (the
> current-gen gui toolkit) is available in Java 8 so it's definitely being
> actively developed, it's not abandoned or anything.
>
> So the question then becomes, which is better:
>
> a) Take bitcoinj completely out of the Java world via native compilation
> or transpilation to C++
> b) Embed the JVM and link the two worlds together?
>
> (b) is much less ambitious, especially if you're OK with writing a bit of
> Java code to keep the interface thin. Basically the Java side calls into
> your app when interesting user-visible things happen, like new transactio=
ns
> appearing, then your GUI can call into the java side to send money. There
> are auto-translators that make the glue work easy, like
> https://code.google.com/p/javacpp/. You probably wouldn't want to expose
> the entire bitcoinj API that way because it's very large, but the code
> needed to bring up a wallet app is very small. I knocked one up this
> weekend in about one evenings worth of coding, completed with nice
> animations. The interfaces you'd need are basically some Objective-C++
> methods that receive information from the Bitcoin side, like the balance
> having changed, a list of transactions, etc, and then a callback into the
> Java side to send money. If you look at the javacpp site you can see
> example code for making calls both ways.
>
> If I were in your shoes, I'd go for (b) because it is the most well
> trodden path and will let you achieve the best user visible results
> quickly. The JVM can be bundled with your app and stripped down if you're
> worried about download size.
>
> If it's unclear how the code would look, let me know and I'll try and
> knock up a really simple prototype.
>
> There's also (a). I'm investigating transpilation for a few reasons, one
> of which is to do with a private project. I'm working with the author of
> j2c: https://code.google.com/a/eclipselabs.org/p/j2c/. It's a rather
> sophisticated transpiler that converts Java to clean, readable C++11 that
> looks much like code a human would write. It's complete enough to transpi=
le
> the entire standard Java class library, including all the GUI toolkits an=
d
> other things - so, pretty amazing piece of code. However it's incomplete
> because where the Java code calls native methods (that would be provided =
by
> the JVM) it just spits out stubs you're expected to fill out yourself, fo=
r
> starting threads and so on. As there's no JVM it's just like using a C++
> library that is missing a "portability layer".
>
> I'm working on this myself and don't really need much help at the moment,
> I'm just making steady progress towards getting something up and running.=
 I
> can let you know once I reach some interesting milestones. The point of
> this is that whilst you don't need access to most of the API to write a
> wallet app, I'd like to make every kind of app easy from C++, not just GU=
I
> wallets. Then the compile-to-C++ approach is much more appealing, even
> though it's also more work.
>
>
>
>
>
> On Mon, Jul 15, 2013 at 4:39 PM, Wendell <w@grabhive.com> wrote:
>
>> Hi Mike,
>>
>> You are absolutely right about the synchronize time, it's one of our mai=
n
>> frustration points right now and we clearly won't deliver the kind of us=
er
>> experience we want, without fixing this. Actually we were thinking of
>> extending Jeff Garzik's picocoin as time permits, but the plan is far fr=
om
>> concrete at the moment.
>>
>> What you say about trans-piling bitcoinj is _really_ appealing. We
>> discounted Java simply because an OS X JVM is no longer guaranteed, but
>> otherwise bitcoinj is ideal for our purposes. How can we assist or
>> otherwise accelerate such an effort?
>>
>> -w
>>
>> On Jul 15, 2013, at 3:19 PM, Mike Hearn wrote:
>>
>> > That's great! I'm all for more wallets, especially user friendly UIs.
>> >
>> > However being based on bitcoind means it will take a very long time to
>> synchronize for new users. We know a lot of users drop out. The best fix
>> for this is SPV mode. Do you have any plans in this direction?
>> >
>> > So far, the only SPV mode implementation I know about is bitcoinj. I a=
m
>> experimenting with trans-piling bitcoinj to C++ to make it usable from
>> Objective-C++ exactly with your use case in mind.
>>
>>
>
> -------------------------------------------------------------------------=
-----
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
>
> http://pubads.g.doubleclick.net/gampad/clk?id=3D48808831&iu=3D/4140/ostg.=
clktrk_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> =C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=
=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=
=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=
=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=
=B0
> include7 AG
> Jonas Schnelli
> Mattengasse 27
> CH-8005 Z=C3=BCrich
> Switzerland
> Office: +41 44 500 16 70
>
> Mail: jonas.schnelli@include7.ch
> Web: www.include7.ch
> V-Card: www.include7.ch/js.vcf
> =C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=
=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=
=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=
=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=
=B0
>
> ACHTUNG
> Bitte senden sie uns keine sensitiven Daten in unverschl=C3=BCsselten E-M=
ails.
> Verwenden Sie hierzu folgenden Link:
> https://include7.ch/contact/secureform
>
> =C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=
=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=
=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=
=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=
=B0
>
>

--089e0115f34e90907c04e1926bc8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">You can cut down the JVM to be a few megabytes if you&#39;re=
 aggressive about it. But for a desktop app I&#39;m not sure it&#39;s reall=
y necessary these days. A few megabytes used to make a noticeable differenc=
e to success rates but bandwidth improved a lot since then.</p>

<p dir=3D"ltr">Portability to android is a given, it&#39;s already Java bas=
ed. IOS is a non starter until apple is convinced to allow wallet apps into=
 the App store, language is not the issue there.</p>
<p dir=3D"ltr">There is no point manually rewriting bitcoinj to c++ when j2=
c does such a great job already. You would want to at last start from what =
it generates even if you fork from there.</p>
<div class=3D"gmail_quote">On 15 Jul 2013 20:19, &quot;Jonas Schnelli&quot;=
 &lt;<a href=3D"mailto:jonas.schnelli@include7.ch">jonas.schnelli@include7.=
ch</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style=3D"word-wrap:break-word"><div>The embedded JVM is a way. But the=
 binary will be huge.</div><div>And how about the portability (like iOS and=
 Android)?</div><div><br></div><div>If i would have &quot;unlimited resourc=
es&quot; and like to make a &quot;perfect native client&quot; i would see t=
wo solutions:</div>
<div>a) add SPV features to bitcoind and go on with=C2=A0BitcoinKit.framewo=
rk (maybe first SPV features are only available through &quot;API&#39;s&quo=
t; and not for bitcoind as runnable binary)</div><div>b) rewrite bitcoinj i=
n c++ (<b>auto-port the unit-tests</b> and try to rewrite line by line to c=
++)</div>
<div><br></div><div>also a mix of a) and b) is possible. Like extending bit=
coind with the SPVBlockstore, bloom filter, etc. from bitcoinj (rewritten i=
n c++). The wallet birthday must also be added somehow.</div><div><br></div=
>
<div>both a) and b) (or the mix) is a lot of work and might take much longe=
r as Mike&#39;s JVM idea.</div><div>But it then might end up in a stable, p=
ortable and extendable pice of code.</div><div><br></div><div>&lt;/jonas&gt=
;</div>
<div><br></div><br><div><br><blockquote type=3D"cite"><div dir=3D"ltr">Orac=
le provide an OSX JVM and will do so for the forseeable future, it&#39;s al=
so open source, so the community could carry on if they stopped. The primar=
y problem with the Oracle JVM is lack of retina support for Swing, but if y=
ou&#39;d write a Cocoa UI yourself then it doesn&#39;t matter of course as =
Java won&#39;t handle any GUI stuff. Retina support for JavaFX2 (the curren=
t-gen gui toolkit) is available in Java 8 so it&#39;s definitely being acti=
vely developed, it&#39;s not abandoned or anything.<div>

<br></div><div>So the question then becomes, which is better:</div><div><br=
></div><div>a) Take bitcoinj completely out of the Java world via native co=
mpilation or transpilation to C++</div><div>b) Embed the JVM and link the t=
wo worlds together?</div>

<div><br></div><div>(b) is much less ambitious, especially if you&#39;re OK=
 with writing a bit of Java code to keep the interface thin. Basically the =
Java side calls into your app when interesting user-visible things happen, =
like new transactions appearing, then your GUI can call into the java side =
to send money. There are auto-translators that make the glue work easy, lik=
e=C2=A0<a href=3D"https://code.google.com/p/javacpp/" target=3D"_blank">htt=
ps://code.google.com/p/javacpp/</a>. You probably wouldn&#39;t want to expo=
se the entire bitcoinj API that way because it&#39;s very large, but the co=
de needed to bring up a wallet app is very small. I knocked one up this wee=
kend in about one evenings worth of coding, completed with nice animations.=
 The interfaces you&#39;d need are basically some Objective-C++ methods tha=
t receive information from the Bitcoin side, like the balance having change=
d, a list of transactions, etc, and then a callback into the Java side to s=
end money. If you look at the javacpp site you can see example code for mak=
ing calls both ways.</div>

<div><br></div><div>If I were in your shoes, I&#39;d go for (b) because it =
is the most well trodden path and will let you achieve the best user visibl=
e results quickly. The JVM can be bundled with your app and stripped down i=
f you&#39;re worried about download size.=C2=A0</div>

<div><br></div><div>If it&#39;s unclear how the code would look, let me kno=
w and I&#39;ll try and knock up a really simple prototype.</div><div><br></=
div><div>There&#39;s also (a). I&#39;m investigating transpilation for a fe=
w reasons, one of which is to do with a private project. I&#39;m working wi=
th the author of j2c:=C2=A0<a href=3D"https://code.google.com/a/eclipselabs=
.org/p/j2c/" target=3D"_blank">https://code.google.com/a/eclipselabs.org/p/=
j2c/</a>. It&#39;s a rather sophisticated transpiler that converts Java to =
clean, readable C++11 that looks much like code a human would write. It&#39=
;s complete enough to transpile the entire standard Java class library, inc=
luding all the GUI toolkits and other things - so, pretty amazing piece of =
code. However it&#39;s incomplete because where the Java code calls native =
methods (that would be provided by the JVM) it just spits out stubs you&#39=
;re expected to fill out yourself, for starting threads and so on. As there=
&#39;s no JVM it&#39;s just like using a C++ library that is missing a &quo=
t;portability layer&quot;.</div>

<div><br></div><div>I&#39;m working on this myself and don&#39;t really nee=
d much help at the moment, I&#39;m just making steady progress towards gett=
ing something up and running. I can let you know once I reach some interest=
ing milestones. The point of this is that whilst you don&#39;t need access =
to most of the API to write a wallet app, I&#39;d like to make every kind o=
f app easy from C++, not just GUI wallets. Then the compile-to-C++ approach=
 is much more appealing, even though it&#39;s also more work.</div>

<div><br></div><div><br></div><div><br></div></div><div class=3D"gmail_extr=
a"><br><br><div class=3D"gmail_quote">On Mon, Jul 15, 2013 at 4:39 PM, Wend=
ell <span dir=3D"ltr">&lt;<a href=3D"mailto:w@grabhive.com" target=3D"_blan=
k">w@grabhive.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">Hi Mike,<br>
<br>
You are absolutely right about the synchronize time, it&#39;s one of our ma=
in frustration points right now and we clearly won&#39;t deliver the kind o=
f user experience we want, without fixing this. Actually we were thinking o=
f extending Jeff Garzik&#39;s picocoin as time permits, but the plan is far=
 from concrete at the moment.<br>


<br>
What you say about trans-piling bitcoinj is _really_ appealing. We discount=
ed Java simply because an OS X JVM is no longer guaranteed, but otherwise b=
itcoinj is ideal for our purposes. How can we assist or otherwise accelerat=
e such an effort?<br>


<span><font color=3D"#888888"><br>
-w<br>
</font></span><div><div><br>
On Jul 15, 2013, at 3:19 PM, Mike Hearn wrote:<br>
<br>
&gt; That&#39;s great! I&#39;m all for more wallets, especially user friend=
ly UIs.<br>
&gt;<br>
&gt; However being based on bitcoind means it will take a very long time to=
 synchronize for new users. We know a lot of users drop out. The best fix f=
or this is SPV mode. Do you have any plans in this direction?<br>
&gt;<br>
&gt; So far, the only SPV mode implementation I know about is bitcoinj. I a=
m experimenting with trans-piling bitcoinj to C++ to make it usable from Ob=
jective-C++ exactly with your use case in mind.<br>
<br>
</div></div></blockquote></div><br></div>
---------------------------------------------------------------------------=
---<br>See everything from the browser to the database with AppDynamics<br>=
Get end-to-end visibility with application monitoring from AppDynamics<br>
Isolate bottlenecks and diagnose root cause in seconds.<br>Start your free =
trial of AppDynamics Pro today!<br><a href=3D"http://pubads.g.doubleclick.n=
et/gampad/clk?id=3D48808831&amp;iu=3D/4140/ostg.clktrk_____________________=
__________________________" target=3D"_blank">http://pubads.g.doubleclick.n=
et/gampad/clk?id=3D48808831&amp;iu=3D/4140/ostg.clktrk_____________________=
__________________________</a><br>
Bitcoin-development mailing list<br><a href=3D"mailto:Bitcoin-development@l=
ists.sourceforge.net" target=3D"_blank">Bitcoin-development@lists.sourcefor=
ge.net</a><br><a href=3D"https://lists.sourceforge.net/lists/listinfo/bitco=
in-development" target=3D"_blank">https://lists.sourceforge.net/lists/listi=
nfo/bitcoin-development</a><br>
</blockquote></div><br><div>
<div style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;tex=
t-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:norma=
l;text-transform:none;font-size:medium;white-space:normal;font-family:Helve=
tica;word-wrap:break-word;word-spacing:0px">
<div style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;tex=
t-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:norma=
l;text-transform:none;font-size:medium;white-space:normal;font-family:Helve=
tica;word-wrap:break-word;word-spacing:0px">
=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=
=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=
=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=
=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=
<br>include7 AG<br>Jonas Schnelli<br>Mattengasse 27<br>CH-8005 Z=C3=BCrich<=
br>Switzerland<br>Office: <a href=3D"tel:%2B41%2044%20500%2016%2070" value=
=3D"+41445001670" target=3D"_blank">+41 44 500 16 70</a><br>
<br>Mail:=C2=A0<a href=3D"mailto:jonas.schnelli@include7.ch" target=3D"_bla=
nk">jonas.schnelli@include7.ch</a><br>Web:=C2=A0<a href=3D"http://www.inclu=
de7.ch/" target=3D"_blank">www.include7.ch</a><br>V-Card:=C2=A0<a href=3D"h=
ttp://www.include7.ch/js.vcf" target=3D"_blank">www.include7.ch/js.vcf</a><=
br>
=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=
=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=
=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=
=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=
<br><br>ACHTUNG<br>Bitte senden sie uns keine sensitiven Daten=C2=A0in unve=
rschl=C3=BCsselten E-Mails.<br>Verwenden Sie hierzu folgenden Link:<br><a h=
ref=3D"https://include7.ch/contact/secureform" target=3D"_blank">https://in=
clude7.ch/contact/secureform</a><br>
<br>=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=
=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=
=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=
=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=C2=B0=
=C2=B0</div></div>
</div>
<br></div></blockquote></div>

--089e0115f34e90907c04e1926bc8--