Aug 27, 2026

Engineering

Aligned

Single parent constraint for nodes Nodes are defined to possess only one parent to prevent complex runtime conflict resolution scenarios.

Authority requirement for node creation Creating a name within a parent that points to a specific node requires authorization over both the parent and the target node.

Adoption of node ID terminology Terminology is standardized to use "node ID" instead of "iode" to simplify system description and align on a stable identifier.

Link creation and resolution strategy Links will be generated with all available context (node ID and path) at write-time, and resolution will follow a fallback hierarchy to handle conflicts.

Pretty paths are user-managed liability Pretty paths are designated as a liability for the space owner, and users assume responsibility for potential instability when choosing to publish or share these paths.

Redirect service for existing URLs Existing legacy URLs and name-spacing are supported through a separate link-shortening and redirect system rather than being embedded into the permanent data layer.

Optional naming for resource node blobs Resource node blobs are designed to support optional naming, enabling the creation of private documents without requiring human-readable paths.

Discontinue granular path-based capabilities Support for granular capabilities with paths is discontinued, requiring users to have full space-writer permissions to use legacy node IDs as parents or nodes.

We've updated the Decisions section using your feedback.

Let us know what you think: Helpful or Not Helpful

Next steps

[ ] [Eric Vicenti] Share Diagram Link: Share the TL Draw link with the team.

[ ] [Alexandr Burdiyan] Draft Data Model Document: Create a document summarizing the data model concepts and findings from the meeting.

[ ] [Horacio Herrera] Check link behavior: Investigate how comment links behave during resolution to confirm accurate target document redirection.

[ ] [Alexandr Burdiyan] Review Node ID: Read and analyze the artificial intelligence response concerning the implementation of random or non-forgeable node identifiers.

[ ] [The group] Resume Discussion: Reschedule the follow-up meeting to continue the discussion on node IDs and legacy data models at 3:00.

[ ] [Horacio Herrera] Fix Collection: Fix the collection implementation to address pending technical issues.

[ ] [Eric Vicenti] Assist Development: Assist Horacio Herrera with specific components of the collection changes.

Details

Did the screenshots in this section make your notes better or worse?

Hard Links and Runtime Conflict Resolution in Directory Models: Alexandr Burdiyan explained that they initially explored using Unix-style hard links to reduce the number of runtime conflicts and avoid having to determine a single parent node for documents that act as both directories and files (00:03:33). However, Alexandr Burdiyan noted that like Unix directories, their system cannot support multiple parents for a single node without introducing a separate concept of a directory ID. Eric Vicenti questioned the necessity of hard links when symbolic links or redirects could be used instead (00:02:29). Alexandr Burdiyan ultimately concluded that nodes must have a single parent, meaning the system still needs to handle these concurrency conflicts and permission inheritance correctly (00:05:02).

Migration and Challenges of the HM24 Path Replication Model: Eric Vicenti presented an issue with the HM24 model, where child refs duplicate the path names of their parents (e.g., "cars" saved inside "Ford" and "Mercedes" blobs). Eric Vicenti explained that renaming a parent requires manually renaming every recursive child and publishing multiple new refs and redirects, which is unreliable (00:08:08) (00:09:49). To transition to a new model where only the relative path name and a parent reference are stored, Eric Vicenti introduced the concept of an "orphan ref" (a named ref naming its parent without an explicit point) and proposed an "adoption ref" mechanism where an authorized writer could help link orphaned child nodes to a new parent during migration (00:10:43). Alexandr Burdiyan noted that the actual implementation points to an opaque node identifier rather than directly to "auto" (00:13:39).






Node Indirection, Permissions, and Non-Forgeable IDs: Alexandr Burdiyan and Eric Vicenti discussed the necessity of using stable, opaque node identifiers (referred to interchangeably as node IDs or iodes) to allow independent renames and moves within the hierarchy without breaking references (00:15:36) (00:20:58). Alexandr Burdiyan raised concerns about permission enforcement and preventing unauthorized users (such as "Alice" creating refs in a shared "cars" folder) from forging or linking to unauthorized documents like "alien" (00:17:38) (00:24:41). To prevent forgery, Alexandr Burdiyan suggested that a node's permanent identifier should be derived from the content or Content Identifier (CID) of its initial creation ref rather than being a random, easily forged UUID (00:40:12).






