Hollahoop

HollaHoop

Sign in
Feedback

General

Anything else.

New post
All typesFeatureBugTweak

How does Hollahoop compare to UserJot / Canny?

Honest answer: the *shape* is similar — feedback boards + voting + roadmap kanban + changelog + docs. The differences: - **Self-hosted-first.** The reference deploy is a single VM with self-hosted Supabase, Postgres, and Garage S3. No vendor lock-in on the data tier. - **Per-project everything.** Every plugin/app/system gets its own public surface — feedback, roadmap, changelog, docs — under its own slug. - **Built in public.** We dogfood Hollahoop on Hollahoop, so you can see exactly what we're working on and what's shipped.

ShippedGeneral·7 days ago·0

Sidebar collapse toggle: floating chip, modern look

The collapse / expand control had two problems. (1) The lucide PanelLeftClose icon felt heavier than the rest of the portal chrome. (2) The button moved between the brand row (when expanded) and a separate block above the user card (when collapsed), which made it feel like the control jumped down the rail when you clicked it. Replaced both with a single floating chip pinned to the right edge of the sidebar near the top, in the SAME position whether the rail is full-width or a 56px column. Uses ChevronsLeft / ChevronsRight icons for a cleaner Linear / Vercel feel, sits as a small rounded pill with subtle ring + shadow, and hangs half over the border so it reads as a separate floating control rather than another nav row. Also removed overflow-y-auto from the admin rail aside so the chip never scrolls out of view on short viewports.

TweakShippedGeneral·1 day ago·0

Settings sub-nav: API and all config under one Settings surface

The admin sidebar used to expose **API** as its own top-level entry alongside Feedback, Roadmap, etc. Configuration was split across two surfaces (top-level "API" + a separate "Settings" page that only had General). Now the project sidebar focuses on day-to-day work and **every configuration destination lives under Settings** with a shared left-rail nav: General, Privacy & Access, Login & SSO, Domain, Widget, Changelog, Integrations, **API**, Members, Billing, Data, Help. The Settings sidebar item stays active for any nested route. - New shared `settings/layout.tsx` wraps every settings sub-page with the rail - `SettingsNav` highlights the active page (with prefix-match for `/api-keys/*` etc.) - Removed the standalone "API" item from the admin sidebar You only have to learn the word "Settings" once.

TweakShippedGeneral·1 day ago·0

Inline search input in sidebars (with / and ⌘K shortcut hint)

The search trigger was previously a tiny icon-only button tucked into the sidebar header. Discoverability was poor. Both portal sidebars (admin + workspace) now show a **small inline search bar** that: - Reveals the `/` keyboard hint inline - Opens the same command palette modal on click, ⌘/Ctrl + K, or `/` (when no input is focused) - Collapses back to the icon variant when the sidebar is collapsed (see related card) The bar is `variant="bar"` and shares the same `<SearchTrigger>` component used elsewhere, so behaviour stays consistent.

TweakShippedGeneral·1 day ago·0

Status history audit table

Foundation for cycle-time analytics, lead-time stats, the Timeline view, and stale-item alerts. New post_status_history table: id, post_id, from_status_id, to_status_id, changed_by, changed_at. Populated by an AFTER UPDATE trigger on posts when status_id changes. RLS: read-only to project members. Unblocks immediate analytics features: median request to shipped, time-in-status, and a public "shipped 23 user requests in 90 days" stat for the marketing surface. No UI in this card - strictly the table + trigger + a tiny query helper. UI cards reference this one as a dependency.

ShippedGeneral·2 days ago·0

Three-way theme switcher: light / dark / system

Theme used to be a binary toggle (light or dark). Many users want their dashboard to follow OS preference, so the system option is now first-class. - New shared module `src/lib/theme/theme.ts` with `readSavedTheme`, `setTheme`, `applyTheme`, `subscribeToSystemTheme` - All four entry points use it and stay in sync: top-bar `ThemeToggle`, sidebar account popover, public user-menu submenu, and `/app/account/appearance` - `system` resolves `prefers-color-scheme` at apply time and live-listens for OS changes via `matchMedia` - Pre-paint inline script in the root layout pins the resolved theme on `<html>` before hydration, so there's no FOUC Closes the related "Theme toggle flickers on first paint (FOUC)" card.

