In this system, hierarchy is inferred from the URL. Changing the URL reshapes how a document sits within that hierarchy, without actually moving it.

The URL is separate from the document title. For convenience, we auto-fill it from the title, but it can be edited freely. When you change the URL, you are only modifying the document’s path or slug — not its parent, not its directory, and not its relationships. This is useful when you want to refine the naming without reorganizing content.

Example:

Branching is a way to take a document and bring it into a new context — a different site, directory, or community — while preserving its history up to that point.

A branch copies all versions of the original document and creates a new, independent timeline. From that moment on, the two documents diverge: changes in one do not affect the other.

Because the document now lives in a new location, permissions are reset to match that destination. The original author may lose edit access, while new collaborators in that space gain control. In practice, this means the document becomes part of a different community, with its own goals and governance.

Today, branching behaves as a snapshot: you branch a specific version, and that version does not follow future updates from the original. In the future, we may support following upstream changes or rebasing, but that does not exist yet.

Branching should be used when you want to fork a document’s direction — to adapt it, reinterpret it, or evolve it under different ownership.

Branch Following , How to Branch a Document?

Moving a document changes its location in the hierarchy.

When a document is moved, it is placed under a new parent, and everything beneath it, child documents and comments, moves along with it. The document itself remains the same: same history, same identity, same permissions.

Conceptually, you can think of a move as a branch followed by deleting the original. But from the user’s perspective, it is simply a relocation.

Alex Burdiyan on Opportunities

Use move when the document belongs somewhere else, but you do not want to create a new version or break continuity.

Duplicating creates a brand new document using the content of an existing one.

Unlike branching, duplication does not carry over history, relationships, or context. It is a clean copy: no previous versions, no links to the original, no children, no comments. Just the content.

This is useful when you want to reuse a structure or template without any connection to the source. A common example is recurring documents like meetup events, where the format stays the same but the instance is entirely new.

Republishing is a concept we have considered, but it is not currently part of the system.

It is inspired by ideas like retweets or reposts, but for the open web, extending across sites and communities. Instead of creating a new version (like a branch), republishing would keep a single document identity that appears in multiple places.

In this model, the document would have the same ID, the same history, and the same permissions everywhere. Any update made in one location would automatically be reflected in all others. It would behave like a live mirror rather than a copy.

The key distinction is simple: branching creates divergence, while republishing would preserve unity.

If implemented, republishing would be the right choice when you want to distribute a document across multiple communities while maintaining a single source of truth.

How to Branch a Document?