Cool,

Since we're trying to clarify some of the things that may not be entirely 
clear, there are a few other things it may be relevant to address or define at 
the same time:

  1.  What's the intended direction of interpreting the conditions?
  2.  What's the result of the conflict if a condition is specified multiple 
times?

So using the thought-up case of r0.a2.n5.a4.n10.seed.example.com:

  1.  Should the DNS seed process the conditions from the seed root and "up the 
tree" or in the opposite direction?

For the sake of argument, I'm going to assume we want to take a (DNS-wise) 
logical approach, i.e. interpreting from the seed root and "up the tree", so in 
the order: n10, a4, n5, a2, r0.

  1.  What happens to a2 when we meet a4? Should a4 replace any current a 
condition or simply be ignored (or in the case of a perhaps even merged through 
a bitwise or)? Same question for n5when we meet n10.

Personally I think it would make sense to always replace currently set 
conditions, when we hit new conditions with the same key. This would allow us 
to easily add a condition to a query programmatically, without having to 
interpret any conditions that may be set already. Prepending a current query 
string with a6. would then guarantee that an earlier condition does not limit 
my results to either IPv4 or IPv6 nodes. As long as the length of the query 
string does not exceed a total of 253 chars (standard DNS limitation, not 
counting the root .).

Any thoughts on this?


/Thomas

________________________________
From: Christian Decker <decker.christ...@gmail.com>
Sent: Friday, March 16, 2018 10:44:01 AM
To: Thomas Steenholdt
Cc: lightning-dev@lists.linuxfoundation.org
Subject: Re: DNS Seed query semantics clarification

Thomas Steenholdt <tsteenho...@cascadetechnologypartners.com> writes:
> Thanks for the explanation - This was exactly the the piece of the
> puzzle I was missing. 😊
>
> I'd be happy to help clarify this in the BOLT10 specification, if that
> makes any type of sense? I can make a pull request for revie

Absolutely, improvements are always welcome :-)

_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to