Unifying References, Tombstones, and Redirects into a Node Concept: Eric Vicenti proposed renaming "ref v2" to "node" and integrating tombstones and redirects directly into this new node concept to streamline terminology and data modeling (00:29:10) (00:31:27). Alexandr Burdiyan described how a node blob contains a target (which can point to changes, a tombstone, or a redirect), a relative path name, and a parent (consisting of a space and a node ID) (00:30:26). They discussed how moving a node requires creating a redirect at the old location or creating a new node, with hierarchical lookups always proceeding from the top level down (00:36:18) (00:38:21).






Handling Comments and Universal Resource Behavior: Eric Vicenti stated that the goal is to design a universal resource behavior that supports documents, comments, and future data types rather than redesigning document behavior from scratch (00:46:31). Horacio Herrera asked whether comments should point to moved documents or node IDs. Eric Vicenti and Horacio Herrera agreed that targeting the stable node ID is preferable so that comments, children, and capabilities move together as an all-or-nothing unit, though it should ultimately be up to the author whether to preserve or ditch them (00:48:59).






Link Stability, Human-Readable Paths, and Resolution Precedence: Horacio Herrera and Eric Vicenti discussed the complexities of link addressing, noting that while human-readable paths are useful, stable node IDs prevent links from breaking when documents are renamed or moved (00:51:32). Alexandr Burdiyan and Eric Vicenti highlighted the trade-offs of combining names, node IDs, versions, and "latest" flags in URLs, which creates multiple possible link combinations (00:53:34). Eric Vicenti suggested capturing as much resolution context as possible when a link is written, while Alexandr Burdiyan and Eric Vicenti noted that the system may need a fallback resolution protocol or a way to prompt the user if a named path and a node ID diverge due to a conflict (00:56:48).






Pretty Paths and Slugs for Addressing: The participants discussed how addressing systems should function and how to save links in permanent data while planning to handle potential conflicts later (00:58:29). Alexandr Burdiyan suggested adopting an approach similar to Notion, where default links consist of a node ID prefixed with a human-readable slug. Horacio Herrera noted that slugs can change based on the title, and Eric Vicenti considered this approach elegant and familiar to users (00:59:40). Alexandr Burdiyan and Eric Vicenti discussed adding a share button to let users generate pretty links while explicitly warning them that pretty paths carry liabilities and are not guaranteed to be unbreakable or stable. The team agreed that pretty paths should be treated as a liability for space owners, placing the responsibility on them if they choose to share them (01:00:33).

Arbitrary Redirects and Link Shortening Service: The meeting addressed the requirement to support existing URLs and provide arbitrary redirects for domains and sites. Eric Vicenti proposed supporting existing URLs through a separate link shortening service and a redirect database mapping pretty URLs to node IDs as a layer on top of permanent data (01:01:33). Horacio Herrera compared this capability to how GitHub stores redirects when a repository is renamed. Alexandr Burdiyan and Eric Vicenti debated whether namespacing and redirects should be baked into the lowest level or handled via a higher-level redirect system (01:02:36). The consensus was that the redirect table could be structured as a document, though the exact storage mechanism required further definition (01:03:34).

Preserving User Content and Legacy Links: The team evaluated the importance of ensuring that existing user content and links are not broken during system updates. Alexandr Burdiyan strongly opposed breaking user content, emphasizing the goal of protecting links for all users, including inactive or historical authors (01:04:33). Eric Vicenti raised the theoretical scenario of an author who is no longer active, while Alexandr Burdiyan noted that paths are part of the ontology and are valuable for internal navigation, similar to internal link shorteners used by companies. The participants agreed on the importance of preserving legacy content and links without abandoning historical user data (01:05:22).






