Snowlake IDs are sometimes string, sometimes integer.

[Marqin]

Look at this payload.

Channel ID is integer. Author id is integer. Message id is integer.

But when asking about User.current(state[:rest_client]) the result user ID is a string.

This should be uniformly treated in all places as a string or integer (preferable string, as Discord API uses strings for that).

iex(9)>
    "author" => %{"avatar" => "ac4066c6fb7c329e0cbdf9c88139a2e5",
      "discriminator" => "3379", "id" => 153225472447086593,
      "username" => "Marqin"}
    "channel_id" => 193682812925116416
    "id" => 218812642570141696

[Marqin]

Ok. I've talked with guys on discord API server (that one from #2) and this is what I get to know:

• when using websockets and ETF we get all Snoflakes as ints (because on the other side of wire is also Erlang VM)
• when using REST API we get all Snoflakes as strings, because that's how it works there (and there is Python)

[Marqin]

I think it's better to stay with ints (their comparision should be faster than strings?).

The question is, what to do with REST api? Leave it as string as just document it in README that it uses strings, or we cast it somewhere internaty to integers? (it can be hard to find all usage places)

[jhgg]

the reason the HTTP api returns strings is because javascript would truncate the number to 53 bits if it was sent as a number.

on our client - our ETF parser (http://github.com/hammerandchisel/erlpack) (which is C++) converts the large ints over the wire to strings for JS.

I'd be open to exposing a header that you can send with the request that tells the server not to do the conversion though if your client /can/ handle ints this large.

[Marqin]

@jhgg Thanks for explanation. And yes, header for that would be helpful.

[Marqin]

I made suggestion on Discord Feedback for this.

[Marqin]

@jhgg this proposition has been removed from uservoice without reason :/ Does this need any community help for changes in erlpack?