GPortal

Why GPortal exists

The Gooism collective has three constituencies that today coordinate through DMs, group chats, and the kindness of mutual friends: VJs, Artists, and Event Spaces. Information is lossy at every hop. GPortal is the unified surface that closes those loops.

GPortal lives under the Gooism collective umbrella, which is currently in a proposed structural phase (a 501(c)(3) is one of the options on the table, but nothing is decided — the Proposed Org Structure doc is the working draft, pending full collective approval + legal/financial advisor review). The accessibility-first mission is the through-line. Long-term home is gooism.org; short-term home is wallspace.studio/gooism/ while we build out the actual product surface at gportal.wallspace.studio.

Core entities

Three first-class profile types. Each entity owns its own profile, sets its own discoverability rules, and edits its own fields. Cross-references resolve into hyperlinks (a VJ's "primary venue" jumps to that Space's profile; a Space's "house VJ" jumps to that VJ; etc.).

Promoter v0.5 directory shipped

Intermediaries and hiring agents who book talent + run nights at venues. Sit in the middle of the model: they have a "client roster" (talent they hire) AND a "venue partnership" list (where they run shows). Distinct from artists (talent themselves) and spaces (venues themselves). Example: Boof Party in SF runs nights at The Midway, hires Fetz + collective VJs directly.

Multi-stage venues Shipped

Some venues have multiple bookable rooms with different capacity / rig / vibe. The Midway (SF) has main concert hall (1500), Concourse (350), Patio (250), Annex Studio (150), and an opt-in Pier 80 expansion (5000). Each gig books one stage; the parent venue is the contact + billing surface.

Stored as stages_json on the parent event_space_profiles row — we don't need stages to be queryable as their own rows, just attachable to gigs / bookings. Shape:

[
  { "name": "Main Concert Hall", "capacity": 1500, "screens": 4 },
  { "name": "Concourse",         "capacity":  350, "screens": 1 },
  { "name": "Patio",             "capacity":  250 },
  { "name": "Annex Studio",      "capacity":  150, "screens": 2 },
  { "name": "Pier 80 expansion", "capacity": 5000, "screens": 8,
    "notes": "Opt-in. Requires permit + Midway crew." }
]

Search & directories

Three directory views — one per entity — sharing one underlying CRUD pattern. Rate-range is a first-class filter alongside skills, geography, availability, and genre. Cards show overlap state at a glance so out-of-band matches stay visible (the negotiation door is always cracked open) without burying in-band ones.

Rate-overlap visual cue

Every directory card shows the entity's rate range vs. the searcher's range:

• In range — ranges overlap. Green border, prominent placement.
• Within 20% — near miss. Yellow border, "negotiable" tag if applicable.
• Out of range — greyed by default; "Show all" toggle reveals.

Cross-references

Every directory hop is a hyperlink. A VJ's primary_venue chips to the Space profile. A Space's house_vj chips to the VJ profile. An Artist's primary_vj chips to the VJ. The graph is bidirectional: from a Space's profile, you can see "VJs who have worked here" pulled from the venue_experiences join table.

Browse Packages Productized services view

Fourth directory: a packages-only view that cuts across VJs. Filterable by:

• Category — CRT cluster / projection / LED / live AI / recorded set / consult / mentor…
• Price range — absolute (e.g. "$200–$1500") or relative-to-budget overlap
• Duration — per-set / per-night / per-event / multi-day
• Lead time — "buyable in < 7 days" filter for quick-turn shows
• Travel radius — "covers my city without travel surcharge"
• Buyable directly — toggle to hide negotiation-only packages
• Has sample reel — only show packages with media so the buyer can see what they're getting

Each package card shows the offering VJ's name + rating, the included scope, the price, and a "Book this package" CTA. Direct path from category browsing to confirmed booking, bypassing the multi-message custom-quote loop entirely when both parties are aligned.

Event Planner

The matchmaking + staffing + costing surface. Inputs go in (artist + space + date), reconciled requirements come out (tech list, VJ shortlist, cost estimate, rider/cost split). Confirms into a saved event everyone can see.

Inputs → Auto-derived → Manual

Budget reconciliation panel

The planner's most distinctive surface. Side-by-side: venue VJ budget (min–max), shortlisted VJ rate ranges, artist fee, artist budget. Overlap state per pair shown as green/yellow/grey with a one-tap "negotiate" affordance that opens a thread pre-filled with the gap context. Same panel surfaces artist-fee vs. venue-artist-budget reconciliation.

Output

A saved event record visible to all participants (VJ, artist, space, optional collective admins). Exportable as a one-pager that includes the agreed rate, payment terms, and rider/cost split. Once confirmed and the event date passes, ratings unlock for all parties (§08).

Package suggestions alongside custom shortlist

The planner's recommendations panel shows two parallel rails: Custom-fit VJs (the rate-matched, skill-matched shortlist for a bespoke quote) and Buyable packages (already-priced offerings that fit the event's needs). Spaces and artists who already know what they want can skip the negotiation entirely and book a package; the rest get the traditional shortlist. Same backend, two UX paths.

