summaryrefslogtreecommitdiff
path: root/9a/15d873e9b3f8efc71d29dd26a16479b9b800c1
blob: 125371611645c49aacf214a94edbdd3e3e93c896 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
Return-Path: <justin@netki.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 87E63BAF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 17 Jul 2015 01:02:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com
	[209.85.218.43])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 84C78126
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 17 Jul 2015 01:02:01 +0000 (UTC)
Received: by oige126 with SMTP id e126so61850612oig.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 16 Jul 2015 18:02:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=+oSujTea+uuR7NbROVejpWaTqe12Y4wFRErCGObR+Jk=;
	b=CMZx7Sl7D8wX7+AlxbrOG3sBvKS8FJTTZVkNeLKnxYPV49phO74f0H5dHhJl6TQ9Kp
	ELx86RSzSo/5NTxE9yPpz7Uog1UGCjWdYQIVERcJ0pESQZKKfuTotUP3+fXmoT/D2S6J
	+4YQpir6budvTfiGJb1SQoz9iJ+TjTAppO//ihJLiduGPw6sTIT+bWRBbCC1NF8wVeRN
	iLtrTtaKkKUQLcc6dllj+sP8Z+PMigUQG+Fm4Bj+sFWM7FpyDWqatSwxzUmWPnzITPx8
	vwy5/rgsGQZcMj199HSHmTfuWJWggOkWtKusR0GWpnlEsqiTLm80i53eqxacGea5DscV
	q3Dw==
X-Gm-Message-State: ALoCoQnJHf8En0VABt1rTLwBAr0hLEAXEaMSYGgg4+AxmekTJzF0l8xzj2MRCFwhq57vc76dEYoc
MIME-Version: 1.0
X-Received: by 10.60.69.200 with SMTP id g8mr11022104oeu.40.1437094920901;
	Thu, 16 Jul 2015 18:02:00 -0700 (PDT)
Received: by 10.202.221.66 with HTTP; Thu, 16 Jul 2015 18:02:00 -0700 (PDT)
In-Reply-To: <CABqynxL5AhEPLSw8TYjn9CVTc42+OHihKPGY6X3GP5W6u6TZaQ@mail.gmail.com>
References: <CADhj2oT_rgaf6LFgwMawwJKaA8384v5jQ=e-7T8GNY4gGZ2udQ@mail.gmail.com>
	<CABqynxKf=xBOG_38LYqtps2jXWeOR3g4PVFm6AKbJKLndG3Tig@mail.gmail.com>
	<CABqynxL5AhEPLSw8TYjn9CVTc42+OHihKPGY6X3GP5W6u6TZaQ@mail.gmail.com>
Date: Thu, 16 Jul 2015 18:02:00 -0700
Message-ID: <CABqynxJAMPain_SJJ9OiVfH9MJKurip-2O3EadkJBamak3j7jA@mail.gmail.com>
From: Justin Newton <justin@netki.com>
To: Justin Newton <justin@netki.com>
Content-Type: multipart/alternative; boundary=001a11333a3644ebc7051b07bcaf
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jul 2015 01:02:02 -0000

--001a11333a3644ebc7051b07bcaf
Content-Type: text/plain; charset=UTF-8

[CONTINUED]

>
> Additionally, we just released another open source API server to help
>> with the "other half" of the lookup problem.  Its in its infancy, and
>> we are certainly taking feedback on it at this time.  It is called
>> Addressimo <https://github.com/netkicorp/addressimo> and will serve
>> unique HD Wallet addresses or Payment Requests for every lookup, thus
>> allowing a user to have a private, secure way to share a Wallet Name
>> that can be used to send them any digital currency.
>>
>
> Oh snap...https://github.com/openalias/openalias-api
>

These are actually vastly different pieces of software, at least from the
description, and a first read of the code.  My understanding is the
software you linked to here basically takes the DNS work out of lookups for
people, as we released: https://github.com/netkicorp/wns-api-server  Its
our Wallet Name Lookup server.

