SchildiChat: Read Receipts & Typing Notifs

SchildiChat: Read Receipts & Typing Notifs Not Working When Presence is Disabled

Ever noticed your SchildiChat read receipts and typing notifications sometimes go missing? You're not alone! Many users have encountered this peculiar issue where, when presence is disabled, the client seems to stop rendering these helpful indicators. This can be quite frustrating, as these features are pretty standard in most chat applications. The good news is, there's a clear path to fixing this: ensuring that read receipts and typing notifications always render, regardless of your presence settings. This approach is already implemented in major clients like FluffyChat and Shamrock, demonstrating its effectiveness and user-friendliness. It's a bit of a bummer that this 'antifeature' – preventing users from seeing data within their own client – was inherited from Element X, but thankfully, this project is actively working to improve the user experience!

Understanding Presence and Its Impact on Read Receipts

Let's dive a little deeper into why SchildiChat read receipts and typing indicators can disappear. In many chat protocols, like Matrix (which SchildiChat uses), 'presence' refers to your online status – whether you're online, offline, away, or busy. This information is shared with your contacts. However, some users prefer to disable presence sharing for privacy reasons. The issue arises because, in some client implementations, the rendering of read receipts and typing notifications is tied to the presence system. If presence is disabled, the client incorrectly assumes there's no need to display these notifications either. This is where the problem lies. The core idea behind fixing this is to decouple the rendering of read receipts and typing indicators from the presence status. In simpler terms, your client should always show you if a message has been read or if someone is typing, irrespective of whether you're broadcasting your online status to others. Think about it: you're looking at your own chat window. You should have access to all the information your client can provide about the conversation, including delivery and read statuses. It's not about what others see of you, but about the data you receive and you can see. This makes for a much more transparent and functional chat experience. Major clients like FluffyChat and Shamrock have already adopted this approach, showing that it's not only feasible but also a more intuitive way to handle these features. By making read receipts and typing notifications always visible, SchildiChat can significantly enhance its usability and align with user expectations for modern messaging applications. It’s a crucial step towards a more robust and user-centric design.

Why Always Rendering is the Better User Experience

Implementing always-on read receipts and typing notifications is not just a technical fix; it's a fundamental improvement in user experience that aligns with the core purpose of a chat application. When you're engaged in a conversation, you want to know the status of your messages and the intent of the other person. Seeing those little checkmarks indicating your message has been delivered and read, or observing the typing indicator appear, provides crucial context. It reduces anxiety about whether your message was received and encourages more natural, fluid communication. When these features are hidden or disappear based on settings like presence, it creates a jarring and unreliable experience. Users might start questioning if their messages are being sent correctly, if the other person is ignoring them, or if the app itself is malfunctioning. This lack of transparency is precisely why the current behavior is considered an 'antifeature' by many. It actively hinders the user from accessing information that is readily available within the application's data stream. The argument for disabling presence is usually privacy – not wanting to broadcast one's online status. However, this should not come at the cost of obscuring information about message delivery and engagement within your own client. The two functions are distinct. Your decision to share your online status with others shouldn't dictate whether you can see when they have read your messages. By ensuring that read receipts and typing indicators are always rendered, SchildiChat empowers users with complete information about their interactions. It makes the app feel more reliable, more informative, and ultimately, more useful. It's about giving users control and visibility over their own communication data. This is a principle that aligns with the open-source ethos and the desire to build truly user-friendly applications. Embracing this always-on approach will undoubtedly lead to greater user satisfaction and a more polished chat experience overall, moving away from the limitations inherited from less user-focused designs.

The Inheritance from Element X and the Path Forward

It's unfortunate, but not uncommon, for projects to inherit certain design decisions or technical implementations from their predecessors. In the case of SchildiChat, this includes certain behaviors that might not be ideal for all users, such as the issue with SchildiChat read receipts and typing notifications being tied to presence settings. The original implementation in clients like Element X may have had its reasons at the time, perhaps related to performance or a specific design philosophy. However, as the messaging landscape evolves and user expectations change, it becomes clear that such dependencies can become problematic. The fact that this behavior is considered an 'antifeature' highlights a shift in what users expect from modern chat clients. They want transparency, control, and a complete view of their communication. When a feature actively prevents a user from seeing data within their own client, it goes against the fundamental principles of user empowerment and information accessibility. The good news is that SchildiChat, being an actively developed and community-driven project, has the flexibility to address these issues. By acknowledging this inheritance and working towards a solution – namely, having presence-disabled clients always render read receipts and typing notifications – SchildiChat is demonstrating its commitment to user experience. The successful implementation of this by other major clients like FluffyChat and Shamrock serves as a strong precedent. It shows that this is a well-understood problem with proven solutions. The path forward involves a focused effort to decouple these features, ensuring that disabling presence doesn't inadvertently disable valuable communication feedback. This isn't just about fixing a bug; it's about refining the application's core functionality to be more intuitive, reliable, and aligned with what users truly need and expect from a high-quality chat experience. It’s a step towards shedding the limitations of past designs and building a truly user-centric application.

Implementing the Solution: Always Render, Never Hide

So, how exactly do we get to the point where SchildiChat read receipts and typing notifications work flawlessly, even when presence is disabled? The solution is elegantly simple in its principle: the client must always render these indicators. This means modifying the client's logic so that the display of read receipts and typing notifications is not conditional on the user's presence status being enabled or shared. When a message is marked as read by the recipient, or when a recipient starts typing, the server sends this information. The client receives this information. The crucial step is to ensure that the client's UI is designed to always process and display this incoming data, regardless of whether the user has chosen to broadcast their own presence. Think of it like this: even if you've told the app not to tell anyone you're home, you still want to know if the mail has arrived or if the delivery person is at your door. The information is there; the client just needs to be programmed to show it to you. Major clients like FluffyChat and Shamrock have adopted this 'always render' approach, and their success serves as a strong validation for this method. They've recognized that hiding this information creates a less functional and more confusing experience. For SchildiChat, this involves a code change that prioritizes the display of these message status indicators. It's about building a more robust and transparent communication interface. Instead of relying on a complex interplay between presence settings and notification rendering, the logic becomes straightforward: if the data is available, display it. This approach not only resolves the immediate issue but also future-proofs the feature against potential complications arising from other presence-related changes. Ultimately, the goal is to create a chat client that is predictable, informative, and puts the user's ability to understand their conversations first. This commitment to always rendering these key indicators is a significant step towards achieving that goal.

Conclusion: Enhancing Privacy Without Sacrificing Functionality

The issue with SchildiChat read receipts and typing notifications when presence is disabled highlights a common challenge in software development: balancing user privacy with essential functionality. While disabling presence is a valid privacy choice, it shouldn't come at the expense of basic communication feedback within the user's own client. The solution – always rendering read receipts and typing notifications – is a testament to building more user-centric applications. By decoupling these features from presence settings, SchildiChat can offer a more transparent, reliable, and intuitive experience. This approach, already proven effective by leading clients like FluffyChat and Shamrock, ensures that users have full visibility into their conversations, regardless of their privacy preferences. It’s about empowering users with information without forcing them to compromise on their desired level of privacy. This is the kind of thoughtful design that elevates a good chat application into a great one. We can learn more about privacy in messaging at the Electronic Frontier Foundation and about the Matrix protocol at Matrix.org.