clarify intended behavior of `validate`

[0xdaem0n]

The validate and verify functions (unclear of the distinction, but appears to be discussed in #24) has an inconsistent implementation in nearly every language. I am curious what the intended implementation is, totally understand that different languages have different idioms to adhere to.

• Python: the validate function does not return anything, merely raises an exception if there is an error in parsing. However, the docstring indicates an intended boolean return type (true if ok, false otherwise).
• Javascript: the equivalent validate function returns {Promise<SiweMessage>} This object if valid., which is a parsed message with all the message's fields.
• Rust: my read of the verify function (not validate) is that it returns the publickey, if valid, and throws an error otherwise.
• Golang: verify function looks to be same as in Rust
• Ruby: I think this function returns true if valid, and raises an exception otherwise.
• Elixir: AFAICT this implementation actually does return true if valid and false otherwise, as it catches any exceptions to finally return a boolean.

In particular, Javascript looks to be the outlier with its behavior - it does validate the message but additionally returns the message. However, it's also the language with the most adoption / usage, so I assumed it was the 'canonical' approach.

Happy to help with the changes if we can confirm the desired behavior, thanks for working on the protocol!

[awoie]

We are currently harmonizing our APIs across languages (should be finished this week) and we can then revisit this issue.

[sbihel]

The naming is now unified accross the libraries, #27 for the Python one. verify is to verify the signature, nonce, etc. validate if present (it is a constructor in most languages) validates the formatting of a message.

As for the return type, it simply depends on what the underlying ethereum/secp256k1 library returns, and the language's idioms.