Addressimo, as I described above, provides a different purpose.  Its a way
for service providers, mobile wallet providers or end users to have an
online server that can serve unique wallet addresses ala HD Wallets (BIP32)
or signed Payment Requests (BIP0070).  This allows for an easy way to
increase security and privacy by serving a unique address for every
request, and/or sign the address (and other optional data) with an X509
private key to prove ownership of the address in a way independent of and
supplemental to the DNSSEC chain (also can be DANE for yet another layer of
security).  It also supports offline signing of the Payment Requests so the
server doesn't have to have access to a private key, or need to be trusted.





>
>
> In any case, I'd much rather we had one effort going forward than
>> multiples, so let's talk!
>>
>
> I agree, and you guys are in an ideal position to change to supporting the
> OpenAlias standard (and enhancing it) without skipping a beat. We would
> definitely appreciate and take your input and efforts, and that would make
> OpenAlias v2 (oa2:) a standard built out in conjunction with Netki.
>
> Not only do you get Electrum support without lifting a finger, but it will
> go a long way to repairing your relationship with the open-source community
> at large, several proponents of which have taken great umbrage at what you
> were previously pushing as a closed-source, centralised system.
>
>
I'm a little confused by these closing statements.  Our system has, from
the beginning been open in terms of the fact that anyone could both serve
names or do lookups without ever touching our servers, talking to us, or us
even knowing that they did it or that they even exist.  Our system has
NEVER been one where folks were required to use us for any portion of the
service, and from our first beta product launch our open source tools did
all lookups against DNS records and the blockchain, never any proprietary
servers or interfaces on our side.

In terms of the format itself being open, we have already made several
extensions and modifications to it as a result of conversations with
industry participants in order to ensure that what we are building meets
the needs of the community at large.  We will gladly continue to do so, it
is how we ensure we are building something everyone needs!

I'd love to know where you got information that we were in some way a
closed and centralized system so that we can have an opportunity to clarify
that misconception.


In terms of finding a common standard, as I said, I am thrilled to have the
conversations, but there are some places, highlighted above, that would
cause me to hesitate to "just implement" the Open Alias standard.  I can
also see places where bringing the formats together to one standard could
have strong benefits, for example:

I think formatting the record as a key value pair with versioning has
merit, and would love to move it in to what we are doing (and likely will).

On the other side, I think the two level lookup provides a lot of value at
scale over trying to send back a bunch of text records when only a small
portion of the data is used.

I'd love to hear thoughts from others in the community on mandating DNSSEC
and thoughts on DNSCrypt.  I have a strong opinion on both of those but
would love to engage in thoughtful dialogue around what path best suits the
need of the community.


Looking forward to the discussion!

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

<div dir=3D"ltr">[CONTINUED]<br><div><blockquote class=3D"gmail_quote" styl=
e=3D"font-size:13px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div d=
ir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><br><=
/div><span class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex">Additionally, we just released ano=
ther open source API server to help<br>with the &quot;other half&quot; of t=
he lookup problem.=C2=A0 Its in its infancy, and<br>we are certainly taking=
 feedback on it at this time.=C2=A0 It is called<br>Addressimo &lt;<a href=
