RSS identity reference
Syndication registry model
A trustworthy registry preserves history and evidence. It does not reduce feed identity to one mutable URL or an unexplained similarity score.
What a registry should do
Assign stable feed IDs, resolve known URLs, preserve aliases, expose validation history, and document migrations. It can support readers, directories, crawlers, archives, and analytics without claiming ownership merely because content was fetched.
Record model
Feed immutable ID, canonical URL, status, format
Alias URL, relationship, first/last observed, evidence
Observation fetched metadata, redirect chain, parser result
Event move, merge, split, retirement, claim change
Validation errors, warnings, identity checks, freshness
Claim actor, verification method, scope, expirationOwnership and publisher claims
Verify claims through domain control, well-known files, authenticated provider integrations, or other documented methods. Store the verification method and time. A copied feed or temporary redirect should not automatically transfer control of an established record.
Merge and split policy
Require strong evidence for merges, preserve source IDs as tombstones or aliases, and support appeals. Similarity systems should propose relationships, not destroy records. Splits create new IDs and an explicit lineage event.
Public outputs
Expose canonical URL, known aliases, current status, last observation, validation freshness, match evidence, and machine-readable links. Keep sensitive operational data and private-feed observations out of public results.
Review feed fingerprints for duplicate detection and the API guide for endpoint design.