IMO, the note metadata are a good place for the note‘s ID, e.g. like this:
---
id: NOTEID
---
Ideally, this ID would be provided by the app itself. But even w/o this I think it‘s good if each note has one, and other tools/plugins can build upon this.
On a sidetrack (about IDs): For my own use case, I wanted to base my note IDs on timestamp-based IDs (and not UUIDs). This is since timestamp-based IDs have the huge advantage that they can be generated manually, w/o the need for a machine. However I’ve wanted millisecond precision to allow for automated ID generation (e.g. on import) w/o the need for manual intervention. Still, the IDs shouldn’t get too long, and stay somewhat readable/recognizable.
To suit the above, my IDs take the note’s creation date (but any date will suffice) with millisecond precision in its reverse base32-encoded form (after Crockford). For comparison, here’s an example:
1) UUID: 9B5D722E-4C58-441F-997F-C086B097E2C7
2) shorter timestamp: 202104130930
3) longer timestamp: 20210413093059456
4) my ID based on (3): 1T5F-CGC0-8PQJ
The encoding keeps the IDs short while still maintaining precision. While these IDs are not as intuitive as pure date-based IDs, I find them more legible than the longer timestamps – the inserted hyphens & the 4char-blocks (together with the fact that it’s digits and letters) actually make them more recognizable for me. In any case, I find them more manageable than UUIDs and sufficient for a PKM use case. And since this system is based on timestamps, these can be also used (if notes are generated manually or externally).