Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/korynthian/chatroom/llms.txt

Use this file to discover all available pages before exploring further.

kChat is a fully static application — every page is plain HTML, and all logic runs in the browser through vanilla JavaScript. There is no build step, no server-side runtime, and no compilation required before deployment. This means you can host your own kChat instance on any service that is capable of serving HTML files over HTTPS, including free tiers of GitHub Pages, Netlify, and Vercel. The only external dependency at runtime is the Supabase project you configured during setup.
Your Supabase project URL and publishable API key are embedded directly in chat.js and indextablenames.js, which are downloaded by every visitor’s browser. Never use your Supabase service-role (secret) key in these files. The publishable (anon) key is designed for client-side use, but it is still visible to anyone who views the page source. Protect your data by configuring Row Level Security policies in Supabase (see below).

​
Hosting Options

GitHub Pages serves static files directly from a repository branch at no cost.
  1. Push the kChat directory (with your credentials already set in chat.js and indextablenames.js) to a GitHub repository.
  2. In the repository, go to Settings → Pages.
  3. Under Build and deployment, set Source to Deploy from a branch, choose the main branch, and set the folder to / (root).
  4. Click Save. GitHub will publish the site within a minute or two and display the URL (typically https://<your-username>.github.io/<repo-name>/).
No build command is needed. GitHub Pages will serve index.html as the default document for the root URL.

​
Securing Your Data with Row Level Security

Because the Supabase publishable key is visible in client-side JavaScript, anyone who finds your project URL could, in principle, read or write to your Supabase tables directly. Supabase’s Row Level Security (RLS) feature lets you define fine-grained policies that control exactly which operations are permitted on each table. At a minimum, consider adding RLS policies that:
  • Allow any user to read (SELECT) from the messages and rooms tables.
  • Allow any user to insert (INSERT) into the messages table.
  • Restrict UPDATE and DELETE on messages to the row owner or an authenticated admin role.
You can enable RLS and add policies from the Authentication → Policies section of the Supabase dashboard, or via the SQL editor. Refer to the Supabase RLS documentation for full details.
All user preferences — including username and any custom CSS theme — are stored in the browser’s localStorage. This data is local to the device and browser you are using; it is not written to Supabase and will not carry over to other devices or browsers automatically.

Build docs developers (and LLMs) love

Get started for freeTalk to us