From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 87E63BAF for ; 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 ; Fri, 17 Jul 2015 01:02:01 +0000 (UTC) Received: by oige126 with SMTP id e126so61850612oig.0 for ; 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: References: Date: Thu, 16 Jul 2015 18:02:00 -0700 Message-ID: From: Justin Newton To: Justin Newton 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
[CONTINUED]

<= /div>
Additionally, we just released ano= ther open source API server to help
with the "other half" of t= he lookup problem.=C2=A0 Its in its infancy, and
we are certainly taking= feedback on it at this time.=C2=A0 It is called
Addressimo <https://github.com/netkicorp/addressimo> and will serve
un= ique HD Wallet addresses or Payment Requests for every lookup, thus
allo= wing a user to have a private, secure way to share a Wallet Name
that ca= n be used to send them any digital currency.

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=A0https:= //github.com/netkicorp/wns-api-server=C2=A0=C2=A0Its our Wallet Name Lo= okup server. =C2=A0

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't have to have = access to a private key, or need to be trusted.



=C2=A0


<= 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'd much rather we had one effort going fo= rward 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 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.
=

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.


I'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>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!

I'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


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 "just implement" 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:

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).
=
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.

I'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


Lookin= g forward to the discussion!
--001a11333a3644ebc7051b07bcaf--