---
title: "How We Built Our Website on XION"
description: "A walkthrough of how XI Objects uses its own provenance stack to publish, serve, and verify content on xiobjects.com, from markdown authoring to DOM-level attribution."
published: 2026-02-18T18:25:49.708463+00:00
updated: 2026-02-18T18:25:49.708463+00:00
tags: ["applied-science", "attribution", "react", "website", "xion+md"]
url: https://xiobjects.com/docs/xio/applied-science/website-integration
source: XI Objects
---

<!-- xion:doctype xion+markdown -->
<!-- xion:metadata
{
  "version": "1.0",
  "content_type": "application/xion\u002Bmarkdown",
  "source_type": "xi-content/doc",
  "generator": "xio-content-publisher/1.0.0",
  "generated": "2026-02-18T18:25:44.8949360\u002B00:00",
  "encoding": "utf-8",
  "render_intent": "markdown",
  "title": "How We Built Our Website on XION",
  "slug": "xio/applied-science/website-integration",
  "copyright": "\u00A9 2026 XI Objects Inc"
}
-->

# How We Built Our Website on XION

We eat our own cooking.

[xiobjects.com](https://xiobjects.com) isn't a marketing site with XION bolted on. XION *is* the content layer. Every article and documentation page is authored in Markdown, then run through our serialization and trust infrastructure to produce signed XION+MD artifacts. Those artifacts are served through our API, rendered by React components that understand the format, and verifiable without leaving the browser.

This is how we approached it. Not the only way to integrate XION, but it's what we did and what we learned.

---

## The Content Pipeline

### Authoring in XION+MD

We write everything in Markdown. During publish, each document gets transformed into **XION+MD**, our signed content format that wraps standard Markdown with structured metadata and a cryptographic trust block:

```
<!-- xion:doctype xion+markdown -->
<!-- xion:metadata
{
  "version": "1.0",
  "content_type": "article",
  "title": "...",
  "author": "...",
  "render_intent": "html",
  ...
}
-->

...your markdown body...

<!-- xion-example:trust
{
  "content_hash": "...",
  "signature": "...",
  "key_id": "...",
  "certificate_chain": [...]
}
-->
```

The doctype declares this is a XION document. The metadata block carries structured information about the content. The body is plain Markdown, so any renderer can display it. The trust block at the end is the cryptographic seal: a BLAKE3 hash of the canonicalized content, an Ed25519 signature, and the full certificate chain back to the Institute of Provenance Root CA.

The trust block gets appended *after* the content is finalized. Change a single character of the body or metadata and the signature invalidates.

### Images: Register the Original, Publish the Optimized

When an article includes images, we run them through our stack before publishing:

1. **Register the original.** The full-resolution source image is fingerprinted, signed with an XI leaf certificate, and registered into Orbital. This is the canonical record: the pristine original, at full quality, with complete provenance.
2. **Optimize for the web.** We compress and scale the image for publishing (WebP, responsive sizes, the usual). The published image is a derivative, not the original.
3. **Serve with a registration hint.** The CDN URL for the optimized image includes a `#xi={blake3hash}` fragment referencing the original registration.

We register the *original*, then publish a *compressed derivative*. When someone verifies that image, even the scaled-down WebP on the page, our perceptual fingerprinting pipeline matches it back to the original registration in Orbital. Compression, format conversion, and resizing don't break the match.

That's the stack doing what it's designed to do. Attribution survives transformation.

---

## Serving XION+MD

### The Content API

The backend has a content API that serves articles and documentation pages. The response shape is straightforward:

```json
{
  "slug": "introducing-xi-objects",
  "title": "Introducing XI Objects",
  "markdownBody": "<!-- xion:doctype xion+markdown -->\n<!-- xion:metadata\n{...}\n-->\n\n...body...\n\n<!-- xion-example:trust\n{...}\n-->",
  "tags": ["announcement", "provenance"],
  "publishedAt": "2026-02-15",
  ...
}
```

The `markdownBody` field contains the **complete XION+MD document**: doctype, metadata, body, and trust block. The API doesn't strip any of it. The full signed artifact goes to the client.

That's deliberate. The verifiable unit is the entire document, metadata and content and signature together. If the API stripped the trust block or modified the body, verification would fail. So it just passes the document through.

---

## Rendering in React

### Parsing the Document

On the client, we parse the XION+MD into its structural components: doctype, metadata, body, and trust block. The parser (`parseXionDocument`) pulls these apart so the rendering layer can work with the body Markdown while the verification layer works with the full raw source.

The `render_intent` field in the metadata controls styling. Articles get `"html"` for rich prose typography. Documentation pages get `"markdown"` for tighter, more utilitarian formatting.

### The XionContent Component

This is where it comes together. `XionContent` does two things at once:

**Renders the Markdown body for display.** Headings, paragraphs, code blocks, images, all styled according to the render intent.

**Embeds the full XION+MD source in the DOM.** The complete signed document goes into a `<script type="application/xion+markdown">` tag. It's invisible, never executed (same pattern as JSON-LD), but it's *there*. In the DOM. Inspectable.

```html
<article data-xion="true"
         data-xion-slug="introducing-xi-objects"
         data-xion-signed="true"
         data-xion-render-intent="html">

  <!-- Full verifiable source (invisible, not executed) -->
  <script type="application/xion+markdown">
    <!-- xion:doctype xion+markdown -->
    <!-- xion:metadata {...} -->
    ...body...
    <!-- xion-example:trust {...} -->
  </script>

  <!-- Rendered body (what you see) -->
  <div class="markdown-viewer">
    <h1>Introducing XI Objects</h1>
    <p>Every second, AI generates another image...</p>
    ...
  </div>
</article>
```

The `data-xion` attributes mark the element as a XION container, making it discoverable by our tooling and anyone else's.

### Image Attribution

Inside the rendered Markdown, every image is wrapped in an `AttributedImage` component. When the image loads, it checks for the `#xi=` registration fragment on the CDN URL. If it finds one, a small `[XION]` badge appears on the image.

Click the badge and the component sends the actual image bytes to Xio.Public's verification endpoint. The server re-fingerprints the image perceptually and matches it against the full Orbital registry, confirming attribution even though the published image has been compressed and resized from the registered original.

---

## The [XION] Tag

`[XION]` on the page, styled in our accent color, is an attribution indicator. The content you're looking at has a verifiable provenance chain.

On article pages, `[XION]` appears in the metadata bar alongside the author name and publication date. Click it and the attribution overlay opens, a flyout panel showing the full verification result.

### What Happens When You Click

1. The full XION+MD source is pulled from the `<script type="application/xion+markdown">` tag in the DOM
2. The entire document is `POST`ed to Xio.Public's document verification endpoint
3. Xio.Public validates the BLAKE3 content hash, verifies the Ed25519 signature, and walks the certificate chain
4. If the document verifies, the response includes the signer's Key ID
5. Attribution is resolved by that Key ID: creator identity, organization, license, AI-use permissions, endorsements

The overlay shows the result. Verified or not, who signed it, when, under what trust context, and what attribution metadata is attached to the signing certificate.

The verification input is the *complete XION+MD document from the DOM*. Not a hash. Not a summary. The entire artifact. The server handles the cryptographic verification; the client just supplies the content and displays the result.

---

## The Chrome Extension (Coming Soon)

Everything above works natively on our site because we built the components for it. But what about other sites, or ours viewed without our React code running?

That's what the XI Objects Chrome Extension will do. We have a working prototype that scans any page you visit for XION content:

- **Trust block detection** finds `<!-- xion-example:trust {...} -->` in the page source
- **Image registration** detects `#xi={hash}` fragments on image URLs
- **Badge injection** overlays `[XION]` badges on attributed content using Shadow DOM, so there are no CSS conflicts with the host page
- **Full verification** lets you click a badge and verify against Xio.Public, with the same attribution flyout

The extension doesn't need our React stack. It reads the DOM, finds the artifacts, and talks to the same public verification API. It works on any page that contains XION content, including ours. The prototype is functional internally and we're working toward a public release.

---

## What This Adds Up To

This isn't just a website. It's a working integration of the full XION stack:

- Content authored and signed with our SDK tooling
- Images registered at original quality, served as optimized derivatives, with attribution surviving the transformation
- XION+MD served intact through a content API (the full signed artifact, not a stripped-down version)
- React components that render the content *and* keep the verifiable source in the DOM
- Client-side verification through Xio.Public: `POST` the full document, get a cryptographic check, resolve attribution by certificate Key ID
- The `[XION]` tag as a user-facing entry point into the trust chain
- A browser extension (coming soon) that will bring the same verification to any page on the web

We built the tools. Then we used them.
<!-- xion:trust
{
  "v": 1,
  "canon_v": 1,
  "ctx": "xiobjects.com/content",
  "hash_blake3_hex": "27c5d832e911586df632b52d3d6f448204f65d3651fb2c46ac486bb7783f0a79",
  "hash_sha256_hex": null,
  "sig_alg": "ed25519",
  "sig_b64": "gIUj6XuXvebjJMaeXhn-t7jIBhNjH8AMAFc6zdNdCs02vyRHz_EErDh34AENYmKQ46hNy4aj7ZSOhVsi64cVAg",
  "pubkey_b64": "ff4Npz7sRQH_vUn9FY8Wrc8v_00Z49h15EyQgKVTHR0",
  "x509_chain_pem": [
    "-----BEGIN CERTIFICATE-----\r\nMIIB9TCCAaegAwIBAgIRAM4lRb8aI/FYHOJD5OYqefQwBQYDK2VwMC4xLDAqBgNV\r\nBAMMI1hJIE9iamVjdHMgSW5jIENvbnRyb2wgSW50ZXJtZWRpYXRlMB4XDTI2MDIx\r\nNTIyMDg0OFoXDTI2MDMxNzIyMDg0OFowSzEeMBwGA1UEAwwVeGlvLWNvbnRlbnQt\r\ncHVibGlzaGVyMRcwFQYDVQQKDA5YSSBPYmplY3RzIEluYzEQMA4GA1UECwwHQ29u\r\ndGVudDAqMAUGAytlcAMhAH3\u002BDac\u002B7EUB/71J/RWPFq3PL/9NGePYdeRMkIClUx0d\r\no4G8MIG5MAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgeAMBMGA1UdJQQMMAoG\r\nCCsGAQUFBwMkMGUGA1UdIwReMFyAFDspt5hZsP6rNX4Cq7owpMYa05OyoS6kLDAq\r\nMSgwJgYDVQQDDB9JbnN0aXR1dGUgb2YgUHJvdmVuYW5jZSBSb290IENBghRSYDf4\r\nsUJ\u002B9h\u002Bod0\u002BZRK/X/JSUBTAdBgNVHQ4EFgQUP5BTxnjCAxVKgMvFhx40ljlGOAkw\r\nBQYDK2VwA0EAjKlSBzHgXpPM2PA\u002BSJ/rMso5OEqtWIHGo/zr2QSuZRXhSWafIbk9\r\nZnl0kKZCqUB2HpCfgnpOGCPK6SlefwQsAQ==\r\n-----END CERTIFICATE-----\r\n",
    "-----BEGIN CERTIFICATE-----\r\nMIIByDCCAXqgAwIBAgIUUmA3\u002BLFCfvYfqHdPmUSv1/yUlAUwBQYDK2VwMCoxKDAm\r\nBgNVBAMMH0luc3RpdHV0ZSBvZiBQcm92ZW5hbmNlIFJvb3QgQ0EwHhcNMjUxMTAy\r\nMDMxNzEyWhcNMzAxMTAxMDMxNzEyWjAuMSwwKgYDVQQDDCNYSSBPYmplY3RzIElu\r\nYyBDb250cm9sIEludGVybWVkaWF0ZTAqMAUGAytlcAMhAFSS/pggSRmTcAMko7uc\r\nATH8OHgxVymd5mBFlPXbJkgio4GtMIGqMBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYD\r\nVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQ7KbeYWbD\u002BqzV\u002BAqu6MKTGGtOTsjBlBgNV\r\nHSMEXjBcgBQAZRTDswSVORu\u002BkUOKX6WvrOvmQKEupCwwKjEoMCYGA1UEAwwfSW5z\r\ndGl0dXRlIG9mIFByb3ZlbmFuY2UgUm9vdCBDQYIUJqoJlpiSFg\u002B7W5IJLMrLttgR\r\nQp4wBQYDK2VwA0EA5FOht7YOsVRPp/FOKMQ\u002B3Mo9JxrvGR3ylKWAWNm6OUV7N3DB\r\nI9cD62wU5I0d0EKDBy0CX9DnoqUyxv5yguraAA==\r\n-----END CERTIFICATE-----\r\n",
    "-----BEGIN CERTIFICATE-----\r\nMIIBaTCCARugAwIBAgIUJqoJlpiSFg\u002B7W5IJLMrLttgRQp4wBQYDK2VwMCoxKDAm\r\nBgNVBAMMH0luc3RpdHV0ZSBvZiBQcm92ZW5hbmNlIFJvb3QgQ0EwHhcNMjUxMTAy\r\nMDMwNTEyWhcNMzUxMDMxMDMwNTEyWjAqMSgwJgYDVQQDDB9JbnN0aXR1dGUgb2Yg\r\nUHJvdmVuYW5jZSBSb290IENBMCowBQYDK2VwAyEAEWNZl\u002Br3IC7\u002BgBh90Yo1kWk1\r\npZCVzVuFdFT7qBBU8W2jUzBRMB0GA1UdDgQWBBQAZRTDswSVORu\u002BkUOKX6WvrOvm\r\nQDAfBgNVHSMEGDAWgBQAZRTDswSVORu\u002BkUOKX6WvrOvmQDAPBgNVHRMBAf8EBTAD\r\nAQH/MAUGAytlcANBAO6QeydOFNrN75qNyftggYudsxMyl4w9qWkSdZ6hlhrRcbSr\r\niG9Si0kbrIJOwYB/LTBU0RM4Rl\u002Bo9PM3Qp0mPwo=\r\n-----END CERTIFICATE-----\r\n"
  ],
  "key_id": "-GCB4sEBzFethc5Pd0Rzyn_6ySyHB4QaqD9DAoW9ViE",
  "created_at": "2026-02-18T18:25:44Z"
}
-->