Drop UUID for blocks in favor of short codes

Feedback Feature Requests
1

Logseq’s block IDs are UUIDs (Universally Unique Identifiers) that can identify ~5 × 10³⁶ blocks (a number with 36 digits), but why does it need to identify so many blocks?

Blocks are unique to a graph anyway and assigned by Logseq itself, it’s not like it is a massive distributed system that needs different independent sources to always adopt different IDs without coordination.

Even just alphanumeric codes with 5 digits can identify 60 millions of blocks and indeed it’s more or less what Amazon uses for its products and YouTube for its videos.

UUIDs for blocks are really a pain from a UX point of view:

This is a block reference: ((64ff6f0e-71d9-4a46-a1f5-ad6d3ff264dd)).

    Vs

This is a block reference: ((e3nf9)).

For more check:

2

Dropping is too drastic. Could make the first few digits work the same.

1 Like
3

Abstract codes are worthless in a markdown frame of mind. They are not human readable. Better with a format like in the bible. GRAPH/page name/bullet number/sentence would be better. I dont care about the lenght. I care about a human readable format.

4

@kennethaar updating potentially tons of block references every time that a block is moved is not feasible. Imagine adding a block at the top of many blocks that are referenced somewhere else: each referenced block is moved, its number change and so every reference must be updated. And this would work only in Logseq, that would care of updating the references, and editing made in other apps would break the references for the mechanism I just described.

5

Perhaps. As it is now I have lost/broken my references several times and just have to give up on ever finding out where the reference was pointing to. So for me references as is are not a feasible solution either.

6

With UUID (and short codes) you can search the reference with external tools that support searching multiple files (and this alone is another advantage compared to paths). What probably happened is deleting blocks without noticing that they were referenced and it can happen if they are hidden in a collapsed block that get deleted. Unfortunately Logseq doesn’t prompt the user with a confirmation dialog when referenced blocks are going to be deleted.

7

Searching for a code wil not give the same advantage as a “url”, since it does not give any information about where it pointed. A hybrid would also work. “Page name/shortcode” would still gove me a pointer as to where I can look.

8

Again, blocks are not tied to a page, so when you move a block you would need to update every “Page/shortcode”. When you move blocks with an external editor, you would need to update the ID manually: Drop UUID for blocks in favor of short codes - #4 by alex0

Instead you may want a Logseq LSP (language server protocol) that let you see where a block reference points to in other editors. There is an experimental one that supports it:

For editors that don’t support LSP there is still the manual search as a fallback.