Can we make the default be 'buffer' instead of 'binary' if no encoding is given and the argument is a Buffer?

@mscdex I think it might break backward compatibility.

That's fine.... this is in 0.9/master already because it's an API change :-)

+1

I was under the impression that this "buffer encoding" was going to be internal, and not exposed in the docs. Returning a Buffer instance should be the default, just like all the other Node core APIs IMO.

@TooTallNate @mscdex:
All crypto is stable

3 - Stable The API has proven satisfactory, but cleanup in the underlying code may cause minor changes.
Backwards-compatibility is guaranteed.

This doesn't mean that we can change stable API between major releases, or I'm wrong?

By changing default behaviour you break lot of modules. (need investigation)

Note that there is more features required from crypto e.g. streams.

One posibility is entirely new module (something like crypto.2) which will respect all the new goods.

IMHO if "stable" here means that this particular change cannot be made, then I think it was a mistake to label it as "stable", especially when Buffer support wasn't even added until just now (which is crazy).

Also as @TooTallNate mentioned, it's better to have Buffer as a default encoding to more closely match encoding behavior elsewhere in node. The less gotchas the better.

@mscdex Absolutely agree, but...

• Step one - deprecate binary encoding, which is now implicit in this API. This will come in Deprecate 'binary' encoding #3279 (@isaacs?)
• Step two - cut out binary encoding entirely and introduce Buffer as implicit, deprecate other encodings in crypto module.

but step two must come some time later, giving maintainers of packages a chance to update

As much as I agree that the 'binary' encoding is not very efficient/elegant/whatever, it's very nice to have available because you can use native string functions to find bytes, perform manipulations, etc.

IMHO since Buffer does not have these same kinds of methods available (unless core members would be willing to merge in something like node-buffertools), we should not remove 'binary' encoding support.

Also, I'm not so sure that deprecating additional/other encodings in crypto is a good idea (making a Buffer the only allowed input/output?). Especially if we're really talking about just crypto, since that would introduce more gotchas if encodings can be used in similar situations elsewhere in node.

@richardhoffman that's like telling people to just convert binary string results back to a Buffer when using crypto functions. Sure you can do that, but why would you want to do it?

@mscdex Where input or output has no encoding by nature - just bytes - there shouldn't be string input or output.
Speaking in C++ types, void * and char * are different. No reason to reinterpret_cast them in javascript.

Node Buffer is not part of standart nor V8, that means pull requests can be accepted if reasonable.

If you want text, you can get if from buffer by Buffer#toString(encoding, start, end) and you should choose proper one or 'hex'

+1 to @mscdex and @TooTallNate : it's better to have Buffer as a default encoding to more closely match encoding behavior elsewhere in node.

To @richardhoffman: Why would you need to modify a crypto buffer?
Because:

1. computers talk in binary, not talk in human language
2. String in JavaScript is UTF friendly, which is handy to write program logic, but is a waster in data processing.

So, here's a plan. @indutny et al, please let me know if you think this is sane:

1. Take this patch, basically as-is. binary remains the default, and we add buffer, noting that it is kludgey and weird.
2. Reduce the crypto stability index to 2: Unstable. Add a paragraph in the docs noting that the binary encoding will cease to be the default in a future version.
3. Release 0.10.
4. In 0.11.0, make buffer the default, and bump the stability back up to 3: Stable.

@isaacs SGTM too