FeatureShippedGeneral·1 day ago·0

Customisable docs sections (create / rename / reorder / delete)

Docs sections were previously hard-coded to the seed values (Getting started / Guides / Reference) — there was no admin UI to add or rename them. You can now manage your docs taxonomy entirely from the docs admin page: - **Add** any header you want — Cookbook, FAQ, API reference, Tutorials, Migration guides, … - **Rename** existing sections inline (header + slug) - **Reorder** with up/down arrows (`position` swap) - **Delete** safely — pages are orphaned (`section_id = null`) rather than dropped, so it's reversible Behind the scenes: - New server actions: `createDocSectionAction`, `updateDocSectionAction`, `moveDocSectionAction`, `deleteDocSectionAction` - Slug uniqueness via the existing `(project_id, slug)` constraint, with a friendly error when collisions happen - Confirmation prompt warns when a delete will orphan pages

FeatureShippedGeneral·1 day ago·0

Collapsible portal sidebar with full lockup expanded and icon-only when narrow

Both portal sidebars (admin project rail + workspace org rail) are now **collapsible**. The full Hollahoop lockup (mark + wordmark) shows when expanded; just the icon mark renders in the 56px-wide collapsed rail. - New `useSidebarCollapsed` hook persists state to `hollahoop-sidebar-collapsed`, syncs across instances via custom event + storage event - `SidebarCollapseToggle` button (PanelLeftClose / PanelLeftOpen) - Pre-paint script in root layout pins `<html data-sidebar-collapsed>` before hydration so the rail never flashes the wrong width - Keyboard shortcut: **Ctrl/Cmd + B** (skipped if focus is in an input) - Search switches to icon variant, nav rows become icon-only with `title` tooltips, workspace org tree collapses to clickable org glyphs - User card in collapsed mode is an avatar pill; popover floats out to the right (`left-full ml-2 w-60`) so it isn't clipped - Width animates with `transition-[width] duration-200` Also fixed the previously-broken `BrandLockup` component: it referenced PNG assets that didn't exist on disk, so it now renders the existing SVG mark + a typographic wordmark that inherits theme foreground colour.

FeatureShippedGeneral·1 day ago·0

GDPR data export and deletion workflows

Legal and trust foundation for EU customers. Users can request a machine-readable export of their profile, posts, comments, votes, subscriptions, tickets, and notification preferences. Admins can export organisation data for compliance. Deletion flow supports self-service account deletion plus admin-assisted data erasure with confirmation and audit logging. Requirements: asynchronous export job table, signed short-lived download URLs, deletion preview showing what will be removed/anonymised, retention policy hooks for billing/support audit data, and clear distinction between deleting content vs anonymising authorship where shared team records must remain. Integrates with the audit log card and account settings.

PlannedGeneral·2 days ago·0

API rate limiting and abuse hardening (platform-wide)

