Having UUIDs to reference data-blocks of Blender would help in some cases with interaction with third party tools, especially when relations between different types of data storage is needed, and handling renaming of data-blocks across those is not possible.

This design task is here to define what would be expected from such feature, and how various issues should be addressed.

See also this ML discussion.

Disclaimer: this is a draft design proposal currently.

Core Ideas

• UUIDs should be 'real' ones, 128bits long.
• UUIDs should be generated on demand, not systematically. This process is not free, and internal handling of data-blocks by Blender itself should not use them at all.
  • Think we should still store them as a systematic fixed chunk of data in the ID block in the .blend file though (being zeroed for non-generated ones), to ease their retrieval from third-party code 'parsing' .blend files?

Issues to Investigate

1. Collision and Uniqueness
   • UUIDs should be absolutely unique withing a .blend file. This would be easy to ensure. Linked data-block would not be concerned by this, since they belong to another .blend file.
   • UUIDs should be reasonably unique across .blend files.
     • Creating new IDs from existing ones (internal copy, appending from a library, creating proxies or overrides from linked data) should nullify the UUID of the new data-block.
     • 'Save file' operations explicitly creating a duplicate file (Save as, Save copy) should maybe enforce re-generating UUIDs?
     • .blend file duplication would be the main source of collision. Not sure how to deal with that case, besides offering the possibility of a manual re-generation of UUIDs by user?
     • If the 'file copy' case is solved, collision between different .blend files remains possible, though extremely unlikely.
2. Runtime IDs
   • Some system may generate a random number of data-blocks in a procedural way (e.g. from future geometry nodes evaluation.
     • Persistence of UUID in such IDs is probably not possible? We should then accept that it would need to be re-generated when nodetree re-create data-blocks?
     • This only concerns IDs that would be generated in Main database (and hence saved on disk), not runtime IDs.

Implementation Hints

• Search for existing implementations of UUIDs (e.g. in python).
• Using OS-provided tools should be preferred solution as much as possible.
• How should RNA (Py API) expose those 128bits UUIDs, as an array of 4 integers? An hexadecimal-encoded string?