and again - if you use clever tricks to reduce this, you increase the overhead to actually use the data.
get a celltower snooper on your phone and watch the data it shows - that's the metadata for your phone. SMS dragnet would need that for both phones, plus the message itself.
It's not an integer. But you can store it inside 64 bits. You can split it into country code and then number, or you can use 60 bits to store 18 digits and then use the top 4 bits to say how many leading 0s to keep/remove. Or other things. A 64 bit integer is enough bits to store variable length numbers up to 19 digits while remembering how many leading zeros they have.
If you want really simple and extremely fast to decode you can use BCD to store up to 16 digits and pad it with F nibbles.
> JSON
Most of this is unimportant. Routing path, really? And we don't need to store the location of a cell tower ten million times, we can have a central listing of cell towers.
I don't think we really need both phone number and IMEI but fine let's add it. Two IMEI means another 16 bytes. And two timestamps sure.
Phone number, IMEI, timestamp, cell tower ID, all times two. That's still well under 100 bytes if we put even the slightest effort into using a binary format.
> and again - if you use clever tricks to reduce this, you increase the overhead to actually use the data.
No no no. Most of the things I would do are faster than JSON.
a phone number is not a 64 bit integer, like, just off the top of my head, a phone number can start with "0"
and again - if you use clever tricks to reduce this, you increase the overhead to actually use the data.get a celltower snooper on your phone and watch the data it shows - that's the metadata for your phone. SMS dragnet would need that for both phones, plus the message itself.