* Does not require you to set up or trust a CA.

* Does not require X.509 processing, which is a huge source of TLS implementation bugs.

* Uses secure-by-default ciphersuite which, unlike TLS's, was designed after the most important work in authenticated encryption was published.

* Does not include legacy ciphersuites with known flaws.

* Mutually authenticated without invoking TLS corner case subprotocols like client certificates and session resumption.

* Small enough to be auditable.

If you have actually tried to implement TLS yourself, there are a lot of places where you can go wrong. There are some places in TLS where it is easy to make implementation errors, and you can't confidently say there are unlikely to be any vulnerabilities in an implementation.

spipes builds upon well-understood primitives and provides a simple, clear, and likely to be correct implementation.

That seems to be a non-argument to me: you shouldn't implement TLS yourself anyways. And given that spiped is a younger project than say OpenSSL will mean less eyeballs applied to finding bugs. And the cryptographic primitives spiped uses are available in TLS as well.

TLS and spiped are simply two different tools, for two different purposes. Control only one of the endpoints? You'll have to use TLS. Want to secure communication between infrastructure you control? Check out spiped.

Even if you're just implementing TLS using an existing TLS library it's easy to get that wrong. TLS is a pain.

Ironic - the timing of your comment, " And given that spiped is a younger project than say OpenSSL will mean less eyeballs applied to finding bugs. " given todays announcement regarding the absolutely epic OpenSSL bug.

What are your thoughts now on not exposing yourself to all of the complexity of OpenSLL?