From: Justin Newton <justin@netki•com>
To: Justin Newton <justin@netki•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
Date: Thu, 16 Jul 2015 18:02:00 -0700 [thread overview]
Message-ID: <CABqynxJAMPain_SJJ9OiVfH9MJKurip-2O3EadkJBamak3j7jA@mail.gmail.com> (raw)
In-Reply-To: <CABqynxL5AhEPLSw8TYjn9CVTc42+OHihKPGY6X3GP5W6u6TZaQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4341 bytes --]
[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!
[-- Attachment #2: Type: text/html, Size: 6284 bytes --]
next prev parent reply other threads:[~2015-07-17 1:02 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-14 19:07 Riccardo Spagni
2015-07-17 0:55 ` Justin Newton
2015-07-17 0:58 ` Justin Newton
2015-07-17 1:01 ` Justin Newton
2015-07-17 1:02 ` Justin Newton [this message]
2015-07-23 9:48 ` Thomas Voegtlin
2015-07-23 13:07 ` Thomas Voegtlin
2015-07-27 21:51 ` Justin Newton
2015-07-31 20:34 ` Thomas Voegtlin
-- strict thread matches above, loose matches on Subject: below --
2015-07-27 22:46 Riccardo Spagni
2015-07-18 11:40 Riccardo Spagni
2015-07-18 11:46 ` Mike Hearn
2015-07-17 8:00 Riccardo Spagni
2015-07-18 11:21 ` Mike Hearn
2015-07-16 16:18 Riccardo Spagni
2015-07-14 17:29 Justin Newton
2015-07-18 13:29 ` Thomas Voegtlin
2015-07-18 23:01 ` Justin Newton
2015-07-20 8:56 ` Thomas Voegtlin
2015-07-14 8:29 Riccardo Spagni
2015-07-13 22:31 Mike Hearn
2015-07-14 6:42 ` Thomas Voegtlin
2015-07-14 11:19 ` Milly Bitcoin
2015-07-14 13:13 ` Thomas Voegtlin
2015-07-14 11:45 ` Mike Hearn
2015-07-19 11:18 ` Thomas Voegtlin
2015-07-20 13:46 ` Mike Hearn
2015-07-20 14:32 ` Thomas Voegtlin
2015-07-20 14:42 ` Mike Hearn
2015-07-20 14:52 ` Thomas Voegtlin
2015-07-20 15:14 ` Mike Hearn
2015-07-20 15:34 ` Thomas Voegtlin
2015-07-20 16:09 ` Mike Hearn
[not found] <55A3B52C.9020003@electrum.org>
2015-07-13 13:06 ` Thomas Voegtlin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABqynxJAMPain_SJJ9OiVfH9MJKurip-2O3EadkJBamak3j7jA@mail.gmail.com \
--to=justin@netki$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox