Link-share posts

When someone shares a URL through the embed widget, Zeeker creates a special link-only post owned by the @zeeker system account. These posts power the cross-site discussion model — every URL on the internet can have one canonical Zeeker thread.

Why they exist

The widget needs a server-side anchor for each URL it embeds against. We use a real post so that:

• The same thread is reachable from zeeker.com/p/<id>.
• Replies, reactions, saves and shares all use the same engine as native posts.
• Mods on the platform can act on widget content with their normal toolkit.

What they look like

A link-only post is rendered as a bare link card — no avatar, no author handle, no @zeeker byline.

• The link card carries the page title, hero image, source domain and snippet.
• The engagement footer (replies, reactions, share, save) is identical to any other post.
• In a thread view, the parent chain shows compact link cards instead of "@zeeker said…" rows.

For a contextual web Embed, preview metadata normally comes from Zeeker's server-side Open Graph fetch. The loader also sends the rendered host document's bounded og:title, og:description, og:image, and og:site_name, plus a document-title and favicon fallback, in the JSON boot body. Relative image/icon URLs are resolved against the host page. The server accepts this handoff only when the request Origin, resolved article origin, and configured Embed site origin match. That host-page data fills only missing or generic fallback fields, which lets a canonical card remain complete when the publisher blocks automated fetches without allowing a page to overwrite substantive metadata already extracted by Zeeker. The same guarded enrichment applies to an existing URL root on a later Embed boot.

The host handoff is limited to the canonical @zeeker discussion-root path. Ordinary member posts and replies cannot use client-supplied preview fields to bypass server extraction or publisher image restrictions.

This special rendering applies wherever an eligible post appears: feed, thread parent chain, reply references, and child preview lists. If preview fetching produces only a URL/hostname/favicon and the thread has no replies, the anchor remains available in its Embed and at its direct post URL but is withheld from the main feeds until it gains meaningful preview data or discussion.

Identification

Backend marks a post isLinkOnlyPost: true when:

author.username === 'zeeker' && type === 'link'

The @zeeker account (user id c145f59a-3f60-4de7-974b-2e28c7920ea5) is reserved system-wide and cannot be claimed by a normal signup.

Behavior

• Reply, react, save, share all work exactly as on a native post.
• Reposting a link-only post creates a normal repost on your timeline; the original engagement still accrues to the link-only post.
• Quoting wraps the link card inside your quote.
• Tagging / mentioning inside a reply works normally.

Moderation

Link-only posts are subject to the same rules as any other content. A community can remove a link-share thread from its own feed even if the source widget keeps surfacing it — community moderation actions take precedence within that community.

If a link itself is reported, the platform-level mod queue gets the report and can:

• Mark a domain as low-quality — link cards from the domain still render but are demoted in trending.
• Block a domain — new link-share threads from the domain are silently dropped at widget time.

When the widget creates one

The first time any user opens the widget on a given URL, the embed backend looks up the link post (deduplicated by canonical URL). If none exists, it creates one. From that moment on, every visitor to that URL — via the widget or via zeeker.com/p/<id> — joins the same thread.

Regression coverage

The link-only-post rendering is covered by the tests/embed/link-only-post.spec.ts Playwright spec in the zeeker_social_testing repository so we don't regress the bare-card UX.