Version: 0.1 (Draft)

Author: annnemnemosyne

Status: Working document — intended to evolve through community feedback

This document was composed using Anthropic's Opus 4.6. along with my own modifications and additions. I fed the model all of my writings so far in addition to many of my private notes that I've never posted. I worked with the model to flesh out some of the main concepts and reviewed and edited it carefully to ensure that my intent has been captured and represented well.

In this document, I describe MapDapps: a protocol for building a decentralized digital map of the world through composable, community-governed layers of spatial data. I refer to The Map as the sum of all contributions to the project.

This specification will give me something tangible to point to when referring to the protocol that the Map runs on. The real work will be developing MapDapps themselves to interface with and build the layers the Map will be composed of.

I also reference DAOs a lot. Yes, I am referring to Decentralized/Digital Autonomous Organizations. I still think there are some neat use cases for these types of governance structures, especially at the hyper-local level. This may seem tired or outdated, but it was what I had to work with several years ago when I started this project and I kept with that language in this document. If that bothers you, swap out "DAO" with "groups of people coordinating" or something. My point is, there are gaps in this protocol and the applications that will run on it that will require coordination at the social layer. Different solutions might fill these gaps, and oldschool DAOs are just one possibility.

I will not accept any Metaverse smaller than a Map of the entire world that is owned by all of humanity.

The Map is not a product. It is the sum of all its layers.

This document defines how layers — the fundamental unit of the Map — are identified, structured, composed, and trusted. It is organized into two tiers:

• Required Spec: The minimum set of constraints that all layers must satisfy in order to be composable with other layers. These are non-negotiable. Without them, the Map cannot exist as a coherent system.

• Recommended Conventions: Optional but strongly encouraged patterns that make the ecosystem more useful, interoperable, and trustworthy. DAOs, applications, and communities may adopt these conventions selectively based on their needs.

The goal is to define as little as possible at the protocol level while ensuring that layers created by independent actors — individuals, games, DAOs, corporations, governments — can be meaningfully overlaid, referenced, and explored together.

A layer is a collection of geospatial features — points, lines, and polygons — anchored to coordinates in the real world, along with metadata describing those features.

A layer may represent almost anything: roads and buildings traced from satellite imagery, hiking trails recorded by GPS, businesses and their hours of operation, public art installations, fictional game objects pinned to real locations, sensor readings, historical annotations, community resources, or personal notes visible only to their creator.

No one entity owns the Map, and no one entity defines what belongs on it. Anyone may create a layer. Anyone may share a layer. The Map emerges from the overlap.

These are the hard constraints. A data structure that does not satisfy these requirements is not a Map layer.

All layers must use a common coordinate reference system: WGS 84 (EPSG:4326). This is the same coordinate system used by GPS and by virtually every major mapping platform in existence.

Coordinates are expressed as latitude/longitude pairs in decimal degrees. Altitude, where relevant, is expressed in meters above the WGS 84 ellipsoid.

Rationale: A shared spatial reference is the single most important property of the Map. Without it, layers cannot be overlaid. WGS 84 is the universal standard. There is no reason to deviate from it.

Each layer must have two forms of identity:

• Layer ID: A persistent, globally unique identifier that refers to the layer across its entire lifecycle, regardless of how its content changes over time. This may be implemented as a public key, a decentralized identifier (DID), an ENS name, or any other system that provides persistent, non-colliding identifiers without requiring a central registry.

• State Hash: A content-addressable hash of the layer's current state — its complete set of features, metadata, and provenance records at a given point in time. This allows any party to verify the integrity of a layer's data without trusting the host.

The Layer ID points to the current State Hash. When a layer is updated, the State Hash changes but the Layer ID remains the same. Historical State Hashes should be retained to support versioning and auditability.

Rationale: Persistent identity allows layers to be referenced, subscribed to, and discussed as stable entities. Content-addressable state hashes allow trustless verification. The combination gives us both human-usable naming and cryptographic integrity.

