Very silly indeed. There's no actual explanation of how, say, "cryptocurrency" should be used. If a spec cannot provide clear examples of what a header or piece of data is supposed to do, that's a warning.
Also not a fan of their little mini-formats embedded inside the format. Pick a structured encoding system, and stick to it. Like cryptocurrency, if it has to exist, should have two fields, type and address. Not this silly parse-text-look-for-semicolons. This kind of stuff leads to people grafting on all sorts of extra bits that require special parsing. It's bad and pointless. Use a binary JSON or something format and call it a day, and don't cram anything else into a string field other than a single value.
And the Phone field definition provides no format for the number, thus making many numbers you receive potentially ambiguous. Does 502 refer to Kentucky or Guatemala?
Seriously though: predefined fields to refer to a user or organisation's "vision statement"? Someone discovered that when you're just typing specs in Word, there's no implementation cost to pay and you can literally type in anything you please. This is the same problem that plagues various other specs. The same reason HTTP has line-wrapping in header fields, or why email URIs can contain comments, ffs.
There also seems to be a lot of "mays" and weird behaviour. Like, images can be 16MB. But you should keep them at 1MB or less, cause maybe clients might not display them if they're over 1MB. Probably. They can ignore them over 1MB, but they have to "handle" up to 16MB. This kinda stuff serves no purpose but to harm interop and split implementations.
Seriously, the more I read this, the more I see someone just having fun re-making email. Hey, sky's the limit! This is pretty funny considering: "DMTP is intentionally simplistic". Simplistic, but they cannot even agree on LF versus CRLF. Seriously. Brand-new protocol, and line-endings for the transfer part is implementation defined.
Disclosure: Given Lavabit's past, I was inclined to think Dark Mail would be more snake oil, so I am definitely biased.
Also not a fan of their little mini-formats embedded inside the format. Pick a structured encoding system, and stick to it. Like cryptocurrency, if it has to exist, should have two fields, type and address. Not this silly parse-text-look-for-semicolons. This kind of stuff leads to people grafting on all sorts of extra bits that require special parsing. It's bad and pointless. Use a binary JSON or something format and call it a day, and don't cram anything else into a string field other than a single value.
And the Phone field definition provides no format for the number, thus making many numbers you receive potentially ambiguous. Does 502 refer to Kentucky or Guatemala?
Seriously though: predefined fields to refer to a user or organisation's "vision statement"? Someone discovered that when you're just typing specs in Word, there's no implementation cost to pay and you can literally type in anything you please. This is the same problem that plagues various other specs. The same reason HTTP has line-wrapping in header fields, or why email URIs can contain comments, ffs.
There also seems to be a lot of "mays" and weird behaviour. Like, images can be 16MB. But you should keep them at 1MB or less, cause maybe clients might not display them if they're over 1MB. Probably. They can ignore them over 1MB, but they have to "handle" up to 16MB. This kinda stuff serves no purpose but to harm interop and split implementations.
Seriously, the more I read this, the more I see someone just having fun re-making email. Hey, sky's the limit! This is pretty funny considering: "DMTP is intentionally simplistic". Simplistic, but they cannot even agree on LF versus CRLF. Seriously. Brand-new protocol, and line-endings for the transfer part is implementation defined.
Disclosure: Given Lavabit's past, I was inclined to think Dark Mail would be more snake oil, so I am definitely biased.