Generalises the per-key rate limiter already shipped in src/lib/api/rest.ts to every public ingress, not just the v1 REST endpoints. Per-IP limits on unauthenticated public surfaces (feedback submission, comments, vote, signup, login, password reset, public hub reads), per-user limits on authenticated mutations, per-project burst caps so a single noisy project cannot drown the platform, and per-org daily envelopes so a misbehaving customer cannot spike infrastructure. Implementation: a small ratelimit table keyed on (scope, identifier, window_start) backed by a Postgres advisory-lock token bucket, plus an in-memory layer for hot endpoints. Fail-closed on Supabase outage; fail-open only when the limiter itself is unhealthy. Brute-force throttling on /login and /auth/* with exponential backoff per IP and per email. Captcha challenge (hCaptcha or Turnstile) auto-injected on suspicious traffic patterns - not on every request. Strict body size limits per endpoint (e.g. post body 20kb, ticket body 200kb, attachments via the upload card only). Slow-loris timeouts. Standard 429 responses with x-ratelimit-* headers and Retry-After. Surfaces a /admin/abuse internal dashboard (Hollahoop staff only, gated by is_hollahoop_admin) showing recent 429s, top noisy IPs, and a manual block list. Audit log integration: every block/unblock recorded. Out of scope: WAF/CDN-level DDOS (handled by the deployment edge if used), full bot detection ML - this card is the deterministic safety net.

PlannedGeneral·2 days ago·0

Avatar upload to object storage (replaces URL text input)

The profile screen used to ask users to paste a public image URL into an "Avatar URL" field — fine for tech-savvy folks, awkward for everyone else. Now the avatar field is a **proper upload control**: - Click, drag-and-drop, or paste-from-clipboard a PNG / JPG / WebP / AVIF / GIF / SVG (≤ 10 MB) - Files go through `/api/uploads` with `kind=avatar`, which authenticates, validates MIME + size, and stores under `avatar/<user_id>/<uuid>.ext` in the public Supabase Storage bucket (S3-compatible) - Each user's avatars are namespaced to their own user-id folder, with the storage path derived server-side from `auth.uid()` so it's unforgeable - "Replace" + "Remove" actions inline; persists immediately on upload so the sidebar widget refreshes via `router.refresh()` without forcing the user to click Save The DB column is unchanged — `profiles.avatar_url` still holds the public URL, just now pointing at a Hollahoop-owned storage object instead of an arbitrary external URL.

FeatureShippedGeneral·1 day ago·0

Privacy policy: Google OAuth data disclosure for verification

Google's OAuth verification team flagged that the privacy policy at /legal/privacy did not document how the application interacts with Google user data. The policy has been rewritten to satisfy Google API Services User Data Policy requirements. - Explicit table of every Google scope requested (openid / userinfo.email / userinfo.profile) with what each returns and how Hollahoop uses it - Explicit confirmation we do not request Gmail / Drive / Calendar / Contacts / Photos or any sensitive scope - 'What we don''t do' section: no resale, no advertising, no behavioural targeting, no AI/ML training on Google data, no human review (with the standard support / security / legal carve-outs) - Limited Use compliance statement linking to the Google API Services User Data Policy - Sub-processors, cookies, retention (30-day logs, 7-day account delete with up to 30-day backup tail), GDPR rights, contact, last-updated date - Replaced the original 3-paragraph policy with a structured 11-section document

TweakShippedGeneral·1 day ago·0

Automatic custom domain DNS setup (Cloudflare API and friends)

First-party setup flow for connecting a custom domain to a Hollahoop project. When the user pastes a domain and a provider token (Cloudflare to start, then Vercel DNS, Route53, GoDaddy, Namecheap), Hollahoop creates the CNAME / TXT / ALIAS records automatically. For providers without a public API, fall back to a generated step-by-step guide with the exact records to add manually. Includes propagation polling, TLS issuance status, and a reusable verification API so multiple Hollahoop features (project hubs, widget script CDN, support email) can hang off the same domain config. Makes the existing Custom domain for the widget script and Custom domains for public project hubs cards much faster to onboard onto.

FeaturePlannedGeneral·1 day ago·0

MCP server hardening: redundancy, rate limits, abuse and threat review

Audit the public MCP surface against the latest model-context-protocol best practices. Revisit per-key and per-IP rate limits, add a circuit breaker for sustained abuse, instrument health and response-time SLOs with auto-failover to a warm replica, redact secrets from error responses, threat-model the tool surface (prompt injection via tool descriptions, scope escalation), and document the security posture publicly. Roll the resulting controls into the existing API rate limiting and abuse hardening card rather than duplicating that work.

FeaturePlannedGeneral·1 day ago·0

Accessibility pass: WCAG 2.2 AA across portal, public hubs, widget, and API

Bring the entire product up to WCAG 2.2 AA. Front-end: keyboard reachability, focus-visible states, semantic landmarks, ARIA only where native semantics fall short, color contrast tokens audited in both themes, prefers-reduced-motion respect, captions and transcripts on demo videos, screen-reader pass on every primary flow (post create, comment, vote, status change, billing). Back-end: API errors return human-readable messages, error responses include WCAG-compliant status text for downstream renderers, server-rendered pages ship correct lang attributes, transactional emails use accessible HTML structure. Add an automated axe-core run to CI so regressions fail PRs.

FeaturePlannedGeneral·1 day ago·0

Theme picker on Profile page (Light / Dark / System)

The Light / Dark / System segmented control was previously only on the standalone Appearance tab. Users naturally look for it on the Profile page first, so it is now embedded directly in /app/account/profile alongside avatar, display name, and username. Extracted the segmented control into a single shared ThemeSegment component so the Profile form, the Appearance tab, the topbar toggle, and the sidebar/user-menu can never drift. Both surfaces auto-subscribe to OS preference changes when System is selected. Removed a personal-name placeholder from the Username input.

TweakShippedGeneral·1 day ago·0

Feature flags + Labs page (per-org and per-user beta opt-in)

Foundation that lets us ship features behind an opt-in beta toggle and graduate them when they are tested. Three small tables: feature_flags (key text PK, label, description, status enum stable|beta|internal|deprecated, default_on boolean, scope enum org|user|both, graduating_target date), org_feature_overrides (org_id, flag_key, enabled), user_feature_overrides (user_id, flag_key, enabled). Stable flags ignore overrides and are always on; internal flags are only visible to Hollahoop staff (auth metadata is_hollahoop_admin); beta flags surface in a new Labs settings page; deprecated flags show a sunset notice and refuse new opt-ins. New routes: /app/{org}/settings/labs (org owner toggles beta features for the whole org, with a per-flag "default for new members" choice) and /app/account/labs (each user toggles personal-experience flags). Code-side: useFeatureFlag(key) hook on client, isFeatureEnabled(key, {orgId, userId}) server helper, both pulling from a single in-memory registry that the build seeds from feature_flags. UI: every flag-gated screen renders a small "Beta" pill near its title pulled from the same registry, plus a one-line "this is opt-in and may change" disclaimer at the top. Cards already in the planned column (support inbox + ingestion + AI assist, team chat, live view, AI Suggest, AI moderation, GitHub integration, Twilio MFA) will register themselves with status=beta from day one and graduate to stable individually as they reach quality bar. Out of scope: percentage rollouts (50% of orgs see X), cohort-based gating, A/B experiment metrics - this is opt-in betas only, not an experimentation platform.

ShippedGeneral·2 days ago·1

Sentry integration: error monitoring, releases, and performance

Wire up Sentry on both the Next.js front-end and the Node/Edge server side. Capture client errors with source maps, server runtime errors, slow API spans, and Web Vitals. Tag every event with org_id and project_id so support can filter by tenant. Tie commits to releases via the Sentry CLI in deploy/deploy.sh, enable Cron monitoring for scheduled jobs (digest emails, AI background jobs), and add a Report this link in the global error boundary. Optional PR comments for new errors introduced by a change.

FeaturePlannedGeneral·1 day ago·0

Audit log: organisation and project activity trail

Append-only audit log for security, compliance, and admin trust. Capture who did what, when, from where: org/project settings changes, member invites/removals, role changes, billing changes, API key creation/revocation, integration connects/disconnects, support ticket sensitive actions, feature flag changes, post status changes, and destructive deletes. Schema: audit_events(id, org_id, project_id nullable, actor_id nullable, action text, target_type text, target_id text, ip_hash, user_agent_hash, metadata jsonb, created_at). RLS: owners/admins can read within their org; no updates/deletes from app role. UI: /app/{org}/settings/audit with filters by actor/action/date/target and CSV export. This becomes the trust spine for later GDPR, billing, support, and AI actions.

ShippedGeneral·2 days ago·1
HollahoopGet yours