Storage format

[pciavald]

One of the challenges working with NFC tags is to future-proof the organization of data in its memory.

While NFC chips are capable of addressing values by block for fast reading, the memory can also be used as a whole where very fast reading may not be a requirement.

Looking at the tradeoff between speed and the furure-proofing of data organization, I think that for a NFC on a spool, reading speed is not a priority. Whether the spool is read in 0.2s or 2s in my opinion does not make a huge difference in usage, if that allows for future compatibility.

There are many ways to look at the organisation of data in a constrained memory. On my side I'm looking at 2 standards: Protobuf and IPLD. Both take a data format spec and data in any kind of format or language, and output a space-optimized representation of this data.

Protobuf advantages:

• widely supported and common
• probably more compact

Protobuf disadvantages:

• data slots for legacy data must be kept reserved to preserve readability of legacy content
• explicit data slot numbering
• maintained mostly by google, known to kill projects on their own agenda

IPLD advantages:

• most modern view on data interoperability
• inherent mechanisms to link to other data through IPFS (e.g. printing processes or datasheets)
• spec versioning and upgrades supported by the tooling
• maintained by many decentralized organizations

IPLD disadvantages:

• still early, small community and basic tools
• mostly oriented to golang for now

My proposition is to use the NFC's memory as a whole, storing data as per a data spec, instead of allocating specific block numbers for specific data, which is both inefficient and hard to evolve.