Ambiguous spec. How is an id constructed?

[07AyubHaris]

I apologize if this has already been answered, however I could not find any information regarding this on the internet.

In Obsidian, each id is a 64 bit hex number. This makes sense to me, because there is an extremely large number of possible id's whilst keeping a standard known length and contents.

Where my understanding of this falters is in the ambiguity of the spec. In Obsidian, if I set the node id to be any arbitrary string, (and update the corresponding edges), Obsidian handles this just fine, and the JSON Canvas spec does not mention at all the contents of an id (except for that each id must be unique).

What this means is that other applications who use this spec may generate id's in a manner different from Obsidian. As someone currently attempting to read and write this format in C, I was planning on storing the id in a 64 bit unsigned integer as strings can be quite annoying in C, however I am not sure If I should do this due to the ambiguity in the structure of an id.

I don't mind whether a change is made to the spec or not, I would just like clarification on this matter.

[lishid]

I think any ID that is unique within the document should be ok. Obsidian generates randomly, but will accept any string that is unique and consistent within the document.

[07AyubHaris]

Do you feel that this should be standardised? I understand that this may seem unneccecary, however I feel that standardising this to a 64 bit hex number would simplify the parsing of JSON Canvas files. As well as this, dealing with strings is just annoying, and for the purpose of identification, a number is just so much more convenient.

[lishid]

Not sure why this was closed but if you want to use a 64 bit hex that should work perfectly fine.I don't think we need to restrict it to that format, but we could put a recommendation of the format. It being a string is more for json object keys.