Nova Chat Laravel Package

Technical Evaluation

Architecture fit

• The package is a Nova tool, not a general-purpose chat service. It slots into the admin panel's own service-provider + Vue asset pipeline, meaning its blast radius is the Nova UI and its database, not the customer-facing product.
• Fit is therefore narrow but clean: it is only appropriate if the requirement is "lightweight internal chat for Nova operators" (support handoffs, ops coordination, review notes). It is a poor fit for customer support inboxes, multi-tenant messaging, or anything needing a public API, mobile client, or message history export.
• It presumes a broadcast stack (Laravel Echo + a Pusher-protocol driver) and persistent storage for messages. That is two new runtime dependencies for a feature that is typically adjacent to the product rather than core to it.
• Because it lives inside Nova, it inherits Nova's authorization model. Verify that it actually uses Nova gates/policies for channel access rather than merely "is logged into Nova" — that distinction determines whether it is an internal tool or a data-leak vector.
• Release 1.2.0 does not change any of the above. It adds PHP 8 support only — no new capability, no architectural movement. The tool remains a narrow Nova-3-shaped artifact.

Integration feasibility

• Hard prerequisite is unchanged: a valid Nova license and a Nova 3.x codebase. 1.2.0 lifts the PHP ceiling but not the Nova ceiling — it predates Nova 4's Vue 3 rewrite and Nova 5 entirely, so Composer constraint resolution against a current Nova install will still fail on the Nova constraint, not the PHP one.
• What 1.2.0 does buy: a modern-PHP application no longer has to run a parallel PHP 7.4 runtime or accept a pinned, EOL'd PHP minor to host the tool. That removes a genuine blocker for teams on Laravel 9 / PHP 8.0–8.1.
• Confirm precisely which PHP 8 minor is supported. "PHP 8 support" in a four-year-old package usually means 8.0 was tested. PHP 8.1/8.2 deprecations (dynamic properties, ${} interpolation, utf8_encode removal in 8.2) are the likely trip points and are not covered by that claim until proven.
• Feasibility on a current stack remains "fork required," not "install required." Budget as a modernization project, not onboarding.
• Effort sizing (rough, one competent Laravel/Vue engineer):
  • Verify PHP 8.x minor compatibility, constrain, install on Nova 3: 0.25–0.5 day (down from 0.5–1).
  • Port to Nova 4/5 (Vue 3 component rewrite, tool registration, asset build via Vite): 3–6 days (unchanged — 1.2.0 touches no frontend).
  • Replace the assumed Pusher dependency with self-hosted Laravel Reverb: 1–2 days (unchanged).
  • Authorization review, rate limiting, retention policy, tests: 2–3 days (unchanged).
• Total realistic landing cost: ~7–11 engineer-days, versus ~10–15 to build a scoped equivalent directly on Reverb + Livewire with no inherited debt. The package's value remains that of a reference implementation, not a dependency.

Technical risk

• Abandonment risk: high, downgraded slightly from "certain." 1.2.0 is the first release in roughly four years, and its entire scope is a compatibility bump. That is evidence the maintainer is reachable, not evidence of a maintenance cadence. Treat it as a one-off reprieve, not a changed trajectory: still 15 stars, 0 dependents, no committed support, no published security policy.
• Version lock risk: high, and now the dominant risk. The PHP constraint has been relaxed while the Nova constraint has not, which concentrates all remaining upgrade exposure on Nova — the one dependency the vendor ships on a frequent, non-negotiable cadence. Expected value of the release is that it defers risk without reducing it.
• Security surface: medium. Chat introduces stored user-generated content (XSS if rendered without escaping), private-channel authorization, and file/attachment handling if present. Each needs explicit review; none will be reviewed upstream. A PHP-version bump is not a security review, and there is no evidence one occurred.
• Bus factor: 1. Whoever performs the fork owns it permanently. Ensure that is a named person, not "the platform team." 1.2.0 does not change this — and depending on the maintainer is now demonstrably an unreliable strategy rather than merely an untested one.
• Regression risk introduced by the release itself: a compatibility patch on an unmaintained package is a low-scrutiny change. If we do adopt, pin to the exact tag and read the diff rather than trusting the changelog.

Key questions

1. What decision does this chat enable — is it internal ops coordination, or a customer-facing capability being smuggled in through the admin panel?
2. Which Nova and Laravel versions are we actually on today, and is a Nova upgrade on the roadmap within 12 months? (A yes still argues against adopting — 1.2.0 did nothing for Nova 4/5.)
3. New: Does 1.2.0 signal resumed maintenance, or is it a one-off? What is the maintainer's stated intent, and is there any commit activity between the two releases?
4. New: Which PHP 8 minor was actually tested, and does it run clean under our target minor with deprecations promoted to errors?
5. Which broadcast driver does the package assume, and do we already operate Pusher/Ably/Reverb, or does this create a new vendor relationship?
6. Does the tool enforce per-channel authorization, or is access implied by Nova login? What is the tenant boundary?
7. Is there an existing sanctioned channel for this need (Slack/Teams integration, shared inbox) that makes this redundant?
8. Who is the named owner post-fork, and what is the acceptable remediation window if a vulnerability is found?

Integration Approach

Stack fit

• Compatible shape: Laravel 9-era app + Nova 3 + PHP 8.0/8.1 + Echo + Pusher-protocol broadcasting + MySQL/Postgres for message storage. This is materially wider than pre-1.2.0, which forced PHP 7.4.
• Incompatible shape: Nova 4/5, Vite-based Nova assets, PHP 8.2+ until proven, or any environment where adding a websocket vendor is a procurement event.
• If the platform already runs a broadcast driver for other features, marginal infrastructure cost is near zero and fit improves materially. If not, this package is the camel's nose for a whole realtime subsystem — scope that decision separately.

Migration path

• Do not composer require into a live application. Instead:
  1. Install 1.2.0 into a disposable sandbox branch on our current PHP minor to read the migrations, config, and Vue source and to surface deprecations.
  2. Extract the schema, event/broadcast contracts, and channel conventions as a specification.
  3. Either fork-and-upgrade, or reimplement against the extracted spec on current Nova/Vue 3 — decide based on step 1's findings, not in advance.
• Prefer vendoring the fork under a namespaced internal path (app/Nova/Tools/Chat) rather than a private Composer package; it keeps the code visible to the team that must maintain it and avoids implying a versioned contract.
• Record the exact upstream tag (1.2.0) the fork diverged from, so future "is upstream fixed?" questions resolve in seconds rather than a diff archaeology session.

Compatibility

• Produce an explicit support matrix before writing code: Nova version × Laravel version × PHP minor × broadcast driver. Pin Nova and PHP minor in composer.json for the duration of the port.
• Treat "PHP 8 support" as a claim to verify in CI, not a fact. Run the full test suite with E_ALL and deprecations surfaced before accepting the constraint.
• Treat Nova 4+ as a rewrite target, not a compatibility target; the Vue 2→3 transition means the frontend will not be salvaged line-for-line.

Sequencing

1. Discovery spike (0.5–1.5 days, reduced): sandbox install of 1.2.0 on the current PHP minor and Nova version, record exactly what breaks. This is the go/no-go gate. The PHP half of this is now cheaper; the Nova half is not.
2. Maintenance-signal check (hours): read the 1.2.0 diff and commit history. If it is a single squashed compatibility commit with no follow-up, plan for zero upstream forever.
3. Requirement confirmation: confirm the internal-vs-external use case and the authorization boundary; kill the project here if it is really a customer support tool.
4. Broadcast decision: adopt existing driver or stand up Reverb. Do this before UI work so the frontend targets the real transport.
5. Backend port: migrations, models, events, channel authorization, rate limiting, retention job.
6. Frontend port: Nova tool registration + Vue components on the current asset pipeline.
7. Hardening: escaping/XSS review, attachment handling if applicable, load test on channel fan-out, runbook.
8. Ship behind a Nova gate limited to an internal pilot group for two weeks before broad enablement.

Operational Impact

Maintenance

• This is still a permanently forked dependency with, in practice, no upstream. Every Nova major release, every Laravel major release, and every PHP minor EOL becomes a scheduled task for your team.
• 1.2.0 marginally improves the near-term picture — one fewer "we must run EOL PHP to host this" conversation — but does not change the steady-state. Do not let a single release reset the team's expectation that this is unmaintained.
• Realistic ongoing cost: 1–2 engineer-days per Nova major upgrade, plus ~0.5 day/quarter of dependency and security hygiene. Low in absolute terms, but it competes with product work and will lose.
• The 0-dependents signal still matters operationally: there is no ecosystem to observe for breakage. You will discover incompatibilities in production, not in someone else's issue tracker.

Support

• Vendor SLA: none. Upstream response time: undefined and now demonstrably measured in years. Escalation path: internal only.
• Consequence: no end-user support story can reference the package. Every bug report routes to the owning engineer. Set that expectation with stakeholders before launch, not after the first outage.
• Document the fork's divergence from upstream (baseline: 1.2.0) in a short ADR so a future engineer does not waste a day trying to merge an upstream release that may never come.

Scaling

• Realtime fan-out scales with concurrent Nova sessions, which is typically small (tens, not thousands). This is the package's one genuinely favorable property, and 1.2.0 does not disturb it.
• The unbounded axis is message volume in the database. Verify and, if missing, add: pagination on load, an archival/retention job, and an index on (channel_id, created_at). Absent retention, this table grows forever and every thread load degrades.
• Attachments (if supported) shift cost to object storage and bandwidth; confirm they exist before promising file sharing — 1.2.0 added none.

Failure modes

• Silent breakage on Nova upgrade — still the primary mode. Mitigate with a smoke test in CI that boots Nova and asserts the tool registers.
• PHP minor drift — newly relevant. A package that "supports PHP 8" may emit deprecations or fatal on 8.1/8.2 as the runtime advances. Add a CI job that runs the suite on the next PHP minor before we upgrade it, not after.
• Websocket unavailable — messages appear unsent or the UI stalls with no fallback. Users will assume the tool is broken and abandon it; require a visible connection-state indicator or explicit "retry" affordance.
• Queue worker down — broadcast events queue and never dispatch; messages persist in the DB but appear lost in realtime. Alert on queue lag.
• Channel authorization misconfiguration — the highest-severity mode: cross-team message visibility. Test negative cases explicitly (user A cannot subscribe to channel B).
• Stored XSS via message body — verify escaping in the Vue render path; treat any v-html as a defect.
• Orphaning — the owning engineer leaves and the fork becomes unmaintained internally, reproducing the exact condition that made the package unadoptable. Mitigate with a named secondary owner at handoff.

Ramp-up

• Codebase is small (a tool, a handful of Vue components, a migration set) — a Laravel/Vue engineer can read it fully in under a day. 1.2.0 adds no surface area.
• The real ramp-up cost is not the code but the decision context: why a fork exists, what was changed, and what the upgrade trigger is. Capture that in a one-page ADR alongside the code — including why 1.2.0 was judged insufficient to un-fork.
• Onboarding a second engineer is cheap if the frontend is moved to the current Nova asset pipeline (familiar conventions) and expensive if the Vue 2 patterns are left in place.