=3D"https://github.com/netkicorp/addressimo" rel=3D"noreferrer" target=3D"_=
blank">https://github.com/netkicorp/addressimo</a>&gt; and will serve<br>un=
ique HD Wallet addresses or Payment Requests for every lookup, thus<br>allo=
wing a user to have a private, secure way to share a Wallet Name<br>that ca=
n be used to send them any digital currency.<br></blockquote><div><br></div=
><div>Oh snap...<a href=3D"https://github.com/openalias/openalias-api" targ=
et=3D"_blank">https://github.com/openalias/openalias-api</a></div></span></=
div></div></div></blockquote><div style=3D"font-size:13px"><br></div><span =
class=3D"im" style=3D"font-size:13px"><div>These are actually vastly differ=
ent pieces of software, at least from the description, and a first read of =
the code.=C2=A0 My understanding is the software you linked to here basical=
ly takes the DNS work out of lookups for people, as we released:=C2=A0<a hr=
ef=3D"https://github.com/netkicorp/wns-api-server" target=3D"_blank">https:=
//github.com/netkicorp/wns-api-server</a>=C2=A0=C2=A0Its our Wallet Name Lo=
okup server. =C2=A0</div><div><br></div><div>Addressimo, as I described abo=
ve, provides a different purpose.=C2=A0 Its a way for service providers, mo=
bile wallet providers or end users to have an online server that can serve =
unique wallet addresses ala HD Wallets (BIP32) or signed Payment Requests (=
BIP0070).=C2=A0 This allows for an easy way to increase security and privac=
y by serving a unique address for every request, and/or sign the address (a=
nd other optional data) with an X509 private key to prove ownership of the =
address in a way independent of and supplemental to the DNSSEC chain (also =
can be DANE for yet another layer of security).=C2=A0 It also supports offl=
ine signing of the Payment Requests so the server doesn&#39;t have to have =
access to a private key, or need to be trusted.</div></span><div style=3D"f=
ont-size:13px"><br></div><div style=3D"font-size:13px"><br></div><div style=
=3D"font-size:13px"><br></div><div style=3D"font-size:13px">=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"font-size:13px;margin:0px 0px 0px 0=
.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote"><div><br></div><div><br></div><span class=3D"im"><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex">In any case, I&#39;d much rather we had one effort going fo=
rward than<br>multiples, so let&#39;s talk!<br></blockquote><div><br></div>=
<div>I agree, and you guys are in an ideal position to change to supporting=
 the OpenAlias standard (and enhancing it) without skipping a beat. We woul=
d definitely appreciate and take your input and efforts, and that would mak=
e OpenAlias v2 (oa2:) a standard built out in conjunction with Netki.</div>=
<div><br></div><div>Not only do you get Electrum support without lifting a =
finger, but it will go a long way to repairing your relationship with the o=
pen-source community at large, several proponents of which have taken great=
 umbrage at what you were previously pushing as a closed-source, centralise=
d system.</div><div><br></div></span></div></div></div></blockquote><div st=
yle=3D"font-size:13px"><br></div><span class=3D"im" style=3D"font-size:13px=
"><div>I&#39;m a little confused by these closing statements.=C2=A0 Our sys=
tem has, from the beginning been open in terms of the fact that anyone coul=
d both serve names or do lookups without ever touching our servers, talking=
 to us, or us even knowing that they did it or that they even exist.=C2=A0 =
Our system has NEVER been one where folks were required to use us for any p=
ortion of the service, and from our first beta product launch our open sour=
ce tools did all lookups against DNS records and the blockchain, never any =
proprietary servers or interfaces on our side. =C2=A0</div><div><br></div><=
div>In terms of the format itself being open, we have already made several =
extensions and modifications to it as a result of conversations with indust=
ry participants in order to ensure that what we are building meets the need=
s of the community at large.=C2=A0 We will gladly continue to do so, it is =
how we ensure we are building something everyone needs!</div><div><br></div=
><div>I&#39;d love to know where you got information that we were in some w=
ay a closed and centralized system so that we can have an opportunity to cl=
arify that misconception. =C2=A0</div><div><br></div><div><br></div><div>In=
 terms of finding a common standard, as I said, I am thrilled to have the c=
onversations, but there are some places, highlighted above, that would caus=
e me to hesitate to &quot;just implement&quot; the Open Alias standard.=C2=
=A0 I can also see places where bringing the formats together to one standa=
rd could have strong benefits, for example:</div><div><br></div><div>I thin=
k formatting the record as a key value pair with versioning has merit, and =
would love to move it in to what we are doing (and likely will).</div><div>=
<br></div><div>On the other side, I think the two level lookup provides a l=
ot of value at scale over trying to send back a bunch of text records when =
only a small portion of the data is used.</div><div><br></div><div>I&#39;d =
love to hear thoughts from others in the community on mandating DNSSEC and =
thoughts on DNSCrypt.=C2=A0 I have a strong opinion on both of those but wo=
uld love to engage in thoughtful dialogue around what path best suits the n=
eed of the community. =C2=A0</div><div><br></div><div><br></div><div>Lookin=
g forward to the discussion!</div></span></div></div>

--001a11333a3644ebc7051b07bcaf--