Proposal: Link Genetic Identifier (LINKID) – Persistent, Self-Healing Web Links
Summary: The Link Genetic Identifier (LINKID) proposes a standardized, persistent, and semantically resilient hyperlink layer that ensures web resources remain accessible, traceable, and repairable — even when underlying URLs change or disappear. It separates logical link identity from physical destination URLs and enables AI-based repair, semantic metadata tracking, and version-aware linking. In short: no more broken links (404), even as content evolves.
Motivation: The Web suffers from link rot — the gradual decay of hyperlinks that once pointed to valid resources but now lead to errors (404, 410, redirects, etc.).
Within only a few years, 30–50 % of hyperlinks in public and corporate websites become unreachable due to:
- domain or CMS migrations,
- file structure changes,
- expired short links,
- or removed content.
This affects digital transparency, reproducibility of research, open-data access, and long-term sustainability.
The LINKID concept builds upon the idea of Digital Object Identifiers (DOI) but generalizes it for the open Web, corporate environments, and dynamic content ecosystems such as CMS, APIs, and AI-generated resources.
LINKID proposes a web-native persistent identifier that:
- can be embedded into any HTML, PDF, or DOCX document,
- remains resolvable even after destination changes,
- supports AI-assisted repair and version recovery,
- and is fully backward compatible with existing href links.
Open Questions for the Community We would appreciate early feedback on:
- URI scheme design: Should linkid: be formally registered as a URI scheme, or introduced via a new HTML attribute first?
- Resolver architecture: Is a browser-native resolver feasible, or should resolution remain extension-based (similar to DOI handlers)?
- Security model: What are best practices for authenticating LINKID registries and preventing spoofing?
- Privacy implications: How can we guarantee GDPR-compliant metadata exchange?
- Standardization path: Would this fit better as a WICG incubation or a joint discussion with the Persistent Identifier CG?
Goals for WICG incubation:
- Define linkid: URI scheme.
- Define LINKIDResolver and navigator.linkid Web API.
- Specify serialization for HTML, JSON-LD, and PDF metadata.
- Create open test suite and reference resolver.
- Define security & privacy considerations jointly with W3C TAG (https://tag.w3.org/).
Related Work
- DOI Handbook
- RFC 3986: URI Syntax
- Handle System
- [W3C Persistent Identifier Community Group] (https://www.w3.org/groups/cg/perma-id/)
Repository: https://github.com/Link-Genetic-GmbH/lid/
Explainer: https://github.com/Link-Genetic-GmbH/lid/blob/main/docs/explainer.md
Next Steps
- Discuss potential interest and overlaps with existing identifier systems.
- Collect feedback on URI scheme and resolver API structure.
- If interest exists, begin formal incubation and create WICG/linkid repo for experimentation.
Contact Christian Nyffenegger Founder & Lead Architect – Link Genetic GmbH 📧 [email protected] 🌐 https://linkgenetic.com GitHub: https://github.com/Link-Genetic-GmbH/lid
Feedback Welcome All thoughts and critiques are appreciated — particularly from browser vendors, web platform engineers, and identifier experts. Our goal is to evolve LINKID into a sustainable, interoperable, and privacy-preserving standard for durable web links.
🔗 Update: Related W3C Initiative – Permanent Identifier Community Group (perma-id)
We would like to note a related initiative: the W3C Permanent Identifier Community Group (perma-id), which maintains the w3id.org infrastructure for permanent web redirects.
While w3id.org focuses on stable, maintained redirect URIs, our Link Genetic Identifier (LINKID) concept operates on a higher semantic layer:
- LINKID introduces a content-aware, versioned, and self-healing identifier mechanism.
- It allows AI-based recovery of broken destinations and semantic fingerprinting to match content changes.
- LINKID can resolve across multiple registries and decentralized networks, not only via static redirect tables.
We believe there is a strong complementarity between w3id.org’s infrastructural persistence and LINKID’s semantic resilience — and we plan to align with the perma-id CG to ensure compatibility and interoperability.
@WICG/chairs Could one of the maintainers please assign this issue or apply the proposal label?
We’d be happy to act as editor/author for the incubation process.
Hi @LinkGenetic - I'm not a member nor affiliated with the WICG, but noticed this issue in the bugtracker and felt like reading it, out of interest. I noticed two broken hyperlinks:
Repository: https://github.com/Link-Genetic-GmbH/linkid
Explainer: https://github.com/Link-Genetic-GmbH/linkid/blob/main/docs/explainer.md
I think these URLs should be updated to reflect their respective content relocations to the github.com/Link-Genetic-GmbH/lid repository.
(in other words: replace /linkid with /lid in the URLs and that should fix them, I think)
Thanks!
The hyperlinks in the description seem correct to me now; thank you for fixing/updating those.
This is reinventing URNs, introducing a JSON-based resolver API, no?
PS: In some places it says, recorded links were bidirectional, but elsewhere I only see target URLs and issuer URLs, not source URLs. PPS: It remains utterly unclear, exactly how resolvers are supposed to keep track of destinations, but it appears that it involves educated guesses (including self-asserted quality estimations), now generally termed “AI”, previously “heuristics”.
Thanks for pointing to the draft — that helps clarify the concern.
You’re right that the document currently defines a linkid: URI scheme. However, the intent is not to reintroduce URNs under a different name, but to specify a resolution contract rather than a pure naming system.
Key distinctions relative to URNs:
- URNs are identifiers of record. They assume stable, authoritative assignment and long-lived resolver bindings.
- linkid: is explicitly a resolvable reference. The scheme exists to enable recovery when those assumptions fail — e.g. when:
- no authoritative registry exists,
- the resolver mapping is missing,
- or the referenced resource has moved, forked, or evolved.
-
Resolution is content-centric, not name-centric The resolver may use content fingerprints, similarity matching, version metadata, and cross-registry lookup. This is fundamentally different from classic URN → resource resolution, which is name-binding based.
-
The JSON resolver format is incidental JSON is used as an interoperable response representation, not as part of the identifier semantics. The same mechanism could sit behind HTTP URLs, URNs, DOIs, ARKs, etc.
In that sense, linkid: is best understood as a semantic fallback and resilience layer, not a competing naming authority.
We fully agree this needs to be carefully aligned with existing identifier work (URNs, perma-id, w3id), and the draft is intentionally brought to WICG to validate exactly these boundaries early.