in both of those PRs, what we have is some local code wrapping a remote procedure call. the error being handled could be be coming from either the local code, or the remote code, or from the stream connecting them. if an error comes from the rpc stream, it means the rpc connection is broken. in scuttlebot#374, i wanted to check if the error was from the stream. in ssb-ebt#2, i wanted to check for specific error types coming from the remote, or for a stream error. i think both of these could be handled by clarifying the errors produced of the underlying interfaces. e.g. packet-stream or muxrpc could pass a specific error to rpc calls that means "the rpc stream broke", and one that means "the remote rejected this method call". then the consumers of these errors may have to handle them and pass them to their caller, and have to decide whether to pass them through, or wrap them with another error. too much passing through and not enough wrapping is i think why there were so many errors in #374 that all meant "the rpc connection broke" to me.

i like the traditional idea of scalar error types. like with C functions where it is specifically documented which error codes a function might set. (see also man 3 errno). but i can see that making errors into vectors or sets could allow for potentially more expressive error handling.