TelechatSharp

Last week, I open-sourced TelechatSharp.

Before making the project public, TelechatSharp—or a much less polished version of it—had been the backbone of a number of personal, Telegram-adjacent side projects. I developed the earliest pieces of what would eventually become TelechatSharp around mid-2020—just a small set of unorganized DTOs backing my Telegram bots, messaging automation tools, and data visualizers. At the time, I was less than a year into my first programming job out of school and started the projects as a way to familiarize myself with C#, the language I used (and still use) at work.

The library itself isn’t overly complex—publishing it was just a nice way to wrap together some code I’d used in multiple projects and throw a little NuGet-shaped bow on it.

Today, many of my projects are still written in C#—whether it’s a small Windows utility or an API in the backend of a web app—but for anything involving large amounts of data, I’m more likely to reach for Python and pandas nowadays instead of building something like TelechatSharp. The library itself isn’t overly complex—publishing it was just a nice way to wrap together some code I’d used in multiple projects and throw a little NuGet-shaped bow on it. Beyond an exercise in cleaning up my own code, it’s also been a great introduction to open-source software (OSS) as a contributor.

The earliest I remember being introduced to the concept of OSS was back in 2010. I was fourteen and following links to public GitHub repos for open-source iPhone jailbreak tweaks. I remember swiping through Cydia and the early work of Ryan Petrich, a developer who released some of the iOS jailbreak community’s most popular tweaks, not knowing anything about Objective-C (or programming in general). At the time, I was more interested in getting the tweaks working on my phone than learning how they were programmed, so it would be seven more years before I wrote my first “Hello, World!”

I’ve benefited extensively from OSS over the years—likely before I even knew what OSS was. In fact, as a developer working mainly with .NET, most of the code I write to earn a paycheque is built from an open-source platform. Using and modifying existing libraries is one thing. Developing my own, in a way that strives (on some level) to adhere to standards set by other well-designed libraries, is another.

While a large part of what makes open source so great is its collaborative aspect, I primarily wanted to use TelechatSharp as a personal challenge. A couple weeks ago, when I first started entertaining thoughts of making the library public, I realized that committing to the idea would force me to address things I didn’t feel the need to prioritize in a personal, no-one’s-ever-going-to-see-this-code-type project. Let’s mark this as internal so someone else doesn’t use it incorrectly…Let’s leave a descriptive error message here in case the data’s invalid…

Many of these small changes were easy enough to identify and address because they were principles I followed when writing code for my day job. But for a side project I originally had no intention of making public? Getting something working in as few lines as possible eclipsed the need for clean code.

The deeper I got into refactoring, however, the more questions began to pop up. Unlike at work, where I wrote code for customer-facing software, this time I was writing code for people who wrote code. That brought with it a whole set of new things to consider:

Should all my public properties have nullable reference types or be non-nullable and return default values?

What would a caller most likely expect to get back here: an empty collection or null?

Should I make these methods extension methods or just instance methods of my custom type?

Searching for anything that resembled a consensus on these topics led me to the Framework Design Guidelines, from which I did end up adopting a few suggested practices. I also poked around other open-source libraries like NumSharp and stripe-dotnet to study their architecture and learn from more knowledgeable developers.

My most recent Telegram-related side project, Telegram Wrapped, makes use of TelechatSharp behind the scenes. Back in December, I put together a Spotify Wrapped-type year-end summary for my close friends and family. But instead of music data, everyone received personalized analytics based on our group chat history over the last five years:

Telegram Wrapped presented everyone with a personalized web page containing chat analytics data from a five-year period in our group chat history—analytics like what time someone was most likely to send a message or their top five most-used words.

A full write-up on my Telegram Wrapped project—where I’ll talk more about the data and overall development process—is currently in the works. For now, you can visit TelechatSharp on GitHub to learn more about the library and view its full source code.