Every feature on a layer must include, at minimum:

Features may carry arbitrary additional metadata as key-value pairs. The required spec imposes no constraints on what metadata a feature may include — that is the domain of recommended conventions and application-level schemas.

Rationale: Stable feature IDs enable cross-layer referencing. Geometry types and coordinates are the minimum needed for spatial rendering. Timestamps are the minimum needed for conflict resolution downstream. Everything else is left open.

Every layer must include the following metadata:

Field descriptions:

• layer_id — The persistent, globally unique identifier for the layer. This is the layer's stable "name" in the system — it remains the same even as the layer's content changes over time. As described in Section 3.2, this could be implemented as a public key, a decentralized identifier (DID), an ENS name, or any other system that provides persistent, non-colliding identifiers without requiring a central registry.

• state_hash — A content-addressable hash of the layer's current data — its complete set of features, metadata, and provenance records at a given point in time. This serves as a cryptographic fingerprint of the layer's current state. Anyone can use this hash to verify they have an unaltered copy of the layer without trusting the host. Every time the layer is updated, the state hash changes. Historical state hashes should be retained to support versioning and auditability.

• name — A human-readable label for the layer. The layer_id may be a long hex string or a DID that is not meaningful to a human reader. The name is what users and applications display. For example: "Portland Hiking Trails" or "Shibuya Street Art Layer."

• created_at — Timestamp of when the layer was first created. This supports provenance — knowing when a layer came into existence helps downstream consumers assess its history, maturity, and relevance.

• updated_at — Timestamp of the most recent modification to the layer, whether a feature was added, edited, or removed. This is critical for conflict resolution: when two layers describe the same real-world feature differently, recency is one of the simplest and most common tiebreakers available to downstream consumers.

• crs — The coordinate reference system the layer uses. In the required spec, this must always be EPSG:4326 (WGS 84 — the standard GPS coordinate system using latitude and longitude in decimal degrees). Including this field explicitly in the metadata allows any application reading the layer to confirm its coordinate system without ambiguity. It also future-proofs the spec: if a future version ever permits alternative coordinate systems, the field is already in place.

Layers relate to each other in three fundamental ways. These are the primitives of the Map's composability.

The default composition mode. Two or more layers are rendered on top of each other by a client application. No coordination between layer creators is required. No data is merged. Each layer retains its own identity, governance, and provenance.

Overlay is what makes the Map a Map rather than a collection of isolated datasets. A user opens an application and selects which layers they want to see. The application renders them together in a shared viewport. That's it.

At the spec level: Overlay requires nothing beyond a shared coordinate reference system (Section 3.1). If two layers use WGS 84, they can be overlaid.

A feature on one layer explicitly points to a feature on another layer. This creates a semantic link: "this feature is about that feature."

Examples:

• A review layer references a restaurant feature on a business directory layer.

• A historical annotation layer references a building feature on an infrastructure layer.

• A game object layer references a landmark feature on a base geography layer.

At the spec level: A reference is expressed as a pair: (target_layer_id, target_feature_id). The referencing feature stores this pair as part of its metadata. The referenced feature does not need to know it is being referenced.

This is intentionally one-directional. A feature cannot prevent other layers from referencing it, just as a website cannot prevent other websites from linking to it. Governance over how references are displayed or weighted is an application-level concern.

A fork is a snapshot of an existing layer that becomes a new, independent layer. The forked layer has its own Layer ID and its own governance, but retains a provenance link to the source layer and the State Hash at the time of forking.

Forking is how the Map evolves. A DAO may fork a neglected layer to maintain it under new governance. A game may fork a base geography layer to create a fictional variant. A community may fork a regional layer to establish different editorial standards.

At the spec level: A forked layer must include:

After forking, the new layer is fully independent. It may diverge arbitrarily from the source. The provenance link is informational, not operational — it does not create any dependency or synchronization obligation.

