An identity that
can travel.

1id1 identifies objects that people and software need to reference, preserve and connect. A paper is one kind of object. The same identifier profile can describe datasets, software, models, claims, proofs, research activities, agents and collections.

Syntax and resolution

Object:  1id1:<namespace>:<object-id>
Release: 1id1:<namespace>:<object-id>@v1

https://1id1.net/id/<namespace>/<object-id>/
https://1id1.net/id/<namespace>/<object-id>/v1/

The HTTPS URL is the canonical Web identifier. The 1id1: notation is a repository citation shorthand, not a registered URI scheme. Object URLs open a record and its release history. Release URLs identify a specific published version. Trailing slashes are part of the canonical URL form.

Namespaces

A namespace identifies the original allocation space. The initial namespace is core, managed by 1id1. Namespace names contain a lowercase ASCII letter followed by up to 31 lowercase letters, digits or hyphens. New namespaces require an entry in the registry and are never reassigned. A change of author, custodian or hosting provider does not change an existing identifier.

The public registry lists allocated namespaces and identifiers. Other issuers and delegated namespaces are reserved for future operation; the current service is operated centrally.

Date and sequence

Profile 1.1 uses YYYYMMDD-NNNN: an eight-digit registration date followed by a daily sequence within the namespace. For example, 1id1:core:20261026-0001 is the first object registered in core on 26 October 2026. The next object is 20261026-0002.

The date uses the Gregorian calendar and the registry's Asia/Shanghai time zone. It is the object's first registration date, not necessarily the date of writing or a claim of intellectual priority. Updating an object or publishing a new version does not change this date or object number.

Sequences start at 0001 each day in each namespace. They are padded to a minimum of four digits and expand naturally after 9999: the next is 10000. There is no four-digit capacity limit. Allocated numbers are never recycled, including withdrawn or cancelled reservations. Gaps are permitted.

The current operator reserves numbers through a locked local allocation ledger. Independent machines must coordinate through a single authoritative registry before allocating within the same namespace. Future delegated issuers receive their own namespaces.

Legacy identifiers

On 26 October 2026 the initial two records migrated from random UUID-based object numbers to the date-and-sequence profile at the operator's request. The former identifiers remain permanent aliases to the same objects and are never reassigned. Their record and download URLs redirect to the corresponding current URLs. The alias map is available for software. New citations should use the date-based identifiers.

Objects, releases and files

An object may have several releases. A release label is v followed by a positive decimal integer, without leading zeros or a fixed digit limit. Each label is allocated once within its object. The corresponding citation shorthand uses @v1, @v2 and so on.

PDF, LaTeX, HTML and other representations can belong to one release. File metadata records the media type, size, download location and SHA-256 digest. A digest checks file bytes; the object identifier remains stable when a new release is issued.

Published releases are retained. Substantive corrections require a new release. An explicit, author-requested correction to a publication imprint may retain its release identifier without changing the scholarly content. Such a correction is disclosed on the record, with updated file checksums and a preserved administrative backup. Current object pages and the catalogue can evolve to list new releases or withdrawal information. A withdrawn identifier is retained with an explanation and is never reused.

Extensible metadata

The initial catalogue uses schema version 1.0. Metadata includes the identifier, canonical URL, title, object type, attribution, publication date, version, files, rights, provenance and verification notes. A relations array links objects through explicit predicates and target identifiers or URLs.

Reserved relation names include isPartOf, derivedFrom, cites, generatedBy, attributedTo and relatedTo. These names are the repository vocabulary; mappings to external vocabularies can be added explicitly. Missing provenance is unknown, not evidence that an activity did not occur.

For AI-assisted work, records can link a generation activity to model versions, inputs, outputs and checking activities. The first deposits provide prose disclosures; detailed activity records will be published when available. Identifier assignment makes no claim of correctness, endorsement, peer review or ownership.

Parts and relationships

A theorem, proof, dataset subset or execution can receive its own identifier when it needs independent citation and maintenance. Its relationship to a larger object is recorded in metadata. A page fragment may locate a passage within a release, but it is not automatically an independently registered object.

Persistence and interoperability

Identifiers are not reassigned. Record URLs remain stable across storage migrations. The operator retains a local registry and publication files for recovery and migration; a future migration must preserve resolution or provide redirects. Domain renewal, certificate renewal and storage maintenance remain operational responsibilities.

Metadata schema versions are independent of content versions. Existing DOI, arXiv, ORCID or other identifiers can be recorded as external identifiers, with the nature of the relationship stated. 1id1 identifiers do not imply registration with those services.

The design follows the W3C recommendations on persistent Web identifiers and separately identifiable versions. Download the current catalogue.