Native Cross-Channel Object References, Linking, Embedding and Graph Behavior

Feature Requests
, , , ,
1

WHAT DO YOU RECOMMEND?

Allow objects residing in one Channel to be referenced, linked (@), embedded, and assigned to Object Properties from within a different Channel, without duplicating the object or merging channels.

HOW COULD IT BE DONE?

  1. Unified Object Search Picker: When inserting an inline link, embed, or selecting an object for a Property, the selector defaults to current in-channel objects as it does today.

  2. Global Query Trigger: Add a “Search all channels” toggle that lets you choose which channel to search (or a prefix search like @channel_name:) at the bottom of the picker to query across the entire personal graph.

  3. Scoped Search & Isolation: Keep local channel queries clean by suppressing out-of-channel objects from routine local searches unless a global search is explicitly invoked.

GRAPH & PERMISSION SPECIFICATIONS

  • Graph View Representation: Out-of-channel nodes in the graph should render as faded or dashed connection lines that extend exactly one hop (linking directly to the target object without expanding its full home-channel sub-graph into the current view).

  • Multi-User & Public/Private Permissions: If an object from a private channel is linked or shared within a public/collaborative channel:

    • Non-owners receive a read-only proxy view of the object.

    • The object owner retains granular controls to toggle public discussion or inline comments on and off for that referenced block.

REAL WORLD USE CASES

  • Domain Isolation without Data Duplication: Maintaining an isolated Engineering Log channel (with specialized object types like Components, Tools, and Schematics) alongside a general PKM channel (with Contacts and Notes). When documenting a project built as a gift for a friend, you can link your friend’s existing Contact object directly to a Recipient property in the engineering project without creating a duplicate contact.

  • Search Noise Reduction: Keeping specialized domains (like Worldbuilding or Technical Specifications) separate prevents clutter. Fictional characters (e.g., “Greg the Destroyer”) will not contaminate routine searches for work contacts (“Greg from Accounting”) in daily logs unless a global reference is explicitly requested.

WHY THIS MATTERS Channels currently act as hard physical walls rather than flexible contextual views. This forces users into an uncomfortable trade-off: either combine everything into a single bloated channel, or rely on convoluted workarounds to connect related information. Native cross-channel referencing preserves clean organizational boundaries while maintaining a unified, interconnected graph.

2

Yes, this is understandably a very desirable solution but it’s actually very complex to solve because of all the different architecture decisions and edge cases that would arise. Just to highlight a couple of points:

  1. This feature request requires object-level permissions, which is incredibly complex to implement. Users have encryption keys to channels, which grants access to everything inside. To have object-level permissions, that would need to be scoped more granularly. Additionally, in an object-based system, how far should it grant permissions? One document can theoretically have hundreds (if not thousands) of other objects linked to it: images, files, embeds, links, etc. Should one key to an object also grant access to view all the other links? One can see how this becomes complex with inline queries/views, etc.
  2. The different types/properties/etc. that exist in channels do not make it simple to just merge graphs and display them as overlaid and separate. There would be many conflicts and edge cases where the graphs don’t make sense. In simple cases it seems fine, but as graph complexity grows it becomes a whole different beast.

In short, the problem is that it’s very difficult to implement a solution like this in an end-to-end encryption and local-first environment. This is an interesting article in general, you can read the ‘Security and Access Control’ part to get an idea of why it’s complex.