SLChat Technical Overview

Originally, SLChat relied on a single WebSocket connection, which was primarily responsible for handling chat messages.

While sufficient at the time, this design had several limitations:

• The socket was focused on message delivery only.
• Updates such as server membership changes were not propagated in real time.
• Multiple tabs could become desynchronized, each maintaining its own outdated list of servers and DMs.

As a result, information and updates were not consistently synchronized across sessions.

To address these issues, on 27/11/2025, SLChat switched to a dual socket architecture.

Under this model:

• The user socket is responsible for user and account data, such as servers and direct messages.
• the chat socket is responsible for chat data, such as message delivery and presence updates.

This transition introduced several additional improvements:

• Enabled the implementation of the pseudo-SPA Architecture.
• Real-time synchronization of server and DM updates across all open tabs.
• Simplified user data delivery, with user data sent immediately upon connection.
• Removal of Jinja-based rendering, as user data is now supplied over the user socket.
• Improved API wrapper design, as client-side state is initialized from socket data rather than templated HTML.

By removing reliance on server rendered pages for data delivery, this change also enables greater flexibility going forward, making it easier to:

• Develop native applications
• Introduce shared or headless clients
• Support alternative frontends using the same backend infrastructure

This lays the groundwork for a more native, cross-platform SLChat ecosystem.

Previously, SLChat relied entirely on server-side rendering using Jinja templates.

While simple to implement at the time, it had several issues:

• Each navigation action generated and returned a fully rendered HTML page.
• Server-side rendering on every navigation increased server load.
• Full page reloads made the interface feel less responsive, impacting user experience.

To address these issues, on 28/11/2025, following the introduction of the dual socket architecture, SLChat switched to a pseudo-SPA (Single Page Application) model, partially. Other pages were soon to follow in the conversion to pseudo-SPA.

Now, instead of re-rendering entire pages for each navigation, the application now sends JSON data while the client handles updates and transitions on each navigation.

This reduces redundant server-side rendering, improves responsiveness, and provides smoother navigation without the overhead of a full SPA.

Initially, SLChat did not support link preview rendering. Links appeared as plain text without any additional context.

To provide richer previews, an external third-party service was used to fetch link metadata.

However, this approach introduced several issues:

• Unreliable information
• Privacy concerns
• Dependence on a third-party service
• Risk of failure which could not be instantly repaired

On 1/12/2025, SLChat switched to its own link preview system, Metafetcher.

Although Metafetcher runs as a separate service, it is fully managed by the same person, ensuring reliability, security, and reduced dependency on external services.

Originally, SLChat allowed messages to be formatted in HTML, providing extensive customization for users.

However, this approach introduced several issues:

• Security risks requiring server-side HTML sanitization
• Difficulty standardizing message content such as attachments
• Increased storage requirements, as HTML blocks are larger than plain text

To address these issues, SLChat deprecated HTML in favor of Markdown on 2/12/2025.

Markdown reduces storage and bandwidth usage while maintaining a level of user-customizable rich content.

Although the flexibility of HTML customization was lost, future improvements with more custom Markdown syntaxes are planned to restore the lost flexibility.

This change simplifies message rendering, standardizes content, and reduces disk space usage.

Previously, all messages of a chat were stored in a single, uncompressed JSON file.

This caused rapid storage growth, even minor spamming could consume significant disk space.

At one point, SLChat had only 15% available storage remaining.

On 26/11/2025, SLChat implemented a new storage system, splitting messages into multiple compressed files.

This change drastically reduced disk space usage.

For example, a set of messages that previously occupied 1 MB now requires approximately 0.05 MB.

Some data was however, lost during migration, but overall disk space usage was greatly reduced as a result.

Before the storage optimization on 26/11/2025, SLChat included an automated system to detect high-storage abuse.

Servers exceeding 1 MB were evaluated to identify spam, and offending accounts and servers were automatically terminated.

After the storage redesign, this automatic termination system was removed, as storage abuse became less impactful.

However, manual inspections were still required to punish offenders, regardless of the impact made.

A replacement is planned for future updates.