Signal Planner Visual node-based App-agnostic

The technical design surface for an event — what's plugged into what, who runs which control, where each output lands. Visual node graph, not a form or spreadsheet. Signal flow is a graph; spreadsheets hide topology. Node graphs are how VJs already think.

Node types

Edge types

• Video — the dominant edge type; cyan in the canvas. Optionally annotated with bandwidth + latency budget.
• Audio — from mixers + audio sources into processors that need reactivity.
• Control — MIDI / OSC / keyboard mappings; grey dashed.
• Data — Spotify metadata, caption text, scene-trigger state.

WallSpace data-model reuse

WallSpace's Wall / CRT / Projector / LayerState shapes (src/renderer/types/index.ts) translate directly to Output and Input nodes. v1.0+ supports import-from-WallSpace (existing setup JSON seeds the graph) and export-to-WallSpace (graph becomes a scene scaffold). Same compositor mental model on both sides of the surface.

Templates

Pre-built common graphs the collective curates. Each ships as a starting graph + a description of when to reach for it. Examples: 4-CRT cluster + camera + ControlNet, two-screen DJ wall + Spotify + caption layer, 3D scene + remote camera ingest, recorded-only fallback rig.

Implementation: @xyflow/react on the GPortal app. Graph stored as JSON in events_internal.signal_graph_json. v0.1 ships a static demo at /planner; v0.5 ships interactive create + save + load.

Calendar & availability

Three-tier sync: manual entry (always works), iCal feed read-only (lightweight), Google Calendar two-way (v1.0). Availability surfaces in directories with privacy gating: public busy/free, detailed view to confirmed connections only.

Privacy

• Public: busy/free cells only. No event names, locations, or descriptions.
• Confirmed connections: see event names + venues for shared / mutual events.
• Owner: full detail.

Recurring availability windows ("I'm available Thursday–Saturday nights, never Mondays") express as a separate layer that doesn't have to compete with one-off blocks.

Chat & messaging

Async-first; per-event group threads + DMs. Real-time presence is a v1.5 stretch goal. No public message walls in v1 — comms is targeted, not broadcast.

Notifications

Email + in-app. Per-event muting; per-thread muting. Quiet hours respected from the user's profile timezone.

Ratings & reviews

Two-way: VJ ↔ Artist, VJ ↔ Space, Artist ↔ Space. Ratings only unlock for parties tied to a confirmed completed event in events_internal — no drive-by reviews, no review-bomb attack surface.

Edge-case handling and arbitration policies are an open question for the collective — see §16.

Integrations

Four external surfaces where GPortal pulls or interoperates: music platforms (Spotify + SoundCloud + Bandcamp + Apple Music), the 19hz event feed, Will's event.tools, and the Fetz intake form schema.

