Widget placement

The launcher (the floating action button, or FAB) sits in a screen corner and expands into the chat panel. You choose the corner, drive open and closed state from your own UI, and hand the assistant the page the user is looking at, all through diosc().

diosc('setPosition', 'bottom-left'); // anchor the launcher in the bottom-left corner
diosc('open');                       // expand the panel

Anchor the launcher

setPosition flips which corner the launcher and panel anchor to. It takes one of two values:

diosc('setPosition', 'bottom-left');
diosc('setPosition', 'bottom-right');

Any other value is ignored and the launcher stays where it is. The corner you set at runtime wins over the backend default, so a later change in the admin portal can’t move a launcher your code has pinned.

Lift the launcher above your own layout

When the launcher sits behind a drawer, modal, or scrim of yours, raise it with the --diosc-fab-z custom property. It controls the launcher’s stacking order; the default is 50.

:root {
  --diosc-fab-z: 200; /* above your drawer's z-index */
}

Note

Set --diosc-fab-z somewhere the page inherits it from, such as :root. In fullscreen and on mobile the panel always sits on top so it can cover your chrome. This property affects the launcher and the docked panel, not those covering states.

Open and close it from your UI

Drive the panel’s open state from your own buttons, deep links, or onboarding flow:

diosc('open');   // expand the panel
diosc('close');  // collapse to the launcher
diosc('toggle'); // flip between the two

Open state is remembered for the rest of the browser tab. If the user has the panel open and the page reloads, it comes back open, so diosc('open') on load is safe to call every time without fighting the user’s last choice. The state resets when the tab closes.

Hand the assistant the current page

The assistant answers better when it knows what the user is looking at. There are two ways to pass that context, depending on whether your app navigates between pages.

For a single-page app, register a navigation observer once. DioscHub hands it a notify callback; call that callback with your page context on every route change, and the assistant stays aware of where the user is.

diosc('observe', 'navigation', (notify) => {
  router.afterEach((route) => {
    notify({ path: route.path, title: route.meta.title });
  });
});

To attach context to a single message instead (for example, a “Ask about this order” button) pass it as the second argument to invoke:

diosc('invoke', 'Summarize what I can do here', { path: '/orders/1042', orderId: '1042' });

Context is for the assistant, not for auth

Page context is plain page data: a path, a record id, a title. Never put an auth token or credential in it. Identity is bound host-side and forwarded opaquely; routing a credential through diosc() defeats the model that keeps it out of the assistant’s reach. See Identity & auth.

What the user sees

1. Your code calls diosc('setPosition', 'bottom-left'), and the launcher slides to the chosen corner.

2. The user clicks the launcher, or your UI calls diosc('open'), and the panel expands.

3. As the user navigates, your navigation observer feeds the assistant the current page.

4. The user closes the panel; the choice is remembered for the rest of the tab.

---

Next: let users @-mention your own entities in the message box with composer mentions.