These are not required by the spec. They are patterns that the community is encouraged to adopt to make the ecosystem more interoperable, trustworthy, and useful.

While the required spec allows arbitrary metadata on features, applications and DAOs are encouraged to adopt shared schema conventions for common feature types. A community-maintained schema registry could define standard fields for categories such as:

• Physical infrastructure: roads, paths, buildings, bridges (fields: surface type, width, access restrictions)

• Points of interest: businesses, parks, landmarks (fields: name, category, hours, contact)

• Environmental: terrain, water features, vegetation (fields: type, seasonality)

• Cultural: art, memorials, historical markers (fields: artist, date, description, media links)

Adopting shared schemas is voluntary but increases the value of a layer by making it more interoperable with applications and other layers that use the same conventions.

The required spec mandates timestamps on features. At the convention level, layers are encouraged to attach richer provenance to each feature:

Richer provenance enables better downstream filtering, conflict resolution, and trust evaluation.

A DAO or governing body may issue attestations for layers or individual features that meet its standards. An attestation is a signed statement that says: "This governance body has reviewed this data and considers it accurate according to our criteria."

Attestations create a trust layer on top of the Map without requiring the protocol to make quality judgments. Applications can let users filter by attestation: "show me only layers attested by my local city DAO" or "show me everything, attested or not."

Attestation standards are set by the attesting body, not by the protocol. A rigorous city DAO may require in-person field validation. A casual gaming community may attest based on redundancy of player-generated data. Both are valid. The protocol's job is to ensure that attestations are cryptographically verifiable and that their governance source is transparent.

At the protocol level, there are no conflicts. Two layers may describe the same real-world location differently, and both are valid within their respective layers. Conflict only arises when a downstream consumer — an application, a DAO, or a user — attempts to compose a unified view from multiple layers.

Recommended strategies for conflict resolution include:

• Recency: Prefer the most recently updated feature.

• Attestation weight: Prefer features from DAO-attested layers.

• Redundancy: Prefer features that are corroborated across multiple independent layers.

• User preference: Let the user choose which layers to trust.

• Arbitration: For disputes that matter, defer to a decentralized arbitration protocol or to the governance body of the relevant DAO.

The spec does not prescribe any of these strategies. It only ensures that layers carry enough metadata (timestamps, provenance, attestations) to make informed resolution possible.

The following concerns are real and important, but are intentionally excluded from this specification. They belong to the application layer, the governance layer, or to future work.

• Storage and hosting. Where layer data physically lives — IPFS, Arweave, a traditional server, a rollup — is not a protocol concern. The spec requires content-addressable hashing for integrity verification, but does not mandate a storage backend.

• Proof of location. How to verify that a contributor was physically present when adding a feature is an active area of research and is not yet mature enough to standardize. The provenance convention (Section 5.2) provides a field for verification status, but the mechanisms are left to implementers.

• Token economics. How contributors are compensated — if at all — is a governance decision, not a protocol decision. Different DAOs and games will have different models.

• Rendering and visualization. How layers are displayed to users — cartographic styling, 3D rendering, AR overlays — is an application concern. The spec defines data structure, not presentation.

• Access control implementation. The spec requires layers to declare their access level (public, permissioned, private) but does not prescribe how permissions are enforced. Encryption, token-gating, and traditional access control lists are all valid implementations.

The Map Layer Composability Model defines the minimum conditions under which independently created spatial layers can coexist as parts of a shared, global Map.

The required spec is small by design. Shared coordinates. Persistent identity with verifiable state. Minimal feature structure. Three composition primitives: overlay, reference, fork.

The recommended conventions are expansive by invitation. Shared schemas. Rich provenance. DAO attestations. Conflict resolution strategies. These are the tools that will make the Map useful, trustworthy, and alive — but they emerge from the community, not from the protocol.

The Map is not built from the top down. It is assembled from the bottom up, layer by layer, by anyone who chooses to contribute. This spec exists to make that possible.