Music platforms Artist preview & embed

Every artist profile gets an embedded preview player so VJs and venues can sample an artist's actual sound before booking, and so artist research surfaces "what music am I designing visuals for?" in one click. Visual-design choices are genre-sensitive; today VJs Google an artist's Spotify after the booking locks. GPortal moves that step to before the conversation starts.

Profile fields (per-artist, all nullable): spotify_artist_url, soundcloud_url, bandcamp_url, apple_music_url, plus a preview_track_url the artist designates as their "listen to this first" calling card. Player UI: small embed on directory cards (collapsed; click to expand-and-play), full-size embed on the Artist detail page, and an "Open in [platform]" deep-link as the always-available escape hatch.

19hz.info CSV feed confirmed

19hz.info publishes plain CSV feeds at predictable URLs (https://19hz.info/events_<Region>.csv) with no auth and no API key — verified via the public phi-line/19hz.bot Discord bot scraping the same feeds. Available regions: BayArea, LosAngeles, Atlanta, Texas, Miami, Massachusetts. CSV columns: date, name, genre, location, time, price, ages, promoter, url1, url2, datetime.

• Cloudflare Cron Worker on a 30-minute schedule fetches each region's CSV.
• Upserts into events_external with source='19hz', region, and a content hash for change detection.
• Surfaces: public "Upcoming events" feed filterable by region/date/genre, plus an "Import from 19hz" affordance on internal event creation.
• Cross-link: when a 19hz event's location matches an event_space_profiles.display_name (fuzzy match), surface a "GPortal venue" badge on the imported event.
• One-way pull only — CSV is read-only. Internal Gooism events stay in events_internal.
• Geographic implication: 19hz covers six US regions, which sets a natural early-launch footprint.

Event-feed landscape v0.5 expansion

19hz covers underground West Coast electronic well, but a national, multi-genre footprint needs more sources. Below is the landscape we surveyed (per docs/SC5/vj_event_api_landscape.pdf), with the ingestion strategy GPortal will follow as we expand outward from the West Coast electronic feed.

Ingestion architecture (v0.5+):

• Core APIs: EDM Train + JamBase ride alongside the existing 19hz Cron Worker. One Worker per source; all upsert into the shared events_external table keyed by (source, source_id).
• Scraping layer: Resident Advisor + Shotgun via a Workers + Queue setup — one fetch worker per source/region, throttled, with content-hash dedup and exponential backoff on failure.
• Enrichment: Bandsintown enrichment runs as a per-artist follow-up: when an artist profile is created or updated with a Bandsintown URL, a background job pulls their tour dates and tags any matching events_external rows so we know "Artist X is playing this venue on Date Y."
• Output: a normalized event + promoter lead database that the Outreach module (§10) and Hiring & Bookings module (§11) both query. The promoter contacts pulled out of scraping flow into lookup_cache so outreach can target them directly.
• Key insight: APIs cover the mainstream surface; the underground, VJ-friendly opportunities live behind scrapes and curation. We treat 19hz / EDM Train / JamBase as the spine and add scrapes as targeted layers, not as the primary substrate.

event.tools (Will's product) Post-MVP

Future integration target. We want to hear what Will needs from GPortal before designing the interface. Listed here so it's not forgotten; not on the v0.1 critical path.

Fetz intake form

Reference doc: Fetz Artist/Event intake form. Used as a field-list reference when designing the Artist + Event intake schemas. No live integration; just structural inspiration.

VJ Outreach & Business Development Flagship growth feature

Live-music bookings outpace visual-element bookings — most events run with simple lighting because no one pitched the artist or venue. GPortal turns 19hz from a passive feed into an active BD engine, handing VJs the right event + the right context + the right template at the right moment.

The VJ growth loop

1. Browse 19hz events filtered to "no GPortal VJ attached."
2. Click event → Research panel pops up with artist socials, venue website, booking contact, recent activity, mutual GPortal connections.
3. Click Pitch → pick template + channel (email / Instagram DM / comment / story reply) → personalize via variable substitution → send (or copy to clipboard for native compose).
4. Outreach is auto-logged in the VJ's CRM view + soft-claimed in the collective — other Gooism VJs see "already pitched by X on date Y." No duplicate spam.
5. Status tracked: sent / opened / replied / declined / booked. Booking confirmation feeds the ratings system (only people who actually worked together can rate).

Lookup / Research module

A research-aggregator usable on any artist, venue, or promoter — not just outreach contexts. Cached per target (14-day TTL) so repeated visits don't hammer external services.

• Web search (Google / DuckDuckGo links, click-through)
• Social handles inferred + cross-checked: Instagram, TikTok, Twitter/X, Facebook, YouTube
• Music platforms: Spotify, SoundCloud, Bandcamp, Apple Music (see §09)
• Venue website + booking contact (parsed when findable, manually added by collective otherwise)
• Recent posts / activity (do they post visual content? — useful for tone calibration)
• One-click "Open all in tabs" for batch research before a pitch

Outreach template library

Curated by the collective, customizable per VJ. Faceted by:

• Channel — cold-pitch email, warm DM, comment / story reply, follow-up after silence, post-event thank-you
• Recipient role — artist, venue/booker, promoter
• VJ tier — new-to-the-scene, established, returning collaborator
• Variables — {{artist_name}}, {{event_name}}, {{venue}}, {{date}}, {{my_portfolio_url}}, {{my_recent_work}}, {{mutual}}

Template versioning + anonymized A/B success-rate tracking ("Template Y replied 38% of cold emails to BayArea venues") so the collective improves the library over time.

Outreach log (CRM-lite)

Per-VJ. Per-target row with channel + template + sent_at + status + response_at + notes + follow-up reminder. Filterable by target type / status / date range / event. CSV export for VJs who keep their own pipeline tools.

Collective claim & etiquette layer

• Soft-claim on first pitch — visible to other Gooism VJs (not the recipient). Cooldown 7 days before second collective pitch.
• Hard cap: max 2 collective outreach per event — prevents carpet-bombing.
• Etiquette callouts on send: "This venue replied 'no VJs needed' last month — proceed?" / "This artist already books with VJ Z (collective member) — courtesy DM to Z first?"
• All etiquette state is built from collective-shared signals, not assumptions; nothing is enforced as a hard block, just visible friction.

Hiring & Bookings

The inverse direction: artists and event spaces actively hiring VJ talent. Pairs with §10 to make GPortal a fully bidirectional matching engine.

Three entry points

Package buy flow

1. Buyer (artist or space) sees a package card with Buy button on the VJ's profile or in the packages directory.
2. Click → modal: target date(s), venue (autocomplete from Spaces or freeform), event description, optional add-ons (from addons_json), travel surcharge calculated automatically based on venue location, total price shown.
3. Buyer confirms. If buyable_directly=true, the package goes straight to the VJ's inbox as booking_requests.status='pending' with a package_id set; the VJ accepts (auto-confirms event) or counters (returns to negotiation flow).
4. If buyable_directly=false, the package surfaces but routes through standard inquiry — the VJ wants to vet fit before committing.
5. Confirmation creates events_internal with the package snapshot frozen on the event record (so future package edits don't change historical bookings).

Open gig flow

1. Artist or space clicks Post a gig → form: event date(s), venue, genre / vibe, required skills, required tech, expected duration, budget range, application deadline, additional notes, contact preferences.
2. Listing goes live in the Open Gigs feed — public board filterable by region / date / genre / budget overlap with the viewer's rate range.
3. Eligible VJs (matching rate range + skills + availability) see the gig with a green badge; near-misses see it greyed; out-of-budget hidden by default with a "show all" toggle.
4. VJ clicks Apply → form pre-filled from their profile (portfolio link, rate, recent work) + a personalized message + 1–3 portfolio reels. One click to submit.
5. Lister sees ranked applications (sortable by rate / experience / venue history / portfolio match). Shortlist, message any applicant, decline politely with a one-tap template.
6. Confirmation creates an events_internal record with primary_vj_id set; remaining applicants get a courtesy decline.

Direct booking flow

1. Visitor on a VJ profile clicks Request booking → modal: target date, venue (autocomplete from Spaces + freeform), event description, budget offer, message, expected response window.
2. Request lands in the VJ's inbox; status pending.
3. VJ can: accept (confirms event), counter (proposes adjusted rate / date), decline (with optional template), or refer (forward to another collective VJ if unavailable — strengthens the collective's reliability story).
4. Confirmation creates events_internal and locks the date in the VJ's calendar.

Trust signals on listings

• "Verified venue" / "Verified artist" badges when listing is posted from a confirmed-identity profile.
• Past-booking count + average rating on the lister card.
• Response-rate metric — does this venue actually book, or just window-shop?

Collective broker mode v1.5

A venue or artist posts a gig with target=collective instead of choosing a specific VJ. The collective coordinator (or an automated rotation) routes it to the best-fit available VJ. Reduces the search burden on first-time clients.

Grant Spec'ing & Fundraising Post-MVP / v2.0

Non-profit events — community shows, accessibility-focused performances, educational outreach, benefits — should be able to pursue grant funding and sponsorship without leaving GPortal. Dovetails with Gooism's potential 501(c)(3) status (proposed; pending collective + legal review — see Proposed Org Structure) and the explicit accessibility-for-visual-art mission.

Why this lives in GPortal

VJs and event planners regularly want to fund community-focused work but lack the legal vehicle, the grant-database knowledge, and the time to draft applications. Embedding the workflow next to event planning means a single thread — "this is the event, this is the budget, here are the grants that match, here's the draft application" — instead of three disconnected tools.

Module surface

Trust & legal

• GPortal does not disburse funds or hold money. It's a workflow layer. All grants flow to the applicant entity (the eventual Gooism non-profit entity if approved / fiscal-sponsored event / individual). Specific entity structure pending Proposed Org Structure review.
• Application drafts are private to the event team. Nothing publishes without explicit submit.
• AI-assisted drafts are clearly marked. Final submission requires human review.
• Past-success data is anonymized / opt-in.

AI Assistant (Claude-powered)

Modeled on the gifting app's existing "opus generate" pattern. One Claude-API surface inside GPortal, surfaced contextually wherever drafting, personalizing, or triaging is the bottleneck. Every AI-touched output is logged with ai_assisted=true for transparency, and the user always reviews + edits before anything sends.

Surfaces (in priority order)

1. Targeted outreach drafts (§10) — primary use case. Personalized draft + 2 alternates ("warmer" / "tighter") + tone-confidence note.
2. Booking-request response suggestions (§11) — 3 reply drafts: accept-with-confirm, counter-offer, polite decline. Pre-filled with calendar conflicts, rate-overlap analysis, referral suggestions.
3. Profile bio assistance — "Describe my style based on my portfolio + recent events" generates a 60–120 word bio. Same for tech-rider summaries on Artist profiles + space-description blurbs on Venue profiles.
4. Gig listing description (§11) — draft a compelling listing from the structured fields. Reduces the blank-page intimidation that kills posting rates.
5. Inbox triage — summarize the VJ's unread messages: "3 booking requests, 1 needs a reply by Thursday, 1 likely a tire-kicker based on budget mismatch."
6. Grant application drafts (§12) — same Claude pipeline; letter of intent / project narrative / budget narrative / outcomes framework, all pre-populated from event metadata + collective boilerplate.
7. Lookup-result enrichment — AI summarizes "what to know in 30 seconds" from the Lookup module's findings.

Implementation pattern

• Cloudflare Pages Function endpoint /api/ai/generate accepts { surface, payload, model, max_tokens }.
• Anthropic SDK (@anthropic-ai/sdk) with claude-opus-4-7 for high-stakes drafts (outreach, grants, bios) and claude-sonnet-4-6 for shorter / faster surfaces.
• Server-side prompt assembly — no API key in client. Per-surface prompts versioned in src/lib/prompts/<surface>.ts.
• Prompt caching enabled on the system prompt + collective boilerplate — the surface-specific user message is the only uncached portion. Cuts cost ~85% on repeated invocations.
• Streaming responses so the VJ sees the draft fill in word-by-word.
• Cost tracking + rate limits per VJ. Cap at e.g. 50 generations/day for free tier; collective members hit higher caps.

Trust + transparency

Privacy guardrails

• No personally-identifiable target details are sent to Claude beyond what's already public (artist name, public bio, public socials). The Lookup cache is the source of truth for what's safe to include in a prompt.
• VJ profile data (used to personalize outreach in their voice) is opt-in to AI inputs — defaults to off.
• Outreach logs are local to the VJ; never sent to the AI for new-target drafts (prevents cross-contamination).

Roadmap

Four tiers, additive. v0.1 is the spec doc + skeleton. Each tier is shippable on its own; we don't gate on the next one.

Tech stack & infra

Reuse over rebuild. The app sits on Cloudflare's stack (already provisioned for wallspace.studio); auth carries over via cross-subdomain cookies; UI primitives port from the gifting app; the node editor is the one new dependency.

Repo layout

Open questions

Decisions GPortal can't make alone. These should land at office hours so the schema + UX commit cleanly.

1. Membership model. Invite-only? Application-based? Open with verification? How does someone become a Gooism VJ vs. a non-collective participant in the directory?
2. Ratings gating. Confirmed-event-only, or freer? Anonymous, or attributed? How are disputes handled?
3. Pay-range visibility. Are rate ranges shown publicly, only to authenticated members, or only after a match-request handshake? Trade-off: transparency vs. anchoring / lowballing dynamics.
4. Pricing recommendations. Should GPortal opine on rates (collective median, tier suggestions) or just show comparables? Tied to whether the platform takes any normative stance on fair pay.
5. Cost-split defaults (rider/services). Published collective standard, or per-event?
6. Hiring fees / collective take-rate. Does GPortal charge for confirmed bookings (small flat fee, % of fee, subscription)? Different rates for custom bookings vs. package purchases? Implications for whichever org structure the collective approves (see Proposed Org Structure) and the relationship to commercial WallSpace.
7. Package economics & quality control. Are packages curated by collective admins (vetted before going live), or self-serve with abuse mitigation? Refund / dispute policy when a package's promised scope doesn't match delivery? Insurance / liability for hardware-heavy packages (CRT clusters, custom mounts)?
8. Outreach etiquette enforcement. Are cooldowns and max-pitches-per-event hard limits or just visible friction? Who arbitrates disputes ("X poached my pitch")?
9. Collective broker mode coverage. Who acts as the broker (rotation, volunteer, automated)? What's the SLA on routing a gig to the right VJ?
10. Outreach data privacy. Is the outreach log fully private to the VJ, or visible to collective admins for safety / dispute review? Privacy vs. accountability.
11. Grants & fundraising governance. What's the relationship between any future Gooism non-profit entity (pending Proposed Org Structure review), per-event fiscal sponsorship, and individual applicant grants? Who curates the grant directory? Does the collective take any cut of awarded grants for platform sustainability, or does 100% pass through?
12. AI-assisted application drafts. On-demand opt-in, or always-available? Disclosure language to funders that AI assisted a draft? (Some funders explicitly prohibit AI-generated narratives.)
13. Data ownership when someone leaves the collective. Their profile data, their outreach log, their event history.