> As far as your other suggestion goes, don't reinvent crypto badly -
> if you want to provide authentication support in listener(), provide a
> hook that allows the application to decide whether or not to accept
> the configuration before it gets applied.

Well, that's fine. My earlier suggestion keeps the API change to a minimum, but I suppose there's no real need to be so minimal.

I suppose the basic approach would be to pass to listen() an optional verify callable (defaulting to None) which, if provided, would be called with the bytes received over the socket. That allows for e.g. signed or encrypted data. The value returned from the verify() call would be processed as the current received value is (allowing the verifier to transform the input, e.g. by decrypting it).