Version: 0.1 (Draft)

Author: annnemnemosyne

Status: Working document — intended to evolve through community feedback

This document was composed using Anthropic's Opus 4.6. along with my own modifications and additions. I fed the model all of my writings so far in addition to many of my private notes that I've never posted. I worked with the model to flesh out some of the main concepts and reviewed and edited it carefully to ensure that my intent has been captured and represented well.

In this document, I describe MapDapps: a protocol for building a decentralized digital map of the world through composable, community-governed layers of spatial data. I refer to The Map as the sum of all contributions to the project.

This specification will give me something tangible to point to when referring to the protocol that the Map runs on. The real work will be developing MapDapps themselves to interface with and build the layers the Map will be composed of.

I also reference DAOs a lot. Yes, I am referring to Decentralized/Digital Autonomous Organizations. I still think there are some neat use cases for these types of governance structures, especially at the hyper-local level. This may seem tired or outdated, but it was what I had to work with several years ago when I started this project and I kept with that language in this document. If that bothers you, swap out "DAO" with "groups of people coordinating" or something. My point is, there are gaps in this protocol and the applications that will run on it that will require coordination at the social layer. Different solutions might fill these gaps, and oldschool DAOs are just one possibility.

I will not accept any Metaverse smaller than a Map of the entire world that is owned by all of humanity.

The Map is not a product. It is the sum of all its layers.

This document defines how layers — the fundamental unit of the Map — are identified, structured, composed, and trusted. It is organized into two tiers:

• Required Spec: The minimum set of constraints that all layers must satisfy in order to be composable with other layers. These are non-negotiable. Without them, the Map cannot exist as a coherent system.

• Recommended Conventions: Optional but strongly encouraged patterns that make the ecosystem more useful, interoperable, and trustworthy. DAOs, applications, and communities may adopt these conventions selectively based on their needs.

The goal is to define as little as possible at the protocol level while ensuring that layers created by independent actors — individuals, games, DAOs, corporations, governments — can be meaningfully overlaid, referenced, and explored together.

A layer is a collection of geospatial features — points, lines, and polygons — anchored to coordinates in the real world, along with metadata describing those features.

A layer may represent almost anything: roads and buildings traced from satellite imagery, hiking trails recorded by GPS, businesses and their hours of operation, public art installations, fictional game objects pinned to real locations, sensor readings, historical annotations, community resources, or personal notes visible only to their creator.

No one entity owns the Map, and no one entity defines what belongs on it. Anyone may create a layer. Anyone may share a layer. The Map emerges from the overlap.

These are the hard constraints. A data structure that does not satisfy these requirements is not a Map layer.

All layers must use a common coordinate reference system: WGS 84 (EPSG:4326). This is the same coordinate system used by GPS and by virtually every major mapping platform in existence.

Coordinates are expressed as latitude/longitude pairs in decimal degrees. Altitude, where relevant, is expressed in meters above the WGS 84 ellipsoid.

Rationale: A shared spatial reference is the single most important property of the Map. Without it, layers cannot be overlaid. WGS 84 is the universal standard. There is no reason to deviate from it.

Each layer must have two forms of identity:

• Layer ID: A persistent, globally unique identifier that refers to the layer across its entire lifecycle, regardless of how its content changes over time. This may be implemented as a public key, a decentralized identifier (DID), an ENS name, or any other system that provides persistent, non-colliding identifiers without requiring a central registry.

• State Hash: A content-addressable hash of the layer's current state — its complete set of features, metadata, and provenance records at a given point in time. This allows any party to verify the integrity of a layer's data without trusting the host.

The Layer ID points to the current State Hash. When a layer is updated, the State Hash changes but the Layer ID remains the same. Historical State Hashes should be retained to support versioning and auditability.

Rationale: Persistent identity allows layers to be referenced, subscribed to, and discussed as stable entities. Content-addressable state hashes allow trustless verification. The combination gives us both human-usable naming and cryptographic integrity.