Comment Addressing and URL Structure: The discussion turned to handling comments as documents without human-readable paths and managing complex URL structures. Eric Vicenti argued that comments require stable node IDs even without human-readable paths. Alexandr Burdiyan explained that comments target external work using a colon-comments suffix linked via document IDs (01:06:25) (01:09:15). Eric Vicenti highlighted that comment URLs include the author's account ID and timestamp ID, sometimes hidden beneath target document IDs (01:07:16). Horacio Herrera and Eric Vicenti discussed the complexities of resolving comment links copied from reference documents instead of target documents (01:08:17), and Alexandr Burdiyan noted the syncing challenges this creates (01:10:53). The team agreed that the generic resource node blob should support optional naming, allowing documents like private documents and comments to receive stable IDs without requiring human-readable paths (01:11:55).






Node ID Generation and Migration from Legacy Data: The group examined how to fit existing old graphs and data into the new runtime model. Alexandr Burdiyan proposed hashing the path as the node ID, the directory name as the parent, and the base name as the name. Eric Vicenti noted that this approach conflicts with how node IDs should work if they need to be explicit (01:13:50), prompting Alexandr Burdiyan to mention checking with their agent regarding random or unforgeable IDs. The participants questioned whether node IDs should always be explicit and whether unforgeable node IDs are necessary to prevent security risks (01:14:58).






Security Risks and Node ID Forging: The participants assessed the risk of node ID forging and how to protect against unauthorized access (01:16:08). Alexandr Burdiyan defined forging as a user claiming a node ID they lack access to by placing it in an accessible directory (01:19:31). Eric Vicenti questioned how a user could edit a node without prior access to the current node and destination parent. Alexandr Burdiyan and Eric Vicenti debated whether checking permissions against the current node ID and validating user access to current versions is sufficient to prevent unauthorized modifications (01:20:45). The team concluded that accepting new nodes requires validating user permissions against the current node ID, while unknown node IDs indicate newly created nodes (01:22:37).






Syncing Order and Revocation Risks: The group discussed peer-to-peer syncing order and the risk of delayed revocation information. Horacio Herrera and Eric Vicenti explored the complications of connecting with untrusted peers who have partial or outdated views due to revocations (01:23:43). Eric Vicenti explained that peers must communicate with as many diverse peers as possible to obtain revocation details quickly, while Alexandr Burdiyan noted that third-party observers lacking space ownership need a reliable way to identify bad blobs. The participants acknowledged that revocation handling is an inherent challenge in peer-to-peer models, requiring broad peer communication to uncover updated state information (01:25:29).

Reusing Legacy Node IDs and Limitations: The meeting addressed whether old refs and legacy node IDs can be reused in the new node blob format. Alexandr Burdiyan argued that without unforgeable IDs, resolving conflicts between competing claims on the same node ID is difficult, while Eric Vicenti suggested using content identifiers of blobs or timestamps as a salt. Alexandr Burdiyan concluded that safely reusing legacy nodes in the new node blob format is too risky. The team decided not to allow legacy node IDs to be reused in the new node blob format, restricting them to respecting the old format solely during indexing (01:27:28) (01:29:36).






Legacy Sub-Document Permissions and Next Steps: The participants reviewed how to manage legacy capabilities with paths and sub-document permissions during the transition. Alexandr Burdiyan stated that users with path-specific capabilities giving access only to certain documents would lose them, and any refs requiring such capabilities would become invalid (01:31:20) (01:33:03). Horacio Herrera and Eric Vicenti agreed that considering the small user base, they could inform affected users directly if issues arose. Alexandr Burdiyan added that using legacy node IDs as parents requires being a full space writer. Eric Vicenti proposed taking a lunch break and reconvening later. The team agreed to assume full space writer permissions for legacy node usage, accept the loss of path-specific capabilities for edge cases, and schedule a follow-up meeting at 3:00 PM (01:32:14) (01:33:54).






You should review Gemini's notes to make sure they're accurate. Get tips and learn how Gemini takes notes

How is the quality of these specific notes? Take a short survey to let us know your feedback, including how helpful the notes were for your needs.