Ditto Web Chat – Milestone 2 Completion

[yuvaraj-quest1]

Ditto Web Chat – Milestone 2 Completion

This PR completes Milestone 2 of the Ditto Web Chat project.
 It includes comprehensive unit test coverage, subscription management, notification system, reaction support, user mentions, dark theme implementation, profile picture rendering, security improvements and CI/CD pipelines.

---

Features Delivered

1. Unit Test Cases – Comprehensive test coverage (~90%+) for both DittoChatCore and DittoChatUI SDKs.
2. Subscription Rooms – Full implementation of room subscription/unsubscription functionality.
3. Notifications and Badges – Real-time notification system with unread message badges and mention badges across subscribed rooms and DMs.
4. Reaction Emojis – Complete reaction picker feature allowing users to add, remove, and display emoji reactions on messages.
5. User Mentions – Comprehensive mention functionality with autocomplete support for tagging users in messages.
6. Dark Theme – Complete dark mode implementation with automatic system theme detection and theme-switching capabilities.
7. Profile Pictures – Full profile picture rendering support across chat lists, DMs, and user mentions with thumbnail optimization.
8. Message Retention – Retention days logic implementation for automatic message cleanup.
9. Security & Compliance – OWASP dependency validation, security vulnerability fixes (glob package), and automated security scanning.
10. CI/CD Pipelines – GitHub Actions workflows for automated test case execution and OWASP security checks.

---

Issues Resolved

• #79 Implement Chat Retention Days (Web)
• #78 Profile image Spec
• #74 Allow user reactions
• #72 Mentions
• #71 Subscribe to rooms

[aaronleopold]

@ErikEverson potential integration in the future?

[ErikEverson]

Yeah

[aaronleopold]

I'd like input from @ErikEverson I think. Offhand I don't think a bunch of booleans is more scalable than a list of permissions, but I don't have a good grasp of our needs in this respect

[ErikEverson]

Yeah actually the most scaleable way we could do this is to have an enum of permissions and then an array of permissions could be used. This means that we get enum safety when we add a new permission and we also get the convenience of not having to add a new boolean and update every place in the code that it is used as well.

[aaronleopold]

@ErikEverson This probably needs to align with our colors, right? At least eventually

[ErikEverson]

Yes we will want this to align with the color stuff from forge as it is a really robust system. I think this is something to refactor when we get the color system finalized in Forge.

[aaronleopold]

Is there a reason we didn't go for an off the shelf solution for toasts like https://github.com/emilkowalski/sonner?

[rohit-quest1]

We considered using an off-the-shelf toast library like Sonner, but for this project we wanted to minimize external dependencies and keep the UI layer purely Tailwind-driven. Since our toast requirements were fairly simple, we opted to implement a lightweight custom Toast component instead.

[aaronleopold]

I think it would be more maintainable long term to not re-invent things where possible. The unpacked size of something like sonner is pretty negligible for modern web applications (166kb for sonner specifically) and I'd argue that a headless UI component not only satisfies your desire to keep the UI layer purely Tailwind-driven but is more ideal since you still get complete control over styling and animations while the library handles the complex orchestration details as our needs grow (promises, ARIA, more queue management, etc).

[yuvaraj-quest1]

Added the sonner package and removed our custom toaster implementation.

We also introduced a new option that allows consumers to pass their own custom notification function through props. This gives integrators full control—if they want to handle notifications in their own way, they can simply provide a function that receives the notification details and display it however they prefer in the parent app.

If no custom function is provided, we fall back to using sonner by default to show notifications.

[github-actions]

🟢 Test Coverage Report - sdks/js/DittoChatCore

Overall Coverage: 92.42%

Metric	Coverage	Status
🟢 Lines	93.78%	green
🟢 Statements	93.78%	green
🟢 Functions	95.83%	green
🟢 Branches	86.31%	green

---

📊 View Detailed Coverage Report

ℹ️ Coverage Thresholds

• 🟢 Excellent (≥ 80%)
• 🟡 Good (60-79%)
• 🟠 Fair (40-59%)
• 🔴 Poor (< 40%)

[github-actions]

🟢 Test Coverage Report - sdks/js/DittoChatUI

Overall Coverage: 91.11%

Metric	Coverage	Status
🟢 Lines	92.53%	green
🟢 Statements	92.53%	green
🟢 Functions	90.56%	green
🟢 Branches	88.8%	green

---

📊 View Detailed Coverage Report

ℹ️ Coverage Thresholds

• 🟢 Excellent (≥ 80%)
• 🟡 Good (60-79%)
• 🟠 Fair (40-59%)
• 🔴 Poor (< 40%)

[github-actions]

⚠️ OWASP Dependency Check - sdks/js/DittoChatUI

Medium severity vulnerabilities detected

Severity	Count
🔴 Critical	0
🟠 High	0
🟡 Medium	1
🔵 Low	0
Total	1

📋 Vulnerability Details

• CVE-2025-64718 (MEDIUM) in js-yaml:3.14.2
  • Description: js-yaml is a JavaScript YAML parser and dumper. In js-yaml 4.1.0 and below, it's possible for an attacker to modify the prototype of the result of a parsed yaml document via prototype pollution ( proto ). All users who parse untrusted yaml documents may be impacted. The problem is patched in js-yaml 4.1.1. Users can protect against this kind of attack on the server by using node --disable-proto=delete or deno (in Deno, pollution protection is on by default).
  • CVSS: 5.3

---

📊 View Full HTML Report

ℹ️ How to fix vulnerabilities

1. Update vulnerable dependencies to patched versions
2. Run npm audit fix or npm audit fix --force
3. Check for alternative packages if updates aren't available
4. Review and update your package.json and package-lock.json

[github-actions]

⚠️ OWASP Dependency Check - sdks/js/DittoChatCore

Medium severity vulnerabilities detected

Severity	Count
🔴 Critical	0
🟠 High	0
🟡 Medium	1
🔵 Low	0
Total	1

📋 Vulnerability Details

• CVE-2025-64718 (MEDIUM) in js-yaml:3.14.2
  • Description: js-yaml is a JavaScript YAML parser and dumper. In js-yaml 4.1.0 and below, it's possible for an attacker to modify the prototype of the result of a parsed yaml document via prototype pollution ( proto ). All users who parse untrusted yaml documents may be impacted. The problem is patched in js-yaml 4.1.1. Users can protect against this kind of attack on the server by using node --disable-proto=delete or deno (in Deno, pollution protection is on by default).
  • CVSS: 5.3

---

📊 View Full HTML Report

ℹ️ How to fix vulnerabilities

1. Update vulnerable dependencies to patched versions
2. Run npm audit fix or npm audit fix --force
3. Check for alternative packages if updates aren't available
4. Review and update your package.json and package-lock.json

[ErikEverson]

One thing to think about with RBAC

[ErikEverson]

Yeah actually the most scaleable way we could do this is to have an enum of permissions and then an array of permissions could be used. This means that we get enum safety when we add a new permission and we also get the convenience of not having to add a new boolean and update every place in the code that it is used as well.

[ErikEverson]

Yes we will want this to align with the color stuff from forge as it is a really robust system. I think this is something to refactor when we get the color system finalized in Forge.