Every feature on a layer must include, at minimum:

Features may carry arbitrary additional metadata as key-value pairs. The required spec imposes no constraints on what metadata a feature may include — that is the domain of recommended conventions and application-level schemas.

Rationale: Stable feature IDs enable cross-layer referencing. Geometry types and coordinates are the minimum needed for spatial rendering. Timestamps are the minimum needed for conflict resolution downstream. Everything else is left open.

Every layer must include the following metadata:

Field descriptions:

• layer_id — The persistent, globally unique identifier for the layer. This is the layer's stable "name" in the system — it remains the same even as the layer's content changes over time. As described in Section 3.2, this could be implemented as a public key, a decentralized identifier (DID), an ENS name, or any other system that provides persistent, non-colliding identifiers without requiring a central registry.

• state_hash — A content-addressable hash of the layer's current data — its complete set of features, metadata, and provenance records at a given point in time. This serves as a cryptographic fingerprint of the layer's current state. Anyone can use this hash to verify they have an unaltered copy of the layer without trusting the host. Every time the layer is updated, the state hash changes. Historical state hashes should be retained to support versioning and auditability.

• name — A human-readable label for the layer. The layer_id may be a long hex string or a DID that is not meaningful to a human reader. The name is what users and applications display. For example: "Portland Hiking Trails" or "Shibuya Street Art Layer."

• created_at — Timestamp of when the layer was first created. This supports provenance — knowing when a layer came into existence helps downstream consumers assess its history, maturity, and relevance.

• updated_at — Timestamp of the most recent modification to the layer, whether a feature was added, edited, or removed. This is critical for conflict resolution: when two layers describe the same real-world feature differently, recency is one of the simplest and most common tiebreakers available to downstream consumers.

• crs — The coordinate reference system the layer uses. In the required spec, this must always be EPSG:4326 (WGS 84 — the standard GPS coordinate system using latitude and longitude in decimal degrees). Including this field explicitly in the metadata allows any application reading the layer to confirm its coordinate system without ambiguity. It also future-proofs the spec: if a future version ever permits alternative coordinate systems, the field is already in place.

Layers relate to each other in three fundamental ways. These are the primitives of the Map's composability.

The default composition mode. Two or more layers are rendered on top of each other by a client application. No coordination between layer creators is required. No data is merged. Each layer retains its own identity, governance, and provenance.

Overlay is what makes the Map a Map rather than a collection of isolated datasets. A user opens an application and selects which layers they want to see. The application renders them together in a shared viewport. That's it.

At the spec level: Overlay requires nothing beyond a shared coordinate reference system (Section 3.1). If two layers use WGS 84, they can be overlaid.

A feature on one layer explicitly points to a feature on another layer. This creates a semantic link: "this feature is about that feature."

Examples:

• A review layer references a restaurant feature on a business directory layer.

• A historical annotation layer references a building feature on an infrastructure layer.

• A game object layer references a landmark feature on a base geography layer.

At the spec level: A reference is expressed as a pair: (target_layer_id, target_feature_id). The referencing feature stores this pair as part of its metadata. The referenced feature does not need to know it is being referenced.

This is intentionally one-directional. A feature cannot prevent other layers from referencing it, just as a website cannot prevent other websites from linking to it. Governance over how references are displayed or weighted is an application-level concern.

A fork is a snapshot of an existing layer that becomes a new, independent layer. The forked layer has its own Layer ID and its own governance, but retains a provenance link to the source layer and the State Hash at the time of forking.

Forking is how the Map evolves. A DAO may fork a neglected layer to maintain it under new governance. A game may fork a base geography layer to create a fictional variant. A community may fork a regional layer to establish different editorial standards.

At the spec level: A forked layer must include:

After forking, the new layer is fully independent. It may diverge arbitrarily from the source. The provenance link is informational, not operational — it does not create any dependency or synchronization obligation.

