Stamps discussion

[pequalsmp]

Hi,

Thank you for all of your work on this project, its amazing how fast-paced the development is.

I would like to ask a few question around the newest change - stamps.

• What standard are stamps following?

We can see some stamps using the _ character which is invalid as per the original RFC and as a result, base64 will fail to decode the stamps. While there are variants allowing this, its certainly not the default option.

• Can we keep the previous format for static server declaration?

  The configuration file should be human readable and manually defining provider_name, address and public_key is much simpler and straight-forward compared to stamp. It seems, that the stamp structure is more complex, and generating them manually (from the previously mentioned parameters) is a bit cumbersome.

• Do we need a uri (sdns://) prefix?

Its unlikely (due to the potential for adding rogue servers without the user knowing) that dnscrypt servers will end up as browser links, which you click, to add them to your static list. And it doesn't seem to serve any purpose during stamp processing either.

[jedisct1]

1) It's the URL-safe base64 variant.

2) Probably not. The previous "format", which wasn't really one, is compatible with nothing but itself. It can't be used to describe a non-encrypted DNS service, a DNS-over-HTTP2 service or a future revision of the DNSCrypt protocol.

3) The prefix serves different purposes:

• It ties the encoded binary string that follows to something. So that you won't post your bitcoin secret key instead.
• It makes it easy to extract DNS stamps from plain text documents. The way servers lists are published depends on that prefix to find where stamps are without resorting to slow and unreliable heuristics.
• Stamps are highlighted like other resource identifiers in text editors :)

[pequalsmp]

I was wondering what your thoughts are on something much simpler, like base64-encoding JSON:

DNSCrypt

{
   "type":"dnscrypt",
   "address":"127.0.0.1",
   "publickey":"FFFF:::FFFF",
   "features":[
      "dnssec",
      "nolog",
      "nofilter"
   ]
}

and DoH respectively

{
   "type":"dnsohttp",
   "address":"127.0.0.1",
   "hostname": "google.com",
   "path": "/",
   "certs": [
        "EEEE",
        "FFFF"
   ],
   "features":[
      "dnssec",
      "nolog",
      "nofilter"
   ]
}

Pros

• Almost every language can serialize/deserialize JSON
• Human readable / modifiable
• Simple structure
• Easily extendable - new features can be added without changing / modifying the parser.

Cons

• Size - this approach increases the size of each stamp a couple of times. However, we're still talking bytes, thus its unlikely to be a problem
• Minor performance decrease (worst case - ms) on startup

[jedisct1]

For keys and hashes, that would be binary-encoded-as-hexadecimal-encoded-as-JSON-encoded-as-base64. Not very efficient :)

[pequalsmp]

Its definitely Matryoshka-esque, still this are operations where realtime performance is not critical.

There is also BSON. Its similar to the current format (length followed by data), but its "standardized" and there are multiple libraries for almost every language/platform.

[jedisct1]

BSON is old and was never standardized. CBOR is, but the current format is super simple. Really, I don't think it's worth importing a generic parser just to parse length-prefixed byte vectors.