nx_wiki_archive.nx

nx_wiki_archive.nx -- NO-LINK-ROT for the sovereign wiki. THE LAW (operator, standing): "No link rot. Archive all information into the Nishi Library so nothing that helped us get here is lost; links should always work." This organ makes rot STRUCTURALLY IMPOSSIBLE via content-addressing. MECHANISM (why rot cannot happen here): Each page's raw bytes are stored under a KEY that IS the hash of those bytes -- the CID = "nxc1-" + 64 hex of sha256(body), from nx_canon_cid's cid_of() (substrate-canonical, FIPS 180-4 KAT'd via nx_sha256). A CID can ONLY ever name one byte string: hand back a CID, you get back the EXACT bytes that produced it, forever. So: - identical content collapses to ONE blob (same bytes -> same CID -> dedup) - a CID link NEVER rots: the key is derived from the content, so as long as the immutable append-only seg_store keeps the blob, the link resolves - this is HOW we exceed Wikipedia, which leans on the Internet Archive to paper over rot after the fact; here rot is a non-event by construction. STORE: the content-addressed append-only seg_store (runtime/nx_seg_store.nx), prefix "knowledge/store/wikiarchive-" (the library's own durability substrate). No nx_library_*.nx ingest organ exists yet, so we land in the seg_store directly; full library-corpus / BM25 unification = a flagged follow-on, NOT silently done here. LAYOUT (two key families in one store): wikiblob:<cid> -> the page bytes (content-addressed; idempotent dedup) wikicid:<slug> -> the page's CURRENT cid (slug -> content pointer; mutable by ADDITIVE re-archive, old versions stay in history) Dropping a wikicid:<slug> pointer never loses data -- the blob is still keyed by its CID (the no-loss proof). IMPORTS: nx_seg_store + nx_canon_cid. Both transitively pull nx_syscalls; the NishiLang resolver de-dups by module identity (nx_infomgmt_gate.nx imports the same trio and builds), so no double-import nxasm-rc6 landmine. Pure NishiLang, NO SQL, NO .sh/.py/.js, no new .tsv/.conf. license_tier: ORIGINAL