These are not required by the spec. They are patterns that the community is encouraged to adopt to make the ecosystem more interoperable, trustworthy, and useful.

While the required spec allows arbitrary metadata on features, applications and DAOs are encouraged to adopt shared schema conventions for common feature types. A community-maintained schema registry could define standard fields for categories such as:

• Physical infrastructure: roads, paths, buildings, bridges (fields: surface type, width, access restrictions)

• Points of interest: businesses, parks, landmarks (fields: name, category, hours, contact)

• Environmental: terrain, water features, vegetation (fields: type, seasonality)

• Cultural: art, memorials, historical markers (fields: artist, date, description, media links)

Adopting shared schemas is voluntary but increases the value of a layer by making it more interoperable with applications and other layers that use the same conventions.

The required spec mandates timestamps on features. At the convention level, layers are encouraged to attach richer provenance to each feature:

Richer provenance enables better downstream filtering, conflict resolution, and trust evaluation.

A DAO or governing body may issue attestations for layers or individual features that meet its standards. An attestation is a signed statement that says: "This governance body has reviewed this data and considers it accurate according to our criteria."

Attestations create a trust layer on top of the Map without requiring the protocol to make quality judgments. Applications can let users filter by attestation: "show me only layers attested by my local city DAO" or "show me everything, attested or not."

Attestation standards are set by the attesting body, not by the protocol. A rigorous city DAO may require in-person field validation. A casual gaming community may attest based on redundancy of player-generated data. Both are valid. The protocol's job is to ensure that attestations are cryptographically verifiable and that their governance source is transparent.

At the protocol level, there are no conflicts. Two layers may describe the same real-world location differently, and both are valid within their respective layers. Conflict only arises when a downstream consumer — an application, a DAO, or a user — attempts to compose a unified view from multiple layers.

Recommended strategies for conflict resolution include:

• Recency: Prefer the most recently updated feature.

• Attestation weight: Prefer features from DAO-attested layers.

• Redundancy: Prefer features that are corroborated across multiple independent layers.

• User preference: Let the user choose which layers to trust.

• Arbitration: For disputes that matter, defer to a decentralized arbitration protocol or to the governance body of the relevant DAO.

The spec does not prescribe any of these strategies. It only ensures that layers carry enough metadata (timestamps, provenance, attestations) to make informed resolution possible.

The following concerns are real and important, but are intentionally excluded from this specification. They belong to the application layer, the governance layer, or to future work.

• Storage and hosting. Where layer data physically lives — IPFS, Arweave, a traditional server, a rollup — is not a protocol concern. The spec requires content-addressable hashing for integrity verification, but does not mandate a storage backend.

• Proof of location. How to verify that a contributor was physically present when adding a feature is an active area of research and is not yet mature enough to standardize. The provenance convention (Section 5.2) provides a field for verification status, but the mechanisms are left to implementers.

• Token economics. How contributors are compensated — if at all — is a governance decision, not a protocol decision. Different DAOs and games will have different models.

• Rendering and visualization. How layers are displayed to users — cartographic styling, 3D rendering, AR overlays — is an application concern. The spec defines data structure, not presentation.

• Access control implementation. The spec requires layers to declare their access level (public, permissioned, private) but does not prescribe how permissions are enforced. Encryption, token-gating, and traditional access control lists are all valid implementations.

The Map Layer Composability Model defines the minimum conditions under which independently created spatial layers can coexist as parts of a shared, global Map.

The required spec is small by design. Shared coordinates. Persistent identity with verifiable state. Minimal feature structure. Three composition primitives: overlay, reference, fork.

The recommended conventions are expansive by invitation. Shared schemas. Rich provenance. DAO attestations. Conflict resolution strategies. These are the tools that will make the Map useful, trustworthy, and alive — but they emerge from the community, not from the protocol.

The Map is not built from the top down. It is assembled from the bottom up, layer by layer, by anyone who chooses to contribute. This spec exists to make that possible.