Appearance
Community experiences
Anchor.Social experiences, also called Embed Elements, are reusable starting configurations for placing part of an existing Zeeker Social community inside a website or app. They are part of Anchor.Social, not separate products, content models, or runtimes.
An Element may combine only capabilities that already exist in Zeeker Social. A preset can choose an existing community feed, post type, thread, composer, chat destination, sort order, or container mode; it cannot create a Support-only header, a separate Reviews dashboard, a new Q&A system, or any other Element-only behavior. When a requested capability does not exist in Social, Zeeker adds it to Social first or omits the Element until it does.
The configuration model
Think of an Element as three layers:
- Zeeker Social supplies the capability. Posts, question and review types, ratings, polls, replies, reactions, badges, feeds, profiles, community chat, moderation, and identity remain the canonical implementations.
- The community defines the ceiling. Community settings determine what content and actions exist and who may use them.
- The embed narrows and presents. An embed chooses a subset of allowed content and controls how that subset fits into the host page. It can never widen the community's access, content, or moderation rules.
Selecting an Element applies sensible initial values to ordinary community and embed controls. Those values can be edited after creation. The preset name is useful for setup, analytics, and demo routing, but it is not a second source of runtime truth.
Available presets
| Element preset | Existing Social capabilities it combines | Common placement |
|---|---|---|
| Group Chat | The community's existing group chat, when community chat is enabled. | Anchor launcher by default; custom trigger, fixed, and full-screen are also available. |
| MOD Chat | An existing private viewer-to-authorized-team chat path. | Anchor launcher by default; custom trigger, fixed, and full-screen are also available. |
| Support Forum | A community feed filtered to allowed question post types, using the community's badges, sort, composer, community-scoped search, and ordinary post pages. | Help center, customer portal, or documentation section. |
| Comments | An ordinary Zeeker thread resolved from a canonical URL or stable host object. | Below an article, guide, release note, or media page. |
| Reviews | Existing review post types and rating fields, scoped to a community or stable product object, with optional shared Social rating and AI-summary surfaces. | Product or service detail section. |
| Product Q&A | Existing question post types and direct answer replies, scoped to a product object. | Product detail or product-documentation section. |
| Community Feed | The community's existing feed, post types, badges, sort, composer, and post pages. | Community home, dashboard, or app tab. |
| Polls | Existing poll or trivia post types and Zeeker's normal voting behavior. | Article, research, event, or course section. |
Availability is capability-driven. For example, Group Chat is not offered for a community whose chat capability is unavailable, and a review preset does not manufacture ratings if the Social review type is not available.
In an eligible public Group Chat with On gated action sign-in, visitors can type a message before signing in. Selecting Send opens the same compact sign-in sheet used by other Embed surfaces. Closing that sheet or completing sign-in keeps the draft; sending still requires an explicit Send afterward and any required community membership. The embed uses one header; its options menu contains theme and sign-in actions. There is no second sign-in button beneath the textbox. Theme changes keep the conversation and draft in place. Preview and read-only configurations do not enable drafting. Authenticated viewing, automatic sign-in, and host-managed sign-in continue to follow the saved access and identity policy.
Additional compositions available today
The eight presets are not the full limit of Elements. The following can already be assembled from the same generic controls without adding an Element-only feature:
| Composition | Existing Zeeker capabilities | Typical placement |
|---|---|---|
| FAQ / Help button | A host-owned trigger opens a question-only support community with native community search, or a curated pinned question thread. | Floating help action on desktop; help item in a mobile bottom tray; full-screen help destination. |
| Topic or channel feed | Existing topic feed, topic slug, community post types, sort, composer, pagination, and post navigation. | Announcements, release notes, event channel, resource hub, or campaign page. |
| Pinned discussion | Existing thread pinned by ID, with the ordinary reply composer optionally shown or hidden. | Office hours, release discussion, curated FAQ answer, or announcement follow-up. |
| Ideas / public feedback board | A dedicated community or topic with discussion/question posts, custom badges, reactions, moderation, and top/trending sort. | Full customer portal or app tab. This is public community feedback, not a private form or ticket inbox. |
| Event hub | Group Chat, question posts/answers, polls, and a topic/community feed. | Event website or companion app screen. |
| Learning companion | Lesson comments, questions/answers, trivia, and polls keyed to a stable lesson object. | Course page or learning app screen. |
| Product engagement hub | Product Reviews, Product Q&A, and contextual Comments keyed to one stable product object. | Product page or commerce app screen. |
| Engagement action bar | Existing discussion, community, chat, like/reactions, share, save, and hide actions. | Article footer, product toolbar, sidebar, or mobile host chrome. |
| Discussion CTA / count button | Existing discussion launcher and reply count. | Content card, article footer, guide, or product listing. |
| Conversation nudge | Existing time/scroll-depth reply preview that opens the canonical discussion. | Long-form article, documentation, or product page. |
| Discovery snippets | Recent/top/trending posts, trending topics, or top users in the existing snippet layouts. | Homepage rail, sidebar, dashboard, or under-content block. |
| Welcome / outreach message | Community-owned one-time outreach content shown inside an eligible community or chat surface. | Community feed or chat entry experience. |
Ticket/SLA management, roadmap merge/status workflows, a general custom form builder, and verified-purchase review workflows still require additional product capabilities.
What the community controls
Community owners configure the underlying Social experience in the Admin Center. These settings apply to Social and every embed for that community:
- Community access: Public or Private;
- Zeeker visibility: Connected to Zeeker or Direct access only, subject to the community's access rules;
- membership, viewing, posting, moderation, uploads, reactions, replies, and sharing;
- allowed root-post and reply types, including existing question, review, and poll types;
- community-defined badges and the default feed sort;
- whether related posts appear on ordinary post pages and whether that related set may include eligible external posts;
- whether community chat is enabled;
- community SSO, whitelabel, branding, rules, and moderation settings.
An embed cannot turn on chat, a root-post or reply type, external content, or an action that the community has disabled. Contextual collections use typed replies beneath the host object's canonical Social post, while community feeds use root posts, so each is checked against the matching Community setting. An embed also cannot make Private posts public or expose a Direct access only community in global Zeeker discovery. Allowed websites and sign-in requirements still apply.
An explicit empty structured-type selection means text discussions/comments only; it does not mean “all types.” Legacy communities whose selection has never been set remain compatible with the previously available types until an administrator saves a deliberate policy.
What each embed controls
An embed can narrow the community capability and adapt its presentation without changing Social's underlying behavior:
| Area | Embed controls |
|---|---|
| Content and navigation | Stable URL/object/thread resolution; allowed subset of community post types; whether the standard community card, native community search, the optional embed top header, the contextual root, post content, or the normal post header is shown; related-post mode (inherit, community-only, or off); same-embed or new-page post opening; and whether outside access is Strictly containerized, limited to profiles, or open to permitted Social destinations. |
| Conversation | Stable URL/object/thread resolution, whether the standard composer is shown, and whether that composer sits above or below the content. Reply ordering continues to follow Social and community rules. |
| Loading and scroll | Host-page scrolling or an internal scroll region, plus infinite loading or an explicit Load more control. Inline Element presets start with host-page scrolling so their container follows the native content height instead of reserving an empty viewport. |
| Reviews | Whether the shared Social rating average/distribution is shown and whether the optional grounded AI review summary is requested. |
| Appearance | auto, light, or dark; transparent or filled outer background; accent and typography; generic container border width/style/color/radius; and an optional generic top header with its own border/background treatment. |
| Identity | Public or authenticated reads, read-only or authenticated participation, permitted login method, and when the login flow begins, within the community's access and SSO ceiling. |
| Connection | Connected behavior, or Embed only when the deployment reports the complete server content-isolation capability. This does not replace the separate outside-access choice. |
| Placement | Anchor floating launcher, host-owned/custom trigger, fixed inline, or full-screen. Placement changes only the container, not the selected Social or Chat capability. |
The generic top header and outer container border are presentation primitives, not new product chrome. Element-specific border radius applies only to that outer embed/container/header boundary. Post cards, reply rails, action trays, composers, badges, search, review summaries, and other content inside it reuse Social's components and styling. A fixed in-page Element has no close button because it is part of the page. Dismissal controls belong only to floating panels, drawers, sheets, and other overlays.
Similarly, a global Social navigation button belongs only in a full-screen Social experience. A focused inline Element does not add Social navigation to the host app. When outside navigation is allowed, a signed-in profile control may open that person's canonical profile on zeeker.com; the embed's outside-access policy can also block that route.
Server content isolation versus outside access
These settings protect different boundaries. Connected content may use any outside-access choice; Embed only always forces the strict outside-access choice:
| Setting | Boundary it controls |
|---|---|
Embed only (networkMode=embed_only) | Server-side ownership, reads, writes, relationships, discovery, and revocation for content owned by one exact config. It keeps that content out of ordinary Social, but it is not the setting that removes every visible link from the Element. |
Strictly containerized (outsideAccess=blocked) | The Element's navigation and discovery surface. It keeps the visitor inside the host experience, but it does not move Connected content into isolated storage. |
With Strictly containerized outside access, Search is limited to posts and replies from the exact configured community. It has no People, Communities, or topic-discovery surface, filters out out-of-community results even if a stale response contains them, and does not render redundant community links, profile/community click targets, or profile/community hovercards. Author names and community context can still appear as non-navigating identity where the canonical Social component needs them.
The other outside-access choices are deliberate Connected-mode escape hatches. Profiles only permits canonical author/member profile destinations while keeping post, community, topic, and arbitrary HTML exits blocked; it may also retain user-profile previews. Profiles, posts & communities permits the normal canonical Social destinations supplied by that Connected surface. Both are disabled for Embed only, and the loader treats any stale permissive value as blocked. A Connected + Strictly containerized Element remains visually contained, but its content is still ordinary Connected Social content.
Preset examples
A Support Forum preset initializes a full-page feed to show an allowed question post type, anchors the existing composer at the bottom, uses the community's default sort, exposes Social's existing community-scoped search, and opens a question in the same embed. Publishers can explicitly move the composer to the top; in that mode it remains in document flow when expanded so it cannot cover the support guidance or posts. Its standard community card starts hidden. During preset application, Embed programmatically injects the implementation-owned support-information box; no Admin Center editor or per-embed HTML/show-hide control is exposed. The box sits immediately above the feed-filter header, is capped at 300px, and follows the same resolved border and corner treatment as the surrounding Embed surfaces. It keeps an opaque themed surface when the fixed Embed canvas is transparent. Search and composer controls remain solid Social surfaces as well. The Element still renders the ordinary Zeeker community feed, composer, post cards, and post page; it does not add Support-specific tabs, counts, filters, headers, or cards.
Server-rendered host integrations can request the public discussion snapshot for one canonical HTTP page. The endpoint never creates a thread and is disabled until the global SEO launch gate is enabled. It returns a bounded, cursor-based set of direct approved replies only when the published config allows public reading, its configured site matches the discussion origin, and the community has Public access, is eligible for Zeeker discovery, and is non-NSFW. Communities with Direct access only or legacy Unlisted access, Private communities, authenticated-only configs, anonymous content, moderation removals, deleted content, private or deactivated account authors, and mismatched Embed isolation partitions fail closed. The JSON endpoint and its oEmbed player are themselves always noindex. The publisher must put the escaped summary in visible host-page HTML outside the interactive mount. Fixed Elements can place it before the mount; floating and host-triggered Elements use a deliberate visible section of the article or product page. Neither placement changes the publisher's canonical or guarantees indexing/rankings. See Publisher-page search.
When an inline Element uses a transparent background, the document, loader shell, Social canvas, and internal navigation/header rows all remain transparent. Individual navigation controls keep solid themed backgrounds; native post cards, composers, search, sign-in panels, and information surfaces also remain opaque. Detached panels and full-app surfaces keep their own opaque canvas. In host-page scroll mode, Social reports its natural height through the loader after content, composer, and route changes. Moving a composer to the top therefore does not leave its former bottom viewport behind.
A Reviews preset initializes the existing review post type for a product object. Top-level contributions in that collection are locked to Review, so the root composer does not offer Post, Question, Poll, or Trivia. Ratings and review fields come from the canonical Social post model. Replies beneath an individual review use Social's ordinary reply composer and do not become additional reviews. The shared Social review surface can optionally show the average, total, and five-to-one-star distribution. A second independent option may show a grounded AI summary generated from reviews the viewer is already permitted to read. Only genuine model output is labelled AI review summary; when no generated summary is available, that AI-labelled block is omitted. Social may separately show deterministic Review highlights, which are never presented as AI. Neither option creates an Embed-only ratings or merchant-reply system.
A Product Q&A preset similarly uses normal question posts, reply threads, community roles, and existing badges. A direct reply to a question is stored and rendered as Social's existing answer type, including the normal Answer badge; deeper replies continue to use their canonical Social types. Embed does not add merchant labels or a separate answer workflow.
Setup
Create an experience at https://embed.zeeker.com:
- Create or select the community that owns its content and permissions.
- In Choose, pick an experience or start from a custom embed.
- In Place, choose an Anchor button, your own button, an inline mount, or full-screen opening. Preview desktop and mobile without choosing a deployment platform yet.
- In Preview, name the embed and choose its language. Optionally open Change style or Access settings, then choose Create draft.
- Refine the draft in Customize, verify the preview, and publish it. Deploy provides website, native SDK, and WebView instructions for that same configuration.
The main creation path stays concise. Fixed content is grouped under Elements, floating activation under Triggers, and both offer Appearance and Restrictions. The community continues to determine which features and identity options are available.
Web implementation
The generated web install reserves the responsive slot before the asynchronous loader runs:
html
<style>
#product-community { min-height: 680px; }
@media (max-width: 640px) {
#product-community { min-height: 600px; }
}
</style>
<div id="product-community"></div>
<script
src="https://embed.zeeker.com/api/embed/widget/loader.js"
data-zeeker-config="YOUR_CONFIG_ID"
data-zeeker-mode="fixed"
data-zeeker-target="product-community"
data-zeeker-height="680"
data-zeeker-mobile-height="600"
data-zeeker-app-id="storefront"
data-zeeker-object-type="product"
data-zeeker-object-id="sku_12345"
data-zeeker-object-title="Canvas Weekender"
data-zeeker-object-url="https://shop.example.com/products/canvas-weekender"
async
></script>The config supplies the saved Social composition and policy. The host object supplies context. Publisher code must not attempt to select an Element kind or weaken access with query parameters.
Keep appId + objectType + objectId stable across platforms when a thread or allowed post set belongs to a host object. A canonical data-zeeker-url is also supported for URL-scoped web content.
Mobile implementation
The Deploy tab supplies native iOS and Android SDK examples and a WebView fallback. A native host passes the same config ID and stable object identity used on the web:
swift
let config = ZeekerConfig(
configId: "YOUR_CONFIG_ID",
mode: .fixed
)
let product = ZeekerObject(
appId: "storefront",
objectType: "product",
objectId: "sku_12345",
title: "Canvas Weekender",
description: nil,
imageUrl: nil,
url: "https://shop.example.com/products/canvas-weekender"
)
let element = ZeekerEmbedView()
element.load(config: config, object: product)The corresponding Android integration uses ZeekerConfig, ZeekerObject, and ZeekerEmbedView. WebViews can use the web loader with data-zeeker-native="webview" and the same object identity. See Installation.
Embedded post pages keep Social's mobile interaction model: the normal post/reply layout, bottom reply composer, back behavior, and supported swipe navigation remain intact. A focused Element does not replace the reply composer with the community-feed pen FAB or add an Element-specific action tray.
Every Element exposes the same four placement choices during creation and customization: Anchor launcher, your own button, fixed in the page, and full screen. Chat presets start with the Anchor launcher because that is usually the least intrusive integration: a floating Chat action on desktop and a compact Chat action in the mobile tray. A customer may explicitly choose fixed Chat or full-screen Chat when the host layout calls for it. Fixed Chat is part of the page and has no close button; launcher and custom-trigger Chat open a dismissible panel or bottom sheet.
Chat sign-in is a secondary action inside the opened destination. When the Zeeker ID flow needs more vertical room, Chat reports the required content height through Social to the Embed loader; the panel or sheet expands up to the safe viewport limit and restores its normal height when sign-in closes. The auth content itself remains scrollable on a genuinely smaller device.
Connection and identity policy
Connection is per embed and separate from the parent community's Community access and Zeeker visibility choices. It does not bypass those policies or the allowed-website and sign-in restrictions.
| Setting | Values | Current behavior |
|---|---|---|
| Connection to Zeeker | connected, embed_only | Connected participates in ordinary Social. Embed only uses one exact config-owned partition when the deployment reports isolation as available. |
| Outside access | blocked, profiles, social | Strictly containerized, profile destinations only, or normal permitted Social destinations. This controls navigation and scoped discovery, not server content ownership. |
| Who can view | public, authenticated | Public permits signed-out reads only when community access rules permit them. Authenticated withholds content until identity succeeds. |
| Who can participate | disabled, authenticated, guest | Read-only, signed-in, or named-guest participation. Guest-enabled surfaces still offer login/signup; Continue as guest is an additional choice. |
| Sign-in method | zeeker, community_sso, either | The embed can narrow the identity choices. Community SSO must already be enabled on the parent community. |
| When to sign in | on_action, on_load, host_managed | Begin on a gated action, request eligible SSO on load, or let the host own the prompt and call window.zeeker.identify(jwt). |
SSO provider setup, secrets, domains, and redirect behavior remain community-level. An embed can choose how it uses that configured provider, but cannot create or replace it.
Deployment capabilities fail closed
Embed only and named guests are selectable only when every participating service reports the required exact-config storage, authorization, and signing capabilities. If a prerequisite is absent, the dashboard and API reject the config or boot instead of silently falling back to Connected or ordinary Social/Chat storage.
Guest participation boundary
guest means an unauthenticated, config-scoped visitor—not Social's existing Anonymous attribution option. Anonymous attribution still belongs to an authenticated Zeeker user. A guest flow must collect a non-empty display name before its first write and bind the resulting principal to one published Embed configuration.
Guest participation is always Embed only. New guest configurations default to embed_only, and the API rejects an explicit guest + connected combination so guest posts cannot enter ordinary Social feeds, profiles, search, SEO, notifications, or analytics. The login sheet keeps normal login/signup and adds Continue as guest only when the runtime capability response says scoped guest contribution is available. The guest must supply a display name. Unsupported guest mutations fail closed; the UI never substitutes the authenticated Anonymous toggle.
Capability is surface-specific. Social posts/replies and Chat each enforce config-bound storage, exact revision checks, revocation, and separate abuse limits. A surface remains signed-in or read-only if its own boundary is not available.
What Embed-only isolation means
Embed-only is the server content boundary, not a synonym for the Strictly containerized outside-access presentation. An Embed-only post or reply has immutable ownership by one exact embed config. A request scoped to that config sees only its own isolated content—not a union with the community's ordinary Social content and not content owned by another config, even when both configs belong to the same community. Ordinary Social requests see only non-isolated content, so an ordinary direct Social URL is not an escape hatch into the isolated partition.
The boundary also applies to relationships and counts. Replies, parents, references, connected sequences, accepted answers, selected replies, related content, reactions, and cached query results must remain in the same exact partition. A public/Connected post cannot be moved into Embed only later, isolated content cannot be converted into public Social content, and an owning config cannot be moved to a different community after it has isolated content.
As a result, isolated activity is absent from ordinary Social home and community feeds, global and community search, profile posts/activity/stats, Social notifications and digests, public topic/trending/popular/authority calculations, sitemaps, SEO pages, and shared Social analytics. Authorized owners can still use scoped Embed/config reporting and private community insights; those reports do not publish the underlying content into Social discovery.
Short-lived scope and immediate revocation
The loader obtains a short-lived, signed scope naming the exact config, community, mode, and current config revision. That scope selects a partition; it is not a user identity or a substitute for community membership. Normal Zeeker login or community SSO and the current community/embed access rules still apply.
Every scoped Social request compares the scope with the live published config. Any config edit advances its revision, so an already-running client loses its old scope on its next protected request. Pausing, unpublishing, or changing the config out of Embed only also revokes access immediately at that boundary. The runtime may request a fresh scope only while the config remains published and eligible; it never retries as Connected.
Embed-only Chat also uses config-owned conversations and messages. Authenticated members and named guests therefore never fall through to the community's canonical Connected group or MOD rooms. Each scoped Chat read, update poll, and mutation rechecks the live config revision and publication state, the embed and community Chat switches, the exact config conversation, and any current membership or staff role required by that path. Removing a member, demoting MOD Chat staff, disabling the applicable Chat feature, revising the config, or unpublishing it revokes the affected access on the next request.
Theme behavior
Each embed saves auto, light, or dark:
- Auto follows the effective host color scheme and responds when it changes.
- Light stays light when the host or preview switches to dark.
- Dark stays dark when the host or preview switches to light.
The preview theme control simulates the host. It changes the embedded surface only when the embed theme is Auto. See Theming.
Previews and public demos
The dashboard preview loads the actual configured Social surface. Draft overrides require a short-lived, config-bound signed preview token. Verified previews are read-only and private/no-store; unsigned preview parameters cannot authorize draft behavior.
Public routes are split by purpose:
Overview pages use illustrations and do not boot the runtime. Each /demo route explicitly labels and shows the actual published Zeeker implementation—not a reconstructed mockup—inside representative website and mobile-app host pages. On a narrow viewport the demo mounts only the mobile implementation and explains that the desktop implementation is available on a desktop-width screen; it does not squeeze or boot the desktop runtime off-canvas. The embedded area is the canonical Social or Chat implementation selected by its ordinary settings, while the surrounding page only supplies host context and must not clip or cover the runtime.