Closed jD91mZM2 closed 6 years ago
Not sure I understand what you mean.
In programmer's terms: Should I store shit in a string or byte array?
Definitely string. Byte array adds JUST another byte to string conversion really.
use byte array. flexibility is good.
I just hope MsgPack byte arrays aren't as inefficient as in JSON.
Oh god. Hope that doesn't make injections possible...
yeah maybe we should just use utf8
~Theodore
On Oct 13, 2017, at 9:30 AM, jD91mZM2 notifications@github.com wrote:
Oh god. Hope that doesn't make injections possible...
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
we can always expand it in the future
But I still need to use a byte array where encryption is possible. So I need to know if injections are possible D:
fuk
~Theodore
On Oct 13, 2017, at 9:32 AM, jD91mZM2 notifications@github.com wrote:
But I still need to use a byte array where encryption is possible. So I need to know if injections are possible D:
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
Just tried converting JSON to MsgPack in the online thingy. It seems like it adds the length in front of the array. good.
Vote up for string, vote down for byte array.
Not sure tbh... It may cause issues with certain implementations of msgpack, idk. Well, keeping it how it is rn is a bad option?
It's not a bad option at all. Might be a little tedious having to convert it to a String for Rust users, but nothing big. All is fine!
Well think of me with the go lib and understand how tedious all this is. Since its already pretty much fine, this shouldn't be what's holding you to release
Reason I added this in the first place is because I originally intended any message to be able to be E2E encrypted. But now when we're making them only work in DMs (because only one person can decrypt them anyways), should I revert it? I mean, that will probably reduce packet size (not sure though, this is MsgPack, not JSON...).