To break it down briefly, we have an open lookup standard based on
both the namecoin blockchain as well as traditional DNSSEC. (You can
choose your own adventure of using namecoin based names or traditional
ICANN names).
We DO provide a service where we will register or host
names on your behalf. However if you follow the format and host them
yourself, everything will work just fine, and our open source lookup
server and libraries will provide those results exactly the same as if
the names were hosted with us.
To that end, we have had conversations
with several companies in the space who intend to host their own
names, and we intend to work with them on the effort to ensure our
documentation is sufficient to ensure they can successfully do so.
In terms of comparisons to OpenAlias, I think there are a lot of
similarities, but a few differences. First the similarities:
1> We both use DNSSEC.
2> We both have the option of storing the address directly in the DNS record.
Differences:
1> We do not use DNSCrypt. I understand why you chose to, but we were
concerned about broad interoperability and easy broad distribution of
hosting, so decided not to use it. We have other ways of achieving
privacy, using HD Wallets and Payment Requests.
2> We have the option of storing a URL rather than just a wallet
address in the TXT record. This allows a second level lookup against
the URL to get back a unique HD Wallet address or Payment Request each
time, further protecting user privacy and security. Using Wallet
Names with Payment Requests allows for the user experience of typing
in an easy to remember name and getting back the "green lock" and who
the validated recipient is. This also provides an auto audit of the
end to end DNS SEC process, in the case the path were somehow
compromised, the signature on the payment request can provide an
additional check.
3> We use a 2 tier lookup format. The first lookup returns a list of
currencies or payment types supported by the Wallet Name. The second
lookup goes to a record specific to that currency type to get the
address to go to. We believe this to be a more scalable solution in a
world where someone can have both multiple digital currency types, but
then also multiple types of colored coins, and wants a simple way to
share a single name for all of those different addresses. This allows
the wallet to do the work behind the scene of choosing the currency it
wants to send, and automatically getting back the right address to
send to, without the user having to do anything different.
4> We mandate DNSSEC while you make it optional. We did this because
we believe giving the user the option of NOT using DNSSEC is like
letting them order a car with no brakes. We weren't sure how we would
explain to them why their money was gone when they really didn't
understand the risks they were taking up front. We had a lot of
discussion about it before coming to the decision we did, and I can
see why you went the other way, although I do believe we made the
right choice.
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.
I'd love to talk here or offline about merging standards going
forward. As an FYI, Verisign has also delivered a standard to the
IETF using DNSSEC to pass payment information here:
https://tools.ietf.org/html/draft-wiley-paymentassoc-00 We have
started discussions with them about merging standards as well.
They actually have a really nice way in their standard to encode email
addresses that more or less ensures that there won't be name space
collision in the case that there is already a record "joe.user.com"
and you want to create one for "joe@user.com" that we are looking at
adding to what we are doing in the next update to our record formats.
In any case, I'd much rather we had one effort going forward than
multiples, so let's talk!