Thomas Voegtlin [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-18 📝 Original message:Le 14/07/2015 19:29, ...

📅 Original date posted:2015-07-18
📝 Original message:Le 14/07/2015 19:29, Justin Newton a écrit :

> Hi there. You are correct that we are a company providing a service,
> however, that service is also based on an open standard which we are
> proposing. I'll be honest that we haven't done the greatest job in
> promoting the standard so far. More coming soon on that front. Any
> of the Open Source Wallet Name resolvers that we have created do
> lookups against the standard record formats, and not directly against
> our servers in any way. Information on the record formats as well as
> links to the lookup API server and some early libraries can be found
> here: https://www.netki.com/#/developers and here:
> https://github.com/netkicorp
>

Sorry to answer late, and thanks for the clarification. After talking
with you, I believe that it will not be difficult to agree on a common
standard, that gives maximum freedom to everyone.

I also believe that it is in Netki's interest to convey the message that
they are actively promoting an open standard, and not pushing a private
solution. For this reason, and assuming that the future standard
satisfies you fully, will you mind if that standard carries a neutral
name (such as "OpenAlias v2", or "BIP xx"), instead of being named after
your company? I reckon that is purely a PR issue.


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

I would rather not make Namecoin part of the standard, because .bit
records cannot be verified easily by lightweight/spv wallets; they would
need a copy of the Namecoin blockchain for that.

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

As far as Electrum is concerned, I do not see DNSCrypt as something
usable in the short term. I do not think it should be mandated, because
there are other ways of achieving privacy, as you say.

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

I see value in the ability to store differerent types of strings in TXT
records. In particular, I have the need to store an email address, and
more than one Bitcoin address or xpubkey per alias.

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

This seems to be a major difference, and I believe it makes sense to do
it the way you describe. Does that solution fully replace the tags used
in OpenAlias, or does it make sense to combine these two systems?


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

I agree on this; there is no point using OpenAlias without DNSSEC.
Wallets can use fallback servers if the default DNS does not have DNSSEC.

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

That is nice, but may be out of scope here. Isn't there a risk that
involving the IETF would make the process a lot slower? Of course it
would be great, but maybe we should try to reach consensus at our level
first (the bitcoin level), before trying to merge with them.


>
> 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 at 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!
>