3 ms·

You'd like to mandate that all stores keep a permanent record of every purchase ever made?

by fwip 7y ago

mynameisvlad 7y ago
> (or gzipped json of it) Parent comment already covered that case. If the content is included in the code, it doesn't need to be stored anywhere. Nobody said permanent, either. It'd be reasonable that the data expires after a certain amount of time. Preferable, even, for limiting exposure in the event of a breach. Additionally, while I don't think this is the case for grocery stores, most stores do actually keep a record of every purchase made. The data and aggregated analytics on said data is huge, and it allows for things like faster returns and personalized coupons/recommendations.
anoncake 7y ago
No need for that. 30 bits to represent the 13 digit IAN. 3 bytes for prices up to 167772.16. If you frequently buy things more expensive than that, just have one of your servants transcribe the recipe to your favorite format. 1 byte for the number of items. If you buy more than 255 of one thing, we'll just add another line to the recipe. That's 60 bits per line item. A QR code holds up to 23,648 bits. That makes up to 394 line items per QR code, without compression, which ought to be enough for anyone. If you do buy more than that, the POS crashes^H prints another QR code.
- fwip 7y ago
  That sounds solid, thanks for the detailed breakdown.
- uponcoffee 7y ago
  >3 bytes for prices up to 167772.16. If you frequently buy things more expensive than that, just have one of your servants transcribe the recipe to your favorite format. >1 byte for the number of items. If you buy more than 255 of one thing, we'll just add another line to the recipe. You could split prices greater than 167772.16 into chunks, delimited by using zero for the number of items in the subseqent line items.
  - anoncake 7y ago
    I think it's simpler to make the field variable length. The same is necessary for the count field, buying >= 256 grams of something is common.

You'd like to mandate that all stores keep a permanent record of every purchase ever made?

by fwip 7y ago

You'd like to mandate that all stores keep a permanent record of every purchase ever made?

> (or gzipped json of it) Parent comment already covered that case. If the content is included in the code, it doesn't need to be stored anywhere. Nobody said permanent, either. It'd be reasonable that the data expires after a certain amount of time. Preferable, even, for limiting exposure in the event of a breach. Additionally, while I don't think this is the case for grocery stores, most stores do actually keep a record of every purchase made. The data and aggregated analytics on said data is huge, and it allows for things like faster returns and personalized coupons/recommendations.

anoncake 7y ago

No need for that. 30 bits to represent the 13 digit IAN. 3 bytes for prices up to 167772.16. If you frequently buy things more expensive than that, just have one of your servants transcribe the recipe to your favorite format. 1 byte for the number of items. If you buy more than 255 of one thing, we'll just add another line to the recipe. That's 60 bits per line item. A QR code holds up to 23,648 bits. That makes up to 394 line items per QR code, without compression, which ought to be enough for anyone. If you do buy more than that, the POS crashes^H prints another QR code.

fwip 7y ago
That sounds solid, thanks for the detailed breakdown.
uponcoffee 7y ago
>3 bytes for prices up to 167772.16. If you frequently buy things more expensive than that, just have one of your servants transcribe the recipe to your favorite format. >1 byte for the number of items. If you buy more than 255 of one thing, we'll just add another line to the recipe. You could split prices greater than 167772.16 into chunks, delimited by using zero for the number of items in the subseqent line items.
- anoncake 7y ago
  I think it's simpler to make the field variable length. The same is necessary for the count field, buying >= 256 grams of something is common.