From @ghjm:

Receptor seeks to provide its users with capabilities similar to those of TCP/IP: unreliable datagrams, similar to UDP; reliable streams, similar to TCP; and reliable secure streams, similar to TCP with TLS. As an implementation detail, Receptor makes use of a library called quic-go for the packet sequencing, error checking and retransmission required to implement reliable stream sockets. Note that the QUIC protocol is no part of the Receptor specification. End users of Receptor do not use QUIC and do not need to be aware that QUIC is in use, and Receptor only makes use of a subset of the capabilities of the quic-go library.

One of the capabilities Receptor affords to end users is non-TLS stream sockets. There are many use cases for this: for example, a chain of proxies where TLS is run over the whole proxy chain; running a DNS server; running or proxying SSH; running a protocol like SMTP that uses STARTTLS; and so on. The quic-go library insists on TLS, because its authors are only interested in the use case of running streaming web services and are not focused on more esoteric uses like that of Receptor. As a result, when a Receptor end user makes a non-TLS stream socket connection, Receptor constructs an insecure TLS configuration and passes it to quic-go. Note that in this case, the Receptor user has explicitly asked for no encryption at all.

If people are unhappy with this usage, one option would be to remove the dependency on quic-go entirely and use something else that does not require TLS. The requirements are that the library must accept an arbitrary PacketConn and provide reliable streaming sockets on top of it, without assuming that the PacketConn is TCP/IP-based (ie, uses IP addresses). A few such libraries exist, notably https://github.com/xtaci/kcp-go. However, none of them have quic-go's track record of successful production use. Rewriting Receptor to use a different library would also require development, testing and deployment resources, and would not provide any direct benefits to end-users. So it seems like the best option is to stick with quic-go, even though it makes us use TLS sometimes when we don't want to.