Laravel Mosparo Laravel Package

Technical Evaluation

Architecture fit

• Laravel-idiomatic throughout: Blade directives (@mosparoScript, @mosparo), an anonymous-style component (<x-mosparo />), a validation rule (new ValidMosparo([...])), a Livewire trait (InteractsWithMosparo), a facade with read-only DTOs (ExeQue\Mosparo\Data), a common exception interface, an artisan command, and a fake(). This matches the framework's own extension points rather than inventing parallel ones.
• Important framing for stakeholders: this package is a client SDK + DX layer, not a spam engine. The actual evaluation work lives in a separate self-hosted mosparo service that we must operate. The architectural decision is therefore as much an infrastructure decision as a library decision.
• Low footprint: no migrations, no persistence layer, no queue workers, no long-running processes. Application side is effectively stateless, which suits containers, autoscaling, and read-only filesystems.
• The token-refresh behaviour ("the box fetches new tokens after every check") is a deliberate anti-replay design — good for correctness, but it means the browser holds conversation state with an external service, which affects CSP, egress, and offline/degraded-network UX.

Integration feasibility

• Hard gate: PHP 8.4+, Laravel 13, Livewire 4 (Livewire only for the Livewire parts). Most production estates today are on older majors. Realistically this package cannot be adopted on existing applications without a framework upgrade programme first. Feasibility on our current estate is close to zero; feasibility on greenfield Laravel 13 work is high.
• Effort once eligible is genuinely small: one head directive per layout, one component or directive per form, one rule per plain-form post, one trait per Livewire component. Order of magnitude ~0.5–2 dev-days for a pilot form, plus infra time to stand up and secure the mosparo server.
• The MOSPARO_ENABLED flag and Mosparo::fake() mean code can ship ahead of infrastructure and ahead of a signed-off rollout — a useful de-risking lever.

Technical risk

• Pre-1.0. v0.1.0 carries no API-stability promise. Expect breaking changes on 0.x minor bumps. Pin the exact version and treat every upgrade as a code change requiring review.
• Vendor concentration. A first release from a single agency/maintainer, with no stated LTS, security-disclosure policy, or release cadence. Bus-factor risk is real. Mitigations: confirm a permissive licence, confirm the source is forkable, and isolate calls behind a thin internal interface so replacement is a contained change.
• Bleeding-edge stacking. PHP 8.4 + Laravel 13 + Livewire 4 + a 0.x dependency compounds currency risk; a failure in any layer can look like a failure in this one.
• Fail-mode ambiguity is the top risk. Every submission makes an outbound HTTP call; on ConnectionFailed / RequestFailed the behaviour (accept the submission = spam gets through, or reject = legitimate users blocked) is a product decision, not a library detail. It must be explicit, documented, and tested — not inherited from a default.
• Field-list drift. Verification names the fields mosparo must have checked, which correctly prevents partial-check bypass — but the inverse is that a newly added form field omitted from the list is silently unprotected. Correctness depends on developer discipline with no compile-time guard.
• Unknowns: CSP nonce support for the injected script, accessibility of the mosparo box, SPA/Inertia support (notes cover Blade and Livewire only), and the supported mosparo server version matrix.

Key questions

1. What is the default behaviour on ConnectionFailed/RequestFailed — fail-open or fail-closed — and is it configurable?
2. What are the HTTP timeout, retry, and circuit-breaker defaults, and can they be tuned per project?
3. What licence, security-disclosure process, and post-1.0 support commitment exist? Expected cadence to 1.0?
4. Is support for Laravel 11/12, PHP 8.2/8.3, or Livewire 3 planned, or is this permanently latest-only?
5. Which mosparo server versions/APIs are supported, and what is the client's compatibility policy on server upgrades?
6. Does @mosparoScript support CSP nonces/hashes for strict-CSP applications?
7. Is the mosparo box accessible (keyboard, screen reader), and what is the fallback for no-JS clients?
8. Is there a first-class path for Inertia/React/Vue front ends, or is that out of scope?
9. What cache stores are exercised (flushCache()/mosparo:clear-cache scoping), and how are keys namespaced across multiple projects and tenants?
10. Does statistics() surface or transmit anything that affects our privacy position?

Integration Approach

Stack fit

• Fits cleanly where the application is Laravel + Blade (+ Livewire) on the required versions. Blade-directive-per-form and validation-rule-per-post are the lowest-friction patterns available in Laravel; the Livewire trait is idiomatic for component forms.
• Does not fit, on current evidence, a JS-SPA/Inertia front end, where the Livewire trait is irrelevant and only the server-side rule applies — and the rule needs a token that the notes do not describe obtaining outside the Blade/Livewire flows. Treat non-Blade front ends as unsupported until confirmed.
• Strong fit for the privacy-sensitive workstream: self-hosted mosparo means no third-party data transfer, which is a materially easier DPO/legal conversation than reCAPTCHA, hCaptcha, or Turnstile. That, not the DX, is the strategic reason to consider it.

Migration path

• From honeypot/rate-limiting: additive. Keep existing controls; mosparo complements rather than replaces them.
• From reCAPTCHA/hCaptcha/Turnstile: form-by-form replacement, never big-bang. Run the new mechanism on some forms while the old one still guards others, so abuse rates are directly comparable during the bake.
• Coexistence lever: MOSPARO_ENABLED=false lets the integration land and be tested in production code paths before the service is mandatory, and gives a documented kill switch if the mosparo server misbehaves. Ensure that flag is itself monitored — a kill switch left on is silent zero protection.
• No data migration required — no schema, no stored verdicts. Rollback is a code revert plus flag flip.

