This hub is a full UI/UX prototype, meetup.com-style. Data lives in localStorage so it's only visible in this one browser. To make it real:
1. Give groups and events real tables/APIs — GET /api/groups?search=&tradition=, GET /api/groups/:id/events — and replace loadAllGroups() / loadAllEvents() below with fetches.
2. Replace createGroup()'s and createHostedEvent()'s local saves with POST /api/groups and POST /api/groups/:id/events.
3. Swap the hardcoded AI_TEACHERS / HUMAN_TEACHERS lists below for a live pull from the real teacher directory (the data behind portals.html) — already generated from portals.html's real Portal 1 / Portal 3 rosters; regenerate the same way if that roster changes.
4. Two modes, two different gates. Private Scheduling (switchMode('private')) is a simple one-off event with no group, no listing, and no fee — unchanged in spirit from before. Meetup-Style is now a real Groups + Events model, like Meetup itself: an organizer creates a persistent, public Group (name, tradition, description), then schedules any number of Events under it. Organizer Access gates creating a Group, not each event — see gathering-donations-dev-spec.md v5 for the $6/mo ($3/mo for MST plan members after free trial months) pricing; once you own a group, scheduling more events under it is free, the same as Meetup charges for the group/listing tool, not per meetup. hasActiveOrganizerAccess() / getOrganizerAccess() / activateOrganizerAccess() are unchanged prototype stand-ins for a real subscription check — still client-side only, still needs a real Stripe checkout and a server-side check on POST /api/groups before launch.
5. Group ownership isn't enforced client-side in this prototype — anyone can click "Schedule an Event" on any group to see the flow, so the mockup is fully clickable end to end. A real launch must check group.organizer_id == current_user.id server-side before allowing POST /api/groups/:id/events.
6. Medium handling changed. Private events keep the old single exclusive Zoom/In-Person toggle (hostMedium). Meetup-Style events use checkboxes instead (mediums array), so an organizer can mark an event as Zoom, In-Person, or both at once (hybrid) — closer to how real Meetup groups actually run events. All rendering reads ev.mediums (array); older single-medium records are read as a one-item array for backward compatibility.
7. Data keys: mst_groups_index + mst_group_<id> for groups; mst_group_events_index + mst_group_event_<id> for events (now carrying a groupId, null for private ones). Search/filter (renderGroupsGrid()) is a client-side filter over localStorage — swap for real query params once there's a backend.
8. Visual theme: the Meetup-Style panel intentionally uses a lighter blue/white "app inside the app" look (.meetup-theme), distinct from the site's dark shell — both to make the mode toggle feel meaningful, and to preview what this could look like if it's spun off into its own standalone site later. Private Scheduling keeps the site's normal dark aesthetic, unchanged.
9. Sample groups/events (ensureSampleData()) exist purely so this isn't an empty page on first load — tagged isSample:true, shown with a "Preview" chip. Delete once real groups exist.
10. ⚠ "The avatar shows up in Zoom" is not built and is a separate, nontrivial project — today avatar-renderer.js only renders the avatar inside our own session.html page; nothing pushes it into an actual Zoom call. You'd need either (a) Zoom's Video SDK to add the avatar as a bot participant, or (b) a virtual-camera pipeline so people can select it as their camera source inside Zoom. Until then, the realistic near-term version is what's built here: the avatar lives in our own Live Session Room, kept open on a shared screen or device.
11. "How The Avatar Joins" placement — considered and intentionally left where it is. The explanation of how the avatar shows up on a shared screen (see #avatar-join-note on the event page) currently only appears once someone is actually setting up or viewing a specific gathering — the moment it's actually relevant, not before. We discussed also surfacing a shorter teaser version earlier in the funnel (e.g. on community.html, or the homepage's "Host Your Own Gathering" blurb) for people who are still deciding whether to host/attend and might have "wait, how does the avatar actually show up?" as an unspoken hesitation. Decided against it for now since it's a conversion nice-to-have, not a usability gap — revisit if that hesitation turns out to be common once there's real usage data. Would need community.html uploaded/reviewed to implement.
12. Tradition dropdowns are now a shared pattern (ALL_TRADITIONS, populateTraditionSelect(), handleTraditionSelectChange()): every tradition picker — the private and Meetup-Style filters, group creation, and the self-led gathering tradition field — shows the full canonical list (from AI_TEACHERS) rather than only traditions that already have content, plus a trailing "+ Create a Tradition" option on the creation flows (not the filters, where "creating" one doesn't make sense). Selecting it uses window.prompt() to add a new option live and unmoderated — fine for a prototype, but a real launch should route custom traditions through some kind of lightweight review step rather than adding them straight to a shared list, to avoid spam/duplicate/inappropriate entries. Also fixed a real gap this surfaced: self-led gatherings previously saved path: '' unconditionally, so they could never be found via tradition filtering — they now save whatever's chosen in the new #h-self-tradition field (defaults to "Open / Various").
13. Added Digital Twin as a third teacher type (DIGITAL_TWIN_TEACHERS, pulled from portals.html's Portal 2 roster — Eckhart Tolle, Thomas Merton, Jim Newman, Ramana Maharshi, John Astin). "Who's Guiding It" (host form) and "Centered Around" (create-group form) now offer AI Avatar / Digital Twin / Human Teacher / (Self, host form only) — checked against all three portals on portals.html to confirm no traditions were missing from ALL_TRADITIONS either (Portal 2's traditions are all already covered by Portal 1's list). teacherType: 'twin' is treated the same as 'ai' everywhere that means "this teacher renders as an avatar via session.html" (the Live Session Room note, Zoom join copy, the demo session link) — the two are only visually distinguished by their tag ("✦ AI Avatar" vs "◈ Digital Twin"), since a digital twin is still avatar-rendered, just modeled on a specific real person rather than a generic guide. Also extended the Meetup-Style search bar to match on group.teacherName, not just the group's own name/description/tradition — since people search for a specific teacher by name (e.g. "Ramana Maharshi") as often as they search by tradition.
14. ⚠ Meetup-style email notifications are NOT built — no code, no backend, nothing. The only trace of this idea anywhere in the prototype is a line of copy on the RSVP confirmation state ("We'll send a reminder as the session gets closer") — that's a promise shown to the user, not a real mechanism. This can't be built client-side at all: a browser tab can't wake itself up a week from now and send mail, so this entire feature has to live on a real backend. Below is the spec for what "basically works like Meetup" means here, written so it's ready to hand off (or pick back up) once there's a backend to build it on.