​
Semantic Context

The Mutable Web introduces a structure where each object—whether it’s a mutation or a document—follows a consistent lifecycle involving local edits and potential publication.

The process applies universally across all applications, mutations, or objects:

LocalChange => Publish (as Fork, as Update) => Pull Request

​
Key Stages of the Lifecycle

​
1. Local Change

When a user initiates an interaction, such as creating or editing an object, changes occur locally in their environment. This approach allows users to make multiple adjustments before deciding to make them public.

Visibility Settings During Local Changes:

  • Private: Accessible only via ID; not visible in search results or public lists.

  • Devel: Visible only in developer mode, ideal for testing and iteration.

  • Public: Fully visible and searchable by others.

This local-first approach ensures flexibility without risking unintended public exposure.

​
2. Publish (as Fork or Update)

Once satisfied with local changes, users can publish their modifications. The method of publication depends on ownership:

  • Fork: If the object was created by someone else, the user forks it to create an independent version.

  • Update: If the object is the user’s original creation, they can directly publish it as an update.

Context-Sensitive Publish Button: The Publish button dynamically adapts based on the object’s origin and state, offering the option to notify the original author via a notify origin checkbox.

​
Creating a Mutation from Scratch

Users can also create a new mutation without forking an existing one. In this scenario:

  • The mutation starts with a null ID.

  • Once published, it generates a unique ID.

​
3. Pull Request

Integrated into the Publish action, the Pull Request mechanism allows users to propose changes to the original author.

  • By selecting the notify origin option during publication, the original author is alerted about the proposed modifications.

  • This facilitates collaboration and iterative improvements.

This structured workflow ensures systematic interaction management, fostering a collaborative and user-centric environment.

​
Special Cases in the LifeCycle

​
Editing Your Own Mutation Without an Origin

When editing a mutation without an origin (not forked from another mutation):

  • Changes are treated as updates.

  • No local copy is created.

  • The ID remains unchanged.

​
Editing a Mutation with an Origin (Foreign Author)

When editing a forked mutation based on another author’s work:

  • Changes remain local until published.

  • Origin metadata is preserved.

  • A Publish as Fork operation is required to maintain the mutation’s history.

​
Publishing a Fork

When publishing a fork:

  • The original mutation remains unaltered.

  • The forked version receives a unique ID.

  • Forks can be further edited, published, or forked again.

​
Fork and Edit Lifecycle

Each mutation follows a lifecycle based on its origin and editing context:

1

Forking Someone Else’s Mutation

Create a new branch from an existing mutation for independent development.

2

Forking Your Own Mutation

Branch out versions of your mutation for different use cases (e.g., production vs. testing).

3

Creating a Mutation from Scratch

Start fresh with a new mutation, generating a unique ID upon publication.

4

Editing Your Own Mutation (No Origin)

Directly update your original mutation without creating a separate fork.

5

Editing Your Own Mutation (With Origin)

Modify a forked mutation, maintaining origin metadata for clarity and traceability.

This systematic approach ensures clarity and consistency across different mutation workflows.

The Mutable Web Lifecycle provides a robust structure for managing changes, fostering collaboration, and ensuring adaptability across diverse use cases.

Whether you’re an end-user, developer, or community contributor, understanding and following these workflows is key to building an efficient, decentralized, and adaptive internet.

Let’s create, share, and innovate—together.