Technical details

How OneFront actually works

The rest of the site avoids jargon on purpose — most people don't need to know how an engine works to drive a car. This page is for people who do want to see under the hood: engineers, technical marketers, or anyone evaluating OneFront against other link-in-bio tools.

The core problem: client-side rendering

Most link-in-bio tools, including Linktree, render page content with client-side JavaScript after the initial HTML loads. Crawlers that don't execute JavaScript — or that time out before it runs — see an empty shell. This includes many AI crawlers, which tend to be more conservative about JavaScript execution than Googlebot.

What OneFront does differently

  • Server-rendered by default. Every public profile page (onefront.org/<username>) is rendered on the server. There is no client-side dependency for content to appear — view-source shows the same content a browser does.
  • Real schema.org JSON-LD. Every profile emits a validating Person or Organization node (with name, url, image, sameAs populated from linked social accounts) plus an ItemList of the profile's links, in a <script type="application/ld+json"> tag in the page head.
  • An AI-crawler-allowlisted robots.txt. /robots.txt explicitly allows GPTBot, ClaudeBot, PerplexityBot, Google-Extended, and standard search crawlers.
  • llms.txt. A site-wide /llms.txt summarizes what OneFront is and links to every public profile. Each profile also has its own plain-text summary at /<username>/llms.txt, built for direct LLM consumption rather than HTML parsing.
  • A public MCP server. /api/mcp implements the Model Context Protocol (streamable HTTP, stateless, no auth required) with tools to query a profile's identity, links, and social accounts, and to record a link click — so an AI agent acting on a user's behalf can interact with the same data structurally, instead of scraping rendered HTML.
  • rel=me account verification. Verified badges use the IndieWeb rel=me pattern (the same mechanism Mastodon and Threads use for their verified-link checkmarks): a OneFront profile links out to a social account with rel="me", and we check that account's page for a link back to the OneFront profile, also marked rel="me". Only when both directions match do we mark it Verified — no third-party identity vendor, no KYC.
  • WebFinger. A /.well-known/webfinger endpoint resolves acct:username@onefront.org to profile data, the same discovery mechanism used across the fediverse (Mastodon, etc.).
  • Gravatar avatar fill. At signup, we check (via Gravatar's public hash-based avatar API, no auth) whether an avatar already exists for your email and use it as a starting point — nothing is fabricated if none exists.

Auto-updating feeds → typed structured data

A profile can subscribe to RSS 2.0, Atom, or podcast (iTunes-namespace) feeds. A scheduled job fetches each with conditional GET (ETag / If-Modified-Since), parses new entries, and upserts them idempotently on the feed's own GUID — so a podcast host publishing episode 43 makes it appear on the page with no manual edit.

The payoff is what those entries become: each is emitted as the schema.org type that fits its source — PodcastEpisode (inside a PodcastSeries), VideoObject, or BlogPosting — carrying datePublished, timeRequired/duration, episode number, and the playable media URL. That is the difference between an AI answer engine seeing "a link" and being able to answer "their latest episode is #43, published Tuesday, 48 minutes long," with the audio one field away. The newest items also flow into the profile's llms.txtand its MCP tools, so every consumer — page, structured data, plain-text, and agents — reports the same "latest."

Feed URLs are fetched behind an SSRF guard (DNS-resolved public-address check, re-validated on every redirect hop) with a size cap, since the URL is creator-supplied and fetched server-side.

High-fidelity media player & bio link sync

Unlike traditional link-in-bio services that embed slow, tracking-heavy third-party widgets, OneFront renders a native floating media player directly wired to your server-parsed podcast enclosures and schema.org PodcastEpisode graph.

  • Live feed detection: Audio enclosures are extracted directly from your RSS feed without requiring manual file uploads or iframe embeds.
  • Interactive controls: Features Apple Podcasts-style desktop and mobile floating bars with time scrubbing, 15-second skip back, 30-second skip forward, and variable playback speeds (1.0x to 2.0x).
  • Profile link synchronization: The player scans links on your profile for episode matches and dynamically injects 1-click play pills. Visitors can listen immediately without navigating away from your profile.
  • Video podcast & livestream support: Episodes paired with YouTube video URLs expand into a collapsible 16:9 studio video drawer, and creators can host 24/7 ambient live radio streams with MSE synchronization that prevents audio throttling in background browser tabs.

Verifying it yourself

View source on any OneFront profile page and you'll find the JSON-LD inline in the initial HTML response — no JavaScript execution required. You can also paste a profile URL into Google's Rich Results Test or the schema.org validator directly.