--- updated: 2026-10-02 scope: / --- # Myles' Registry Myles' Registry is the canonical registry of identifiers used throughout Myles Braithwaite's digital garden. Canonical URL: https://registry.myles.garden/ The Registry provides stable identifiers for entities that may appear across Myles's websites, archives, projects, datasets, and other systems. ## Purpose The Registry exists to answer: What is this thing? rather than necessarily: What do we know about this thing? Each registry entry assigns a stable identifier to an entity. Identifiers allow entities to remain recognizable even when their names, URLs, locations, or surrounding systems change. ## Canonical Identity When an entity has a Registry identifier, treat that identifier as its canonical identity within Myles's digital garden. For example: MB 0 identifies myles. MB 404 identifies myles' garden. MB 404-14 identifies windfall, nested beneath MB 404. Names and URLs may change. Registry identifiers should generally remain stable. ## Identifier Syntax An identifier is a namespace, followed by a number, optionally followed by a hyphen and a second number. The Registry writes every identifier in one of two equivalent forms. Registry form, as stored in an entry's Identifier field and displayed in human-facing interfaces: MB 0 MB 404 MB 404-14 Reference form, as used in this site's URLs, in the `id` field of API responses, and in references between entries: MB-0 MB-404 MB-404-14 The two forms differ only in the separator after the namespace: Registry form uses a space, reference form a hyphen. Convert between them by replacing that one separator. Both refer to the same identifier. Use reference form when constructing a URL or exchanging an identifier with this Registry's API. Use Registry form when quoting an identifier as the Registry displays it. Do not mix the two within a single identifier, and do not alter the hyphen that separates numeric components. Neither of these is valid: MB-404 14 MB 404 14 Identifiers are case-sensitive. Namespaces are uppercase. ## Namespaces The first component of an identifier is the namespace that issued it. The Registry currently recognizes: ARC Arcana Artifact ARCD Arcana Artifact (Digital) MB myles braithwaite (me) MIYS Monkey in your Soul ORB Orbital TREX trex.studio Namespaces are independent. Numeric values should only be interpreted within their namespace. For example: MB 0 TREX 0 must not be treated as related merely because they both contain the number 0. Do not assume that identifier numbers have a universal meaning across namespaces. ## Hierarchical Identifiers An identifier carries at most two numeric components. A second component expresses that the identifier is nested beneath the identifier formed by the first component alone. For example: MB 404 myles' garden MB 404-14 windfall, nested beneath MB 404 There is no third level. An identifier with three numeric components is not valid, and the Registry will not issue one. An entry's page lists the identifiers nested beneath it. Derive nesting from that listing rather than from the shape of the identifier alone. Do not assume that every identifier has entries nested beneath it, or that nesting always expresses the same kind of relationship. ## Numbers Are Identifiers, Not Rankings Numeric components are identifiers. Do not interpret them as: - ratings - scores - rankings - priorities - chronological order - version numbers - popularity - importance unless an entry explicitly defines such a meaning. A larger number does not imply that an entity is newer, more important, or ranked higher than another entity. Numbers are assigned, not earned, and the Registry leaves gaps in every namespace. ## Registry Entries An entry may contain: identifier the identifier itself, in Registry form name a short human-readable name summary a one-line description category the kind of entity (see Categories) url where the entity can currently be found externalRegistryUrl the peer registry that issues this identifier relatedIdentifiers typed links to other identifiers body longer prose about the entity Only `identifier` is always present. Every other field is optional. The Registry publishes no modification date, revision number, or status field on an entry. Do not expect one, and do not infer recency from an identifier's number. Sparse entries are valid. ## Sparse Records Some entries exist primarily to reserve and establish an identifier. They may contain little more than an identifier, a name, a category, and a URL. An entry may explicitly state that it has not yet been documented. Do not invent missing descriptions, relationships, dates, statuses, or other metadata. Missing documentation does not make an identifier provisional or invalid. ## Categories A category describes the type of entity an identifier represents. Categories in use, as published and as displayed: book Book org Organization person Person place Place post Post project Project videoGame Video Game vinylRecord Vinyl Record website Website Additional categories may be introduced, and entries mirrored from a peer registry may carry categories of their own. Treat an unrecognized category as opaque rather than as an error. Do not infer additional characteristics from the category alone. For example, a website entry identifies a website but does not necessarily indicate that the website is currently active, maintained, public, or owned by a particular person unless other metadata establishes that. ## URLs Registry entries may point to canonical or related URLs. A URL identifies where an entity can currently be found. The Registry identifier identifies the entity itself. Therefore: URL ≠ identifier URLs may change while identifiers remain stable. When referring to an entity within Myles's systems, prefer its Registry identifier when one is available. When retrieving the entity's current content, follow the URL recorded by the Registry. ## Relationships An entry may record typed links to other identifiers. The relation types currently in use are: createdBy friend memberOf sameAs worksAt These relationships are held in Registry data but are not currently published through the HTML pages, the Markdown views, or the JSON API. The one relationship a consumer can read directly is nesting, which an entry's page lists. Only assert a specific relationship when it is explicitly represented by the Registry or another authoritative source. Do not derive semantic relationships merely because identifiers share numeric components. ## Cross-Site Identity The Registry acts as an identity layer across Myles's websites. Other sites may use Registry identifiers to refer to the same entities without duplicating their identity. Registered entities currently resolve to these hosts: arcana.myles.garden clippings.myles.garden gate.myles.garden grimoire.myles.garden myles.garden yarrow.myles.garden The Registry itself is https://registry.myles.garden/ and is not a registered entity. When the same Registry identifier appears on multiple sites, treat those references as referring to the same registered entity unless explicitly stated otherwise. This lists hosts, not entities. A host's presence here does not mean every page on it is registered, and a host's absence means nothing on it is. Do not assume an identifier for either. ## External Namespaces The Registry mirrors identifiers issued by related systems. Those entries carry an `externalRegistryUrl` pointing at the registry that issues them, and this Registry's JSON API does not republish them. Namespaces issued entirely by a peer registry: ARC https://arcana.myles.garden ARCD https://arcana.myles.garden TREX https://trex.studio These namespaces are issued here, but some of their entries are mirrored from a peer and are likewise absent from this Registry's JSON API: MB Do not assume that every identifier displayed or linked by the Registry was issued by the MB namespace. Respect the authority of the namespace that issued the identifier, and prefer that registry as the source for its own entries. ## Machine-Readable Formats Prefer these over scraping the HTML pages. Identifier index https://registry.myles.garden/llms.txt Identifier list, HTML https://registry.myles.garden/list Identifiers, JSON https://registry.myles.garden/api/v1/identifiers.json Identifiers, Markdown https://registry.myles.garden/api/v1/identifiers.md One identifier, JSON https://registry.myles.garden/api/v1/identifiers/MB-404.json One identifier, Markdown https://registry.myles.garden/MB-404.md Namespaces, JSON https://registry.myles.garden/api/v1/identifier-types.json Namespaces, Markdown https://registry.myles.garden/api/v1/identifier-types.md Sitemap https://registry.myles.garden/sitemap-index.xml This file https://registry.myles.garden/ai.txt The JSON collection endpoints are paginated and carry `previous`, `next`, and `count` alongside `result`. Follow `next` until it is null rather than guessing page numbers. The Markdown collection endpoints are not paginated. Each is a single document whose table lists every entry alongside the entity's URL and both machine-readable views of its entry, so one request is enough to enumerate the Registry. Substitute an identifier in reference form into the single-identifier paths. Every HTML page also carries schema.org `DefinedTerm` structured data describing the identifier it documents. ## Identifier Resolution To resolve an identifier: 1. Normalize it to reference form by replacing the separator after the namespace with a hyphen. 2. Request the JSON endpoint for that identifier: https://registry.myles.garden/api/v1/identifiers/MB-404.json, substituting the identifier you hold. 3. A 404 means the identifier is not registered here. Do not fall back to a similar identifier. 4. Use the response to determine the entity's name, category, and current URL. 5. Follow the entity's `url` when more detailed information is required. 6. Prefer information from the entity's own site over descriptions duplicated elsewhere. Identifiers mirrored from a peer registry are absent from this Registry's JSON API. Resolve those against the registry named in External Namespaces. Do not resolve identifiers by guessing based only on similar names or numbers. ## AI Guidelines When using the Registry: 1. Treat Registry identifiers as stable entity identifiers. 2. Preserve identifiers exactly, in whichever of the two documented forms the context calls for. 3. Prefer identifiers over names when distinguishing ambiguous entities. 4. Do not interpret numeric components as rankings, dates, versions, or scores unless explicitly documented. 5. Do not merge entities merely because they have similar names. 6. Do not merge identifiers from different namespaces. 7. Do not invent metadata for sparse records. 8. Distinguish an entity's identity from information published about that entity. 9. Use the Registry to establish identity and the entity's own site for detailed content. 10. Respect explicit relationships rather than inferring them from identifier structure. 11. Do not infer recency. The Registry publishes no dates or status fields, so a cached answer cannot be compared against a newer one by metadata alone; re-request the entry instead. 12. Do not infer personal relationships, beliefs, ownership, endorsement, or affiliation unless explicitly represented. ## Authority The Registry should be treated as authoritative for: - identifiers issued within its namespaces - the entity represented by an identifier - mappings between identifiers and entities - current canonical URLs recorded by the Registry - explicit relationships recorded between registered entities It should not automatically be treated as authoritative for all factual claims about those entities. For example: Registry → authoritative for "MB 404 identifies https://myles.garden" https://myles.garden → authoritative for its own current content ## Structured Data A JSON identifier carries exactly these fields: id the identifier in reference form name optional summary optional category optional url the entity's URL, or its Registry page when it has none body optional, on the single-identifier endpoint only There are no relationship, namespace, date, or status fields in the JSON API. Parse the namespace out of `id` if you need it; do not expect the rest. Do not replace explicit identifier relationships with relationships inferred from page titles, URL structures, or numerical similarity. ## Persistence Identifiers are intended to provide durable references. An entity may: - move to another URL - change its name - become inactive - be archived - be replaced - gain additional documentation These changes do not necessarily create a new identity. Prefer the Registry's explicit identity model over assumptions based on URLs or names. ## Limitations The Registry is not: - a comprehensive encyclopedia - a search index of the entire web - a ranking system - a chronology - an ownership database - proof of endorsement - proof of authorship - a complete description of every registered entity It is primarily an identity and reference system. ## Contact Website https://myles.garden/ Contact https://myles.garden/contact/ Verified online identities https://myles.garden/verify/ ## Permissions This file provides context for interpreting the Registry and its identifiers. It does not itself grant additional copyright, crawling, indexing, redistribution, or model-training permissions. Respect applicable robots.txt rules, HTTP headers, licensing information, content signals, and other permissions published by the site: https://registry.myles.garden/robots.txt