Why ferogram?

So before we start talking about why ferogram, let’s first understand what it actually is.

If you landed here directly; ferogram is a fully async Telegram MTProto library written purely in Rust. It lets you access both bot and user accounts directly through MTProto, unlike the traditional HTTP Bot API.

Why ferogram?

I used MTProto libraries in Python and Golang for a long time, and honestly for most normal use cases they were already good enough. But as my requirements grew, I constantly had to build workarounds around them.

At first, I just forked libraries and modified them for my own needs. It worked... until it didn’t.

One big problem was that I never fully understood the internals deeply. Whenever I needed to change something, I had to jump through lots of code, search around, and slowly understand how things worked. It felt like working inside a sealed box.

Another issue was maintenance. Even if I added features or fixes, maintainers obviously couldn’t merge everything or move as fast as my own requirements. So I kept carrying custom patches and modifications on my side.

Then came the worst part.

Whenever upstream released fixes or updates, syncing those changes into my modified versions became painful. The more I customized things, the harder it became to keep everything updated cleanly. After a while, it turned into a long-term mess.

At some point I realized: instead of endlessly patching other libraries, why not just build one myself?

That way I could fully understand the architecture, know exactly where things are implemented, and quickly change or fix things whenever needed.

Cross-language support was also another reason. I still needed strong Python support, and while exploring Rust MTProto libraries I noticed many important internals were private or difficult to expose cleanly for bindings.

That’s basically what pushed me to create ferogram.

Creating “another MTProto library” was never really the goal.

ferogram mostly came from years of modifications, patches, experiments, frustrations, and learning while working with other libraries. A lot of ideas and implementations were inspired by libraries I previously used and learned from along the way.

Why Rust?

Mainly because I needed something easier to integrate into APKs and native environments, and I was already comfortable with Rust.

And honestly.. Rust feels amazing for systems like MTProto clients.

Telegram clients constantly deal with encryption, networking, reconnects, update syncing, media streaming, concurrency, and long-running connections. Rust handles these workloads extremely well while still keeping things safe and efficient.

The performance, memory safety, and control Rust gives are honestly hard to ignore once you start building systems like this.

Open-source project

Initially, I never planned to make ferogram public. I thought it would stay as my own personal project.

But once the project became bigger, bugs from edge cases and usage started showing up everywhere. At some point I realized making it open source would actually help a lot through community feedback and bug reports.

And thankfully, it really did.

Even though there haven’t been many direct code contributions yet, people still helped a lot by reporting bugs, testing things, and sharing feedback from different environments and use cases.

Some features inside ferogram actually exist because of community requests and discussions.. MTProxy support is one example.

So even without massive contributions yet, the community already played a huge role in shaping the project, and I’m genuinely thankful for that support.