Block reference to allow ((page-name#block-ref-name)) not just UUID

Per discord discussion, I request for block reference to allow ((page-name#block-ref-name)) not just UUID.

That ((page-name#block-ref-name)) is also globally unique, since page-name is globally unique and block-ref-name can easily be maintained as unique (even as just simple numeric sequence 1,2,3,…). The block-ref-name can also be automatically generated to be globally unique by using current unix timestamp in milliseconds such as 1632789645123. Hence the full block reference looking like ((page-name#1632789645123))

This would make recovery from broken block reference (for whatever reason) to be possible since page-name is manually recognizable and block-ref-name can be chosen to be recognizable or have timedate info in it.

The semantics/usage of the block reference could also be more similar to HTML id global attributes.


  1. In current Logseq v0.4.0, typing (( will automatically inserts closing )), as you continue typing text within the brackets such as “pennsylvania”, logseq will search the local graph for all blocks containing that word, and display them in a list.
  2. When you select one of the blocks, Logseq will generate a globally unique UUID of the format like 614800f3-e336-45e5-849e-fe64ea361d35.
  3. Then the code ((614800f3-e336-45e5-849e-fe64ea361d35)) will be inserted in the current block.
  4. And the code/attribude id:: 614800f3-e336-45e5-849e-fe64ea361d35 will be inserted in the target block.
  5. And Logseq will render the contents of the target block, embedded in the current block.
  6. According to uuidtools that UUID 614800f3-e336-45e5-849e-fe64ea361d35 is version 4 (random data based) and variant DCE 1.1, ISO/IEC 11578:1996

I agree. This is crucial also for interoperability with other applications, to make each reference recognizable by Obsidian etc.

Obsidian allows page-name#^block-ref-name inside [[]] . It requires ^ for some reason.

I tried inserting id:: my-custom-id in a block, just to see what happens. The text disappeared after exiting the edit, leaving the block empty, and wasn’t there when re-entering the edit. Upon searching for it with (()) in another block, it showed up as #{'my-custom-id'}, but clicking on it would return the UUID, and the block wouldn’t be rendered by {{embed}}. Then my-custom-id stopped showing up in the search.


Improving the interoperability issue mentioned above would be a big win. Allowing for custom block references would also allow users to treat blocks more like first class citizens. Instead, currently, if I want to have a link that is human readable in the markdown file, I’m required to make that a link to a page instead of a block.

One solution to this could be to allow aliases to function for blocks as well as pages. So any block that contains alias:: my-custom-block-id could be referenced with ((my-custom-block-id)), or even better, [[page-title#my-custom-unique-block-id]].

Not sure yet if allowing “block aliases” instead of allowing for custom block IDs feels like a hack, but it’s worth considering.

This is similar to thoughts I’ve had as well.

In my ideal note-taking environment, the note-to-note boundary should be allowed to be fluid, with the note-taking system not enforcing such boundaries. Especially, the file boundary should be abstracted away as far as possible. (The note <-> file-on-disk connection, for interoperability and future-proofing, could still be maintained.) Handling pages and blocks as similarly as possible would be a step in that direction.

What I write below is similar to what others have suggested above, but I’m taking the chance to present an overview and lay out the arguments.


Currently, LogSeq operates with a tree-structured hierarchy[1] with

  • pages for level 1, and
  • blocks for level 2…N.


* page A             1
  * block A-1        2
    * block A-1-I    3
    * block A-1-II   3
  * block A-2        2
* page B             1
  * block B-1        2

Linking to pages vs. blocks:

entity    level   referenced as
------    -----   -------------
page      1       [[title:: property of the page]]
block     2-N     ((block UUID))


This difference is, conceptually, somewhat arbitrary to me. I’d prefer to treat blocks and pages as similarly as possible. This is in line with @deniz notion of treating the blocks as first-class citizens.

Hence, ideally:

entity    level   can be referenced as
------    -----   --------------------
page      1       [[title:: property of the page]]
block     2-N     [[title:: property of the block]]


The link reference for pages is already kind of (allowed to be) separate from the page file name through the title:: and alias:: page properties. The same could be used for blocks - i.e., allowing reference by a title:: (or alias::) block property.


<page A file:>
title:: page A
* title:: block A-1
  some text of block A-1
<page B file:>
title:: page B
* first block of page B
* here, we could e.g. link to [[page A]] and [[block A-1]]

(The user has the option to define a title:: property for a block - UUIDs could also be used, as now.)

This would be the blank-slate ideal implementation. There’s probably aspects I haven’t thought of.

Also, I’m not sure how to handle title collisions, i.e. assuring titles for blocks and pages being globally unique. I guesse LogSeq already has to handle this for collisions on page titles, if defined with the title:: page property, or in any case for an alias:: colliding with another alias:: or page title. Some unified way of avoiding or handling such collissions could be used.

In practice, interoperability with Obsidian weighs heavily as well, and could be a strong reason to choose the Obsidian course rather than my ideal blank-slate suggestion.


  • All existing editors, even the web-based ones, have some hangover from file-based content management. Even with ability to cross-link to nodes inside a tree structure within files, the rigidity of file boundaries is still over-constraining, especially when one is trying to grapple with unfamiliar concepts during which the structure and links are constantly shifting.
  • It should take the concept of knowledge graph as far as possible. The foremost thing is to do away with files, and promote vertices (nodes) and links (relationships) to first-class status.

(from I actually grew really frustrated with existing solutions for organising notes: ... | Hacker News)

[1] a tree-structured hierarchy is defined as

every node is connected to
( (<= 1 parent node) AND
  (>= 0 child nodes)
1 Like

Great write up. Agree that abstracting the file away and treating everything as blocks is an important step for this type of note taking. My one caveat is to work to keep the md files human readable in plain text, otherwise you might as well be using a standard database.

Re: title collisions, namespacing the title of every block by the parent block (i.e. page for top level blocks) seems to be the way that makes the most sense to me. This also fits well with those who suggest the [[page-a#block-1]] block linking syntax.