Blasp Laravel Package

Technical Evaluation

Architecture Fit

• Modular Design: The driver-based architecture (regex, pattern, phonetic, pipeline) aligns well with Laravel’s composable ecosystem. The package abstracts complexity behind a fluent API, making it easy to integrate without deep PHP regex knowledge.
• Extensibility: Custom drivers can be added via DriverInterface, enabling domain-specific adaptations (e.g., industry jargon, niche slang).
• Severity Scoring: The tiered severity system (mild/high/extreme) provides granular control, useful for platforms with varying moderation needs (e.g., forums vs. family-friendly apps).
• Multi-Language Support: Pre-bundled dictionaries for English, Spanish, German, and French reduce localization effort, though custom dictionaries would require additional setup.

Integration Feasibility

• Laravel Native: Leverages Laravel’s service container, events, middleware, and validation systems seamlessly. No framework-specific hacks required.
• Eloquent Integration: The Blaspable trait reduces boilerplate for model-level filtering, though it assumes models are saved via create()/update() (not raw queries).
• Middleware & Validation: Tight integration with Laravel’s request pipeline and validation rules minimizes refactoring for existing apps.
• Blade Directives: The @clean directive simplifies view-layer sanitization, but requires template updates.

Technical Risk

• Performance Overhead:
  • Regex driver is computationally expensive for high-throughput systems (e.g., real-time chat). Pipeline mode compounds this.
  • Phonetic driver relies on metaphone() + Levenshtein, which may slow down bulk operations.
  • Mitigation: Cache results (config/blasp.cache.enabled = true) or use the lighter pattern driver for low-severity checks.
• False Positives/Negatives:
  • Phonetic driver’s sensitivity (max_distance_ratio) may flag innocuous words (e.g., "fork" → "fuck"). Custom false_positives lists help but require maintenance.
  • Regex driver’s separator limit (3 chars) might miss creative obfuscation (e.g., f-u-u-u-c-k).
  • Mitigation: Test with edge cases; adjust config/blasp.drivers.phonetic.false_positives.
• Backward Compatibility:
  • Breaking changes in v4 (e.g., driver architecture rewrite) could require updates if migrating from older versions.
  • Mitigation: Review changelog for v4 → v5 transitions if adopting later.
• Dependency Bloat:
  • Adds ~50KB to vendor space. Justify based on feature usage (e.g., disable phonetic driver if unused).

Key Questions

1. Use Case Alignment:
   • Is profanity filtering a core requirement (e.g., social platform) or nice-to-have (e.g., internal tool)? Prioritize features accordingly (e.g., skip phonetic driver for low-risk apps).
   • Do you need real-time filtering (e.g., live comments) or batch processing (e.g., user-generated content imports)? Adjust driver selection and caching.
2. Language Scope:
   • Are you supporting only English, or multiple languages? Publishing language files (php artisan vendor:publish --tag="blasp-languages") adds complexity.
3. Moderation Strategy:
   • Should profanity be masked, rejected, or logged? The package supports all but may need custom event handlers for logging.
4. Performance Budget:
   • Benchmark with your expected workload. Test the pattern driver first for baseline performance.
5. Customization Needs:
   • Will you extend with custom drivers or dictionaries? Plan for maintenance of these assets.
6. Compliance:
   • Does your use case require audit logs of filtered content? The package lacks built-in logging; events would need to be extended.

Integration Approach

Stack Fit

• Laravel 8.0+: Native integration with service container, events, and validation. No polyfills needed.
• PHP 8.2+: Leverages named arguments, enums (Severity), and attributes (e.g., for custom drivers).
• Database: Eloquent integration assumes relational models. For NoSQL, use middleware/validation rules instead.
• Frontend: Works with any frontend (Blade, Inertia, API responses). Masking strategies (e.g., grawlix) may need UI adjustments.

Migration Path

1. Discovery Phase:
   • Install in a staging environment: composer require blaspsoft/blasp.
   • Publish config: php artisan vendor:publish --tag="blasp".
   • Test with sample data to validate false positives/negatives.
2. Pilot Integration:
   • Start with validation rules (low risk) in a single controller (e.g., CommentController).
   • Example:

     use Blaspsoft\Blasp\Rules\Profanity;
     $request->validate(['body' => ['required', Profanity::in('english')->minSeverity('high')]]);
     

   • Gradually add middleware (blasp:sanitize) to high-risk routes.
3. Model Integration:
   • Apply Blaspable trait to critical models (e.g., Post, UserBio).
   • Configure blaspable attributes and mode (sanitize/reject).
   • Test edge cases (e.g., nested attributes, mass assignment).
4. Full Rollout:
   • Enable middleware globally for all text inputs.
   • Update Blade templates to use @clean directive.
   • Configure caching (blasp.cache.enabled = true) for production.

Compatibility

• Existing Profanity Filters:
  • Replace custom regex filters with Blasp::check() for consistency.
  • For hybrid approaches, use the allow/block lists in config to merge with existing rules.
• Third-Party Packages:
  • Conflicts unlikely, but test with packages using Str macros (e.g., Str::isProfane may shadow other macros).
• Legacy Code:
  • Wrap existing sanitization logic in a service class to isolate changes.

Sequencing

Operational Impact

Maintenance

• Configuration Drift:
  • Centralized config (blasp.php) reduces maintenance but requires coordination across teams.
  • Best Practice: Document config overrides per environment (e.g., severity set to high in production).
• Language Updates:
  • New languages require publishing updates (php artisan vendor:publish --tag="blasp-languages").
  • Best Practice: Monitor Blaspsoft/blasp for new language releases.
• Driver Tuning:
  • Phonetic driver’s false_positives list may need updates as slang evolves.
  • Best Practice: Log false positives to a database and review quarterly.

Support

• Debugging:
  • Use Blasp::fake() in tests to simulate profanity detection.
  • Log ProfanityDetected events for auditing:

    Event::listen(ProfanityDetected::class, function ($event) {
        \Log::debug('Profanity detected', $event->result->toArray());
    });
    

• User Communication:
  • For reject mode, provide clear error messages (e.g., "Your comment contains prohibited language").
  • Example middleware response:

    return response()->json([
        'message' => 'Profanity detected in field: ' . $attribute,
        'details' => $result->uniqueWords(),
    ], 422);
    

• Edge Cases:
  • Handle multilingual text (e.g., Spanish/English mix) by checking all languages:

    Blasp::inAllLanguages()->check($text);
    

Scaling

• Performance Bottlenecks:
  • Regex Driver: High CPU usage under load. Mitigate with:
    • Caching (blasp.cache.results = true).
    • Switching to pattern driver for low-severity checks.