Compatibility

• Blocking: PHP 8.4+, Laravel 13, Livewire 4. This is an eligibility filter, not a tuning parameter.
• Unverified and worth explicit checks: mosparo server version support; cache driver behaviour across Redis/Memcached/database/file; HTTP client dependencies and proxy/egress configuration; locale coverage (29 European languages implies fallback for non-European locales).
• Multi-project support with named projects is a plus for us: one mosparo instance can back several applications, which reduces the number of services to operate.

Sequencing

1. Infra first: stand up mosparo in non-production with TLS, DNS, egress allowlist, secret storage, health checks, and log/metric shipping.
2. Eligibility check: confirm at least one application is on Laravel 13/PHP 8.4, or accept that this is a greenfield-only evaluation.
3. Pilot one low-risk form (contact or newsletter) — highest abuse visibility, lowest business consequence.
4. Deliberately break it: stop the mosparo service and observe behaviour; decide and document fail-open vs fail-closed before wider rollout.
5. CI integration: wire Mosparo::fake() with accept/reject/sequence cases into the pipeline so spam paths are regression-tested, not assumed.
6. Form-by-form rollout, prioritising the highest-abuse forms; record the required-field list per form alongside the form definition.
7. Version policy: pin exact, review each 0.x release as a change request; revisit for 1.0 adoption once API stability and support commitments are published.

Operational Impact

Maintenance

• Two artifacts to patch, not one: the Composer package and the mosparo server. Server upgrades can break the client if the API moves; that coupling needs an owner and a test environment.
• Pre-1.0 means recurring upgrade work. Budget a standing "assess each release" task rather than a one-off integration cost.
• Per-form field lists become part of the definition of done for any form change. Add it to the code-review checklist — this is the single highest-likelihood source of silent protection loss.
• Low surface otherwise: no schema, nothing to back up but server config, and mosparo:clear-cache is scoped so cache hygiene is safe to automate.

Support

• Documentation site exists, which is a positive maturity signal for a v0.1.0. But support is community/single-vendor; no SLA or commercial escalation is stated. Plan for best-effort GitHub response times.
• Mitigation is architectural, not contractual: keep mosparo calls behind a small internal abstraction so a fork or a swap to a different anti-spam provider is a contained change rather than a form-by-form rewrite.
• Internal support surface is small — one integration pattern, one trait, one rule — so it onboards to the platform team quickly and does not need to be spread across feature teams.

Scaling

• Verification cost is one outbound HTTP call per form submission, on the user-facing critical path. That is a latency budget item: set tight timeouts, fail fast, and confirm the added latency against form-completion targets.
• The mosparo server scales with submission volume, not with user count. A single instance is a single point of failure for every protected form across every project it serves — so centralising projects on one instance improves operability but concentrates blast radius. HA or a documented degradation policy is needed before broad rollout.
• Caching (global/per-project/per-call) reduces load for reads — metadata, rule packages, statistics — but does not reduce verification load. Do not treat it as a scaling answer for the submission path.

Failure modes

• Service unreachable → ConnectionFailed. Behaviour must match the documented policy; test it deliberately, not accidentally in production.
• Slow service → latency spike. Without a short timeout and fail-fast, form submission latency inherits mosparo's worst day.
• Credential/project error → UnknownProject / RequestFailed. Every submission fails at once; needs alerting on the exception rate, not just 500s.
• IncompleteProject. Misconfiguration; ideally surfaced at deploy/boot rather than at a user's first submission.
• Kill switch left on. MOSPARO_ENABLED=false in production produces zero protection with zero visible symptom. Add a config assertion and a monitoring check.
• Silent bypass. A field missing from the verify list lets spam through undetected. Canary against abuse-rate dashboards; alert on a step change in spam volume.
• Stale cache. Misconfigured TTLs serve outdated rule packages; flushCache() and mosparo:clear-cache are the remedies and should be in the runbook.
• Livewire token refetch failure mid-session. The box fetches new tokens after each check, so a mid-session outage degrades subsequent submissions — check the resulting UX rather than only the error path.

Ramp-up

• Developers: low — hours. The directives, rule, and trait are familiar Laravel patterns, and fake() plus MOSPARO_ENABLED=false make local work and tests straightforward.
• Ops: moderate — this is a new internet-reachable service to deploy, monitor, patch, and secure, with a dependency on egress, DNS, and secrets management. This is where the real effort sits, not in the PHP.
• Product/legal: favourable. Self-hosted, no third-party transfer, 29 European languages for the user-facing error message — a straightforward privacy and localisation story.
• Onboarding needs: one short internal page covering the fail-mode policy, the required-field-list convention, local dev via the flag plus fake(), and where the mosparo server lives and how it is alerted on.

Recommendation: treat v0.1.0 as a time-boxed evaluation, not a standard. Gate adoption on (a) an eligible Laravel 13/PHP 8.4 application, (b) an explicit fail-open/fail-closed decision, and (c) a confirmed licence and support posture. Adopt broadly only at 1.0, or earlier if the privacy advantage is decisive and the integration is isolated behind our own interface. Pin the exact version either way.