> I believe they have put the most love into their user interfaces out of all the chat programs I have seen
Absolutely true.
Telegram: Best UI. Signal: Best privacy. WhatsApp: Largest userbase.
It's interesting to think about these three dimensions. I could theoretically pinpoint everything that make Telegram's UI the best, and copy it. I could do the same with Signal's privacy. Both of these are technical problems. There's a process for becoming the best at UI, and there's a process for becoming the best at privacy. I don't know a process for becoming the one with the largest userbase.
Other than the 3 big ones, I recently found Jami [1]
Good UI, though not as good as Telegram. Arguably better privacy than Signal - you don't even need an account if you don't want. Zero userbase. Free software.
Telegram is also the best at first class support of all the platforms it runs on. In addition to the Qt-based app that's popular on Windows and Linux, the predominant client on macOS/iOS is AppKit/UIKit-based, and there exist numerous other native clients (such as UWP/WinAppSDK on Windows, GTK on Linux, and CLI for anything with a command line).
In comparison everything else puts reasonable effort into the mobile clients and phones in the rest with bloated, half-baked web apps or if you're lucky an iOS Catalyst port.
Along with UI/UX quality, this stuff matters and impacts adoption, even if most users can't put their reasoning into words.
> I don't know a process for becoming the one with the largest userbase.
Easy: Be at the right spot in the right time and be lucky to be noticed.
WhatsApp had one smart idea: tying accounts to phone number, which solved detectability, while SMS where expensive in many regions. When ICQ/AIM still missed the mobile market and before Apple made iMessage.
Easy to replicate, as we can see with Facebook messenger or Google's different attempts, who invested quite a few resources into that.
I shudder to think about calling Telegram UI "good". Maybe chats like Discord spoiled me but both of those feel like way below level of "comfort" for communication longer than "asking about what food you want", especially when talking about code or other stuff that benefits from more richer formatting.
Both look ass at desktop too, way too many wasted space, tho Telegram at least doesn't stretch the chat on the entire width of monitor when in fullscreen, having to go from far left to far right just to read the chat
> I don't know a process for becoming the one with the largest userbase.
I was at WhatsApp from 2014 - 2019. Growing a large userbase from scratch doesn't happen by any one factor. You have to do a lot of things well. (and probably get lucky)
a) potential users need a compelling reason to join. Messaging at data rates was significant, but not in the US were many people had large messaging allowances. Works better than SMS/MMS was compelling for some.
b) existing users need to be satisfied enough to stay: service has to work consistently, client has to work, etc.
c) signup flow needs to work well. Doesn't matter if people want to use the app if they can't. You need to help users understand their phone number (or other identification). You need multiple methods of verification, because SMS doesn't always work. Giving someone a several digit code over the phone is a cognitive task for the user, and it's harder with disjointed speech generation, so you need to spend some time on that too. You need multiple providers because if you can't get verification codes to users, some of those people will give up and never come back. Since you have multiple providers, you need to figure out how to pick one based on current conditions which you also need to figure out how to track. Also --- you need some money, sending all these codes gets expensive. Phone numbers as ids is a blessing because "everyone has one" and you can use the system address book for contacts, but verification costs add up; usernames or email as id make contact discovery messy and a surprising amount of people in the developing world don't have an email address or don't know what it is.
d) users get new phones, a lot, you need to make it easy to move their account. Or they will likely drop your service when they get a new phone.
e) you need to be prepared for and handle large events. If some big news happens, people will want to talk about it. If some similar service has an outage, you will get more traffic --- if you also fall over, that's a lost opportunity.
f) things need to work well on the devices people actually have. Which might not be the ones you would prefer to use. Worldwide, most people don't have flagship phones. If you want a large number of users, having good experiences only on recent flagships is self limiting. Working well (or at least better than alternatives) on low end and older devices is a path towards addressing users that others miss.
There's probably more. Most of these require sustained consistent effort to deliver. It's not a one time thing. And it's not quick. Sustained consistent effort is easy enough as a one product start-up, but it's very hard as a big-corp.
Userbase can be a positive feedback loop: once you have enough users, that becomes its own reason to join ... and having no one to talk to is a reason to leave. There's not really a way to jump start it, unless you've already got a large user base somewhere else that you can use to seed your service.
I tried Jami for a bit with a friend. For both me and my friend, Jami was very unreliable about delivering notifications about new messages. So my friend would send me a message but because I didn’t get any notification about the message it would go days before I opened the app and saw that he had said something, and I’d respond to it and it would be days before he would happen to open the app again because he also didn’t get any notification.
This is sadly a ubiquitous problem with FOSS phone software. Google's and Apple's notification systems are anti-FOSS. You can use your own on Google phones, but then your app will have to wake up periodically to check it, and the system will detect your app as a battery waster, tell the user your app is a battery waster, and automatically prevent your app waking up to prevent battery waste. And on Apple I believe you simply can't do that because they user has to open the app to wake it.
In one of the early releases of animated emoji on Telegram (I want to say the very first one), it did. Then Apple objected and it stopped. Then shortly afterwards like half of the rest started doing something suggestive but not the eggplant. A lot of fun was had on the Internet imagining the product meetings for all of that.
(Not that any of it is particularly relevant to the quality of Telegram’s UI, which is indeed unmatched.)
Basically, Telegram used to have eggplant sticker that cums, until Apple forced them to remove it. They also had a peach sticker that looked like ass. Thus, I am making this joke about Telegram having best UI.
In this meme, Durov, the Telegram founder, says "Colleagues, greetings. Who can make it, so that eggplant cums? Added a task to Notion." Then "employee" sends a cumming eggplant sticker, and Durov replies "This is what I wanted."
QML is a great language to make GUIs. A few years ago I tried XAML, and it honestly kind of sucked in comparison (the verbosity alone made it painful to work with). I haven't tried Slint UI, but supposedly their DSL is even better since it fully compiles to native Rust code.
I found QML to be a terrible language for making GUIs. I really tried with it. But it just felt so hacky and unfinished. A couple of examples (from like 10 years ago so forgive me if I got some of the details a bit wrong):
1. Child components can magically refer to variables in their parents. This is basic encapsulation 101. The only other language I know of that allows that is SystemVerilog and that's from an era where people didn't know better (especially hardware guys).
2. You can create custom widgets... but they can't display text! There's a class called something like QmlSceneGraphTextNode that is the way that all the provided widgets display text but it's private. I guess they might have fixed this eventually but it stayed private for the ~5 years I tried to use it. They wanted me to just use Label widgets in QML land which sucks.
It also felt like there was a pretty huge impedance mismatch between QML and C++ due to its use of Javascript. E.g. stuff like using 64-bit integers. That reminds me:
3. It uses Javascript.
4. I never found a good way to use dialogs. They seem to push you towards having all possible dialogs exist all the time and just showing and hiding them, which is kind of crazy.
I don't think the idea of a GUI DSL is fundamentally bad, but QML is certainly a pretty miserable implementation. Hopefully the Slint guys have learned all of these lessons.
Jetbrains CLion is great for non-Qt C++, albeit paid. It helped me deliver a bank-exchange-grade connector in a tight schedule with very little knowledge of C (at that time). Mostly with static checking, compiling, cmake etc.
I agree Qt Creator is really good, and VSCode with the Microsoft C++ extension is probably not quite as good.
However with the Clangd extension it is much much better. Even better than Qt Creator. 100% accurate C++ code intelligence, really really fast error squigglies. Honestly I was kind of surprised it's even possible to get it that good.
It's not quite on the level of Dart (which is basically instant and perfect), but I'd say it's on the same level as Rust at least in terms of responsiveness and reliability.
> found out that VS Code was running cargo check one way while in the terminal cargo check was doing some other thing, and effectively blowing the cache every time I switched from one to the other
I have a similar problem with JetBrains RustRover. For example when I do cargo build and cargo clippy in the terminal after RustRover has done build it seems to start over rebuilding more things than when I edit something in vim and only use cargo from the terminal.
Yeah I found the same thing. The issue turned out to be that something in my `.bashrc` was appending to `PATH` (or some other env var). Because my `cargo build` commands that were running in one more level of shell than Rust-analyzer, it had different env vars and therefore a different cache key.
Once you fix it so that Rust-analyzer sees the same env vars as your shell then the issue goes away. It's kind of annoyingly hard to debug though.
It would be great to create a torrent like protocol for chat. People would host for their own circle of friends with some central hosting option for non technicals.
I think a self-hosting option for IM that's better than XMPP could be nice... that said, not sure if something like torrent would be good. I gave a lot of thought to something similar for emails, and the biggest issue came down to, it would be difficult to do something anonymous, distributed, and resistant to flooding/poison pill attacks.
Torrents themselves work against this, because you have known hash values as part of seeding... with email and messaging, you wouldn't have one-off advanced knowledge, and if anyone can send anyone a message, you'd be open to a flood of messages from what seems to be randos. There's some of this from scammers on Telegram and other social media, but it would be much worse.
A federated system that's otherwise tethered to a domain/email or similar would at least allow for self-management and/or block listing techniques to work better in practice.
> There's some of this from scammers on Telegram and other social media, but it would be much worse
I get about one scam message per week on Telegram. And the annoying thing with Telegram is that it’s a paid feature to be able to make it so that only your contacts can send you messages.
Additionally, in order to block and report the sender, I first have to open the message, which sends a read receipt to the sender. Which in turn, if the scammers are smart, is something that they make note of automatically.
So one can presume that every time I open a scam message to block and report the sender, as I do, I am also giving the scammers confirmation that this number is actively in use and my number will keep being included in lists of numbers that they and others send scam messages to.
That's great work. Thanks for sharing. I was wondering is there a good way of mixing rust and Qt but I decided that this wouldn't make sense... But I'm used to generate C++ code from uic, and have little experience in qml.
> I believe they have put the most love into their user interfaces out of all the chat programs I have seen
Absolutely true.
Telegram: Best UI. Signal: Best privacy. WhatsApp: Largest userbase.
It's interesting to think about these three dimensions. I could theoretically pinpoint everything that make Telegram's UI the best, and copy it. I could do the same with Signal's privacy. Both of these are technical problems. There's a process for becoming the best at UI, and there's a process for becoming the best at privacy. I don't know a process for becoming the one with the largest userbase.
Other than the 3 big ones, I recently found Jami [1]
Good UI, though not as good as Telegram. Arguably better privacy than Signal - you don't even need an account if you don't want. Zero userbase. Free software.
[1] https://jami.net/
Telegram is also the best at first class support of all the platforms it runs on. In addition to the Qt-based app that's popular on Windows and Linux, the predominant client on macOS/iOS is AppKit/UIKit-based, and there exist numerous other native clients (such as UWP/WinAppSDK on Windows, GTK on Linux, and CLI for anything with a command line).
In comparison everything else puts reasonable effort into the mobile clients and phones in the rest with bloated, half-baked web apps or if you're lucky an iOS Catalyst port.
Along with UI/UX quality, this stuff matters and impacts adoption, even if most users can't put their reasoning into words.
> I don't know a process for becoming the one with the largest userbase.
Easy: Be at the right spot in the right time and be lucky to be noticed.
WhatsApp had one smart idea: tying accounts to phone number, which solved detectability, while SMS where expensive in many regions. When ICQ/AIM still missed the mobile market and before Apple made iMessage.
Easy to replicate, as we can see with Facebook messenger or Google's different attempts, who invested quite a few resources into that.
I shudder to think about calling Telegram UI "good". Maybe chats like Discord spoiled me but both of those feel like way below level of "comfort" for communication longer than "asking about what food you want", especially when talking about code or other stuff that benefits from more richer formatting.
Both look ass at desktop too, way too many wasted space, tho Telegram at least doesn't stretch the chat on the entire width of monitor when in fullscreen, having to go from far left to far right just to read the chat
> I don't know a process for becoming the one with the largest userbase.
I was at WhatsApp from 2014 - 2019. Growing a large userbase from scratch doesn't happen by any one factor. You have to do a lot of things well. (and probably get lucky)
a) potential users need a compelling reason to join. Messaging at data rates was significant, but not in the US were many people had large messaging allowances. Works better than SMS/MMS was compelling for some.
b) existing users need to be satisfied enough to stay: service has to work consistently, client has to work, etc.
c) signup flow needs to work well. Doesn't matter if people want to use the app if they can't. You need to help users understand their phone number (or other identification). You need multiple methods of verification, because SMS doesn't always work. Giving someone a several digit code over the phone is a cognitive task for the user, and it's harder with disjointed speech generation, so you need to spend some time on that too. You need multiple providers because if you can't get verification codes to users, some of those people will give up and never come back. Since you have multiple providers, you need to figure out how to pick one based on current conditions which you also need to figure out how to track. Also --- you need some money, sending all these codes gets expensive. Phone numbers as ids is a blessing because "everyone has one" and you can use the system address book for contacts, but verification costs add up; usernames or email as id make contact discovery messy and a surprising amount of people in the developing world don't have an email address or don't know what it is.
d) users get new phones, a lot, you need to make it easy to move their account. Or they will likely drop your service when they get a new phone.
e) you need to be prepared for and handle large events. If some big news happens, people will want to talk about it. If some similar service has an outage, you will get more traffic --- if you also fall over, that's a lost opportunity.
f) things need to work well on the devices people actually have. Which might not be the ones you would prefer to use. Worldwide, most people don't have flagship phones. If you want a large number of users, having good experiences only on recent flagships is self limiting. Working well (or at least better than alternatives) on low end and older devices is a path towards addressing users that others miss.
There's probably more. Most of these require sustained consistent effort to deliver. It's not a one time thing. And it's not quick. Sustained consistent effort is easy enough as a one product start-up, but it's very hard as a big-corp.
Userbase can be a positive feedback loop: once you have enough users, that becomes its own reason to join ... and having no one to talk to is a reason to leave. There's not really a way to jump start it, unless you've already got a large user base somewhere else that you can use to seed your service.
> things need to work well on the devices people actually have
Until 2025, WhatsApp was even on KaiOS
That's great, thank you.
I tried Jami for a bit with a friend. For both me and my friend, Jami was very unreliable about delivering notifications about new messages. So my friend would send me a message but because I didn’t get any notification about the message it would go days before I opened the app and saw that he had said something, and I’d respond to it and it would be days before he would happen to open the app again because he also didn’t get any notification.
This is sadly a ubiquitous problem with FOSS phone software. Google's and Apple's notification systems are anti-FOSS. You can use your own on Google phones, but then your app will have to wake up periodically to check it, and the system will detect your app as a battery waster, tell the user your app is a battery waster, and automatically prevent your app waking up to prevent battery waste. And on Apple I believe you simply can't do that because they user has to open the app to wake it.
I never had that experience because I never found another person with Jami.
does Jami store messages server side like Telegram to enable access to messages everywhere?
They all store messages server side.
Not whatsapp afaik
Whatsapp backs up unencrypted messages to Google cloud on Android and whatever it's called for Apple.
The government can just ask them to turn over those. (note that this is legally very different from forcing someone to unlock a device)
- Send a message to someone whose phone is off
- turn off your phone
- get that person to turn their phone on
- they receive the message.
Where was it stored, if not in WhatsApps servers?
> Telegram: Best UI
Hard no. Have you tried activating encryption in personal chats?
"Telegram: Best UI"
https://i.imgur.com/YDaP5EH.gif
I see "content not viewable in your region". Did I miss the joke or something? I never had that experience in Telegram.
Are you in the UK? Here, hopefully Cloudflare isn't blocked for you
https://pub-aff931c6a6424ddbaff3eccef55f4ae1.r2.dev/IMG_7372...
Guys, can you make an eggplant that cums. I don't get it.
In one of the early releases of animated emoji on Telegram (I want to say the very first one), it did. Then Apple objected and it stopped. Then shortly afterwards like half of the rest started doing something suggestive but not the eggplant. A lot of fun was had on the Internet imagining the product meetings for all of that.
(Not that any of it is particularly relevant to the quality of Telegram’s UI, which is indeed unmatched.)
Basically, Telegram used to have eggplant sticker that cums, until Apple forced them to remove it. They also had a peach sticker that looked like ass. Thus, I am making this joke about Telegram having best UI.
In this meme, Durov, the Telegram founder, says "Colleagues, greetings. Who can make it, so that eggplant cums? Added a task to Notion." Then "employee" sends a cumming eggplant sticker, and Durov replies "This is what I wanted."
QML is a great language to make GUIs. A few years ago I tried XAML, and it honestly kind of sucked in comparison (the verbosity alone made it painful to work with). I haven't tried Slint UI, but supposedly their DSL is even better since it fully compiles to native Rust code.
I found QML to be a terrible language for making GUIs. I really tried with it. But it just felt so hacky and unfinished. A couple of examples (from like 10 years ago so forgive me if I got some of the details a bit wrong):
1. Child components can magically refer to variables in their parents. This is basic encapsulation 101. The only other language I know of that allows that is SystemVerilog and that's from an era where people didn't know better (especially hardware guys).
2. You can create custom widgets... but they can't display text! There's a class called something like QmlSceneGraphTextNode that is the way that all the provided widgets display text but it's private. I guess they might have fixed this eventually but it stayed private for the ~5 years I tried to use it. They wanted me to just use Label widgets in QML land which sucks.
It also felt like there was a pretty huge impedance mismatch between QML and C++ due to its use of Javascript. E.g. stuff like using 64-bit integers. That reminds me:
3. It uses Javascript.
4. I never found a good way to use dialogs. They seem to push you towards having all possible dialogs exist all the time and just showing and hiding them, which is kind of crazy.
I don't think the idea of a GUI DSL is fundamentally bad, but QML is certainly a pretty miserable implementation. Hopefully the Slint guys have learned all of these lessons.
> Qt Creator is actually very good, perhaps unexpectedly so for those who haven’t used it
This. I can't abide VSCode. I instead use Qt Creator for all my C++ development.
Me too.
Until having language specific features really lost to AI auto complete, and now it's some vscode flavor.
Jetbrains CLion is great for non-Qt C++, albeit paid. It helped me deliver a bank-exchange-grade connector in a tight schedule with very little knowledge of C (at that time). Mostly with static checking, compiling, cmake etc.
I would personally use qtcreator over clion (and in fact, I do) for not qt c/c++ projects.
It’s just a great ide. Using qt has nothing to do with making it a better or worse ide.
I agree Qt Creator is really good, and VSCode with the Microsoft C++ extension is probably not quite as good.
However with the Clangd extension it is much much better. Even better than Qt Creator. 100% accurate C++ code intelligence, really really fast error squigglies. Honestly I was kind of surprised it's even possible to get it that good.
It's not quite on the level of Dart (which is basically instant and perfect), but I'd say it's on the same level as Rust at least in terms of responsiveness and reliability.
> found out that VS Code was running cargo check one way while in the terminal cargo check was doing some other thing, and effectively blowing the cache every time I switched from one to the other
I have a similar problem with JetBrains RustRover. For example when I do cargo build and cargo clippy in the terminal after RustRover has done build it seems to start over rebuilding more things than when I edit something in vim and only use cargo from the terminal.
Yeah I found the same thing. The issue turned out to be that something in my `.bashrc` was appending to `PATH` (or some other env var). Because my `cargo build` commands that were running in one more level of shell than Rust-analyzer, it had different env vars and therefore a different cache key.
Once you fix it so that Rust-analyzer sees the same env vars as your shell then the issue goes away. It's kind of annoyingly hard to debug though.
It would be great to create a torrent like protocol for chat. People would host for their own circle of friends with some central hosting option for non technicals.
I think a self-hosting option for IM that's better than XMPP could be nice... that said, not sure if something like torrent would be good. I gave a lot of thought to something similar for emails, and the biggest issue came down to, it would be difficult to do something anonymous, distributed, and resistant to flooding/poison pill attacks.
Torrents themselves work against this, because you have known hash values as part of seeding... with email and messaging, you wouldn't have one-off advanced knowledge, and if anyone can send anyone a message, you'd be open to a flood of messages from what seems to be randos. There's some of this from scammers on Telegram and other social media, but it would be much worse.
A federated system that's otherwise tethered to a domain/email or similar would at least allow for self-management and/or block listing techniques to work better in practice.
> There's some of this from scammers on Telegram and other social media, but it would be much worse
I get about one scam message per week on Telegram. And the annoying thing with Telegram is that it’s a paid feature to be able to make it so that only your contacts can send you messages.
Additionally, in order to block and report the sender, I first have to open the message, which sends a read receipt to the sender. Which in turn, if the scammers are smart, is something that they make note of automatically.
So one can presume that every time I open a scam message to block and report the sender, as I do, I am also giving the scammers confirmation that this number is actively in use and my number will keep being included in lists of numbers that they and others send scam messages to.
So Matrix?
There were some rather forgotten nowadays projects like Tox, Briar, Ricochet that should fit what you describe
That's great work. Thanks for sharing. I was wondering is there a good way of mixing rust and Qt but I decided that this wouldn't make sense... But I'm used to generate C++ code from uic, and have little experience in qml.