Should the output of encrypt be base64 url encoded strings?

[gauntface]

cc @wibblymat @petele @PaulKinlan @beverloo

At the moment the output of encrypt are buffers, given that some fields need to be url safe base64 encoded and some don't (I can't recall which) and given this is accessible on the index object, it feels a bit unfriendly to return a buffer.

We could by default return a string for ciphertext, salt and serverpublickey and have an option on the encrypt method to return buffer (just a boolean) that if set to true will return the buffer (useful for internal usage of encrypt).

var message = library.encrypt('Hello, World', subscription);
console.log(message);

// Prints
{
  ciphertext: <Buffer 5d c6 c4 eb 1d 15 38 34 68 1c 32 f4 dd 46 b9 1e 32 4e 3b ff 17 b7 74 e2 87 54 81 f1 64 c1>,
  salt: <Buffer 29 d8 5c b5 46 36 49 58 4f 89 b7 3f f0 e9 28 7c>,
  serverPublicKey: <Buffer 04 f6 80 3b 42 ec 2a 67 a8 9a eb 3e 91 06 7f c7 e1 4f f4 28 41 9b 6a f8 ef 53 6a c8 17 97 52 f1 9e 1e d0 6e bc b8 4a e3 47 7d 73 5f 5b 3d d0 9d c1 f9 ... >
}

[petele]

When would a developer ever want the buffer vs string? If it's rare, or only the advanced dev who wants the buffer, then let's just drop it.

These libraries should cover the 80% use case, not every use case. If a dev wants something special, they can use the the library as their starting point and add the custom functionality they need.

[wibblymat]

The ciphertext at least MUST be raw bytes. But yeah, maybe the other two should come back as strings. On Fri, 26 Feb 2016 at 15:23 Pete LePage notifications@github.com wrote:

When would a developer ever want the buffer vs string? If it's rare, or only the advanced dev who wants the buffer, then let's just drop it.

These libraries should cover the 80% use case, not every use case. If a dev wants something special, they can use the the library as their starting point and add the custom functionality they need.

— Reply to this email directly or view it on GitHub https://github.com/GoogleChrome/push-encryption-node/issues/7#issuecomment-189321411 .