Introduction
Introduction Statistics Contact Development Disclaimer Help
_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
Visit Hacker News on the Web
COMMENT PAGE FOR:
Writing a blatant Telegram clone using Qt, QML and Rust. And C++
Imustaskforhelp wrote 23 hours 9 min ago:
Fascinating.
I am seeing that you are writing a matrix client UI basically which is
nice but I am interested if its possible that you could write it in
(agnostic?) UI way if if it makes sense, where I can swap out any other
protocol instead of matrix too
I was just interested in something similar once and there are other
protocols like session,simplex,signal etc. too which I feel like can
definitely benefit from an unified UI perhaps
Personally I am always interested if any messaging app should just
create a cli application/api and have someone else create the UI since
I feel like the UI bugs and similar can definitely be fixed if its not
in house.
I am curious of your opinion regarding it but the project looks cool!
Personally although I can enjoy telegram's UI, nothing beats cinny's UI
ever.
Cinny has the best UI of any messaging app I have ever seen personally,
there are only very few things I wish to change in that, which can be
changed via userstyle and even recent modern element feels good to me
personally but cinny is brilliant overall
So I am interested to hear what your thoughts are on cinny too
(cinny.in)
adikso wrote 12 hours 24 min ago:
I needed a simple chat UI for a diy "SMS gateway" (for an extra
[nearly free] phone number used only to receive SMS - mainly for
registrations and deliveries) and I ended up using Delta Chat that
uses your email server under the hood. So I implemented all the logic
based on emails... but it would be much better to have some nice
looking UI with easy integration.
prmoustache wrote 21 hours 9 min ago:
Basically pidgin but with telegram's UI.
Imustaskforhelp wrote 12 hours 36 min ago:
Oh yes! I had heard of pidgin but only had people use it for
IRC/XMPP but I didnt know it was an universal chat client.
Yes you are absolutely correct, basically pidgin but with
telegram's UI (or cinny's UI can be good too) but yea, thanks for
pointing out to the resource again! I didnt know it was universal
chat client, thanks for helping me know that.
rw_grim wrote 10 hours 8 min ago:
You could just use libpurple to do all the im stuff and literally
just write a user interface. That said, purple 2 isn't really
designed for modern chat networks, but we're trying to solve that
with the still unreleased purple3.
You may be interested in our State of the Birds which cover
libpurple and pidgin development.
[1]: https://discourse.imfreedom.org/tag/state-of-the-bird
alper wrote 23 hours 40 min ago:
Great work on the 20% of making a working chat app. Now somebody has to
do the remaining 80% and then the other remaining 80%.
yokljo wrote 21 hours 24 min ago:
Thanks. It was just a fun exercise and I had fun writing about it.
solarkraft wrote 1 day ago:
I like this and would like it to continue! FOSS chat UX is, in average,
not good at all in my opinion. I don’t need an exact copy of
Telegram, but something with a similar amount of care put into it
(which is a lot!).
> There's currently no Matrix to speak of, but it's the thought that
counts.
Welp! I was going to ask about it. I’m curious how that goes because
Matrix is the natural thing to support, but I’ve been quite critical
of that being too hard to actually do. The Rust SDK supposedly provides
a lot of support here, so maybe the experience won’t be too bad. Some
inherent protocol stuff may still limit the UX and I‘d love a
thorough writeup on it.
scuff3d wrote 1 day ago:
I think your emoji pop up thing looks better then Telegram's. There's
has way too much animation with all the emoji bouncing around. Yours
was nice and clean.
yokljo wrote 21 hours 27 min ago:
Haha thank you, I was quite pleased with the outcome. It's good,
cause getting the animated emojis working would be pretty involved :P
RustSupremacist wrote 1 day ago:
The GUI situation in Rust is dreadful: [1] Rust is simply not meant for
GUI-based data design but I still want Qt in Rust. That's it. Not QML
or Slint or egui or Tauri or gpui or Iced. No markup at all. None of
the immediate mode things. No double and triple languages like this C++
mess. Definitely not GTK or the other non-imperative subpar things.
There is one option. Until there is more than one, Qt is the best. No
one else is worried about this missed opportunity.
[1]: https://www.boringcactus.com/2025/04/13/2025-survey-of-rust-gu...
yokljo wrote 21 hours 31 min ago:
I'm the OP, and I have to pitch in here. This comment is a bit
unhinged, basically claiming that every WIP GUI library written in
Rust sucks on principle. This is false, and there are some very good
ongoing efforts that will probably be great and desirable GUI options
in the future.
Also, the comment claims that QML is not Qt. QML was added to Qt in
2009 and has been where a large proportion of the developer's focus
has been ever since. It is absolutely Qt and you can't claim
otherwise.
A bit of a passionate response to a passionate parent comment.
ahartmetz wrote 1 day ago:
Dreadful may be your opinion, but there is actually much more
approval than disapproval for Slint in that huge overview.
scuff3d wrote 1 day ago:
What about gpui? The Zed teams GUI framework?
Edit: Oh, my bad. I thought they open sourced it separate from Zed.
Looks like they are still tied together.
eviks wrote 1 day ago:
But they did open source it separately? [1] How are they tied?
[1]: https://www.gpui.rs/
throwaway1389z wrote 1 day ago:
Why does the link try to download a copy of fart from Wikipedia?
sph wrote 20 hours 52 min ago:
View source:
[1]: https://www.boringcactus.com/assets/site.js
IAmLiterallyAB wrote 1 day ago:
Another hackernews hater checking the http referrer I'd guess
p0w3n3d wrote 1 day ago:
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.
yokljo wrote 1 day ago:
Hey, I'm the author of the post. Thanks for reading! Appreciate it :)
I think QML is very easy to get started with and you should just give
it a go. It's not without its weirdness as other comments have
already mentioned, and unfortunately there's still many controls that
are less-than-ideal for desktop applications than their original
QWidget equivalents. Using QWidgets+UIC is nice, but in my experience
creates problems when you want to get fancy and custom with your
design, with animations and shifting layouts and whatnot, well,
especially after using QML.
scrivanodev wrote 1 day ago:
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.
IshKebab wrote 1 day ago:
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.
silon42 wrote 1 day ago:
3 makes me not wanna use Qt anymore.
ahartmetz wrote 1 day ago:
It uses JS like the early web did: for little pieces of logic
here and there. It isn't based or structured around, and
certainly not made of, JS. It's fine. I don't like JS neither,
but I do like QML.
Also, feel free to use QtWidgets for desktop apps, it's IMO the
better technology for that unless your data is simple and you
want it to look like a typical touch UI for some reason.
IshKebab wrote 1 day ago:
Fortunately you can still just use QtWidgets. You just don't get
fancy animations.
QuantumNomad_ wrote 1 day ago:
> 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.
IshKebab wrote 1 day ago:
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.
LorenDB wrote 1 day ago:
> 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.
zerr wrote 1 day ago:
No love for KDevelop? :)
spacechild1 wrote 1 day ago:
Fellow QtCreator user here :)
fooker wrote 1 day ago:
Me too.
Until having language specific features really lost to AI auto
complete, and now it's some vscode flavor.
IshKebab wrote 1 day ago:
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.
spacechild1 wrote 1 day ago:
Qt Creator also supports clangd: [1] . Personally, I haven't tried
it yet.
[1]: https://doc.qt.io/qtcreator/creator-preferences-cpp-clangd...
irishcoffee wrote 1 day ago:
Nah, it isn’t much much better. It’s at best the same.
Clangd is clangd. It integrates the same everywhere.
IshKebab wrote 23 hours 58 min ago:
I meant Clangd is better than Qt Creator's native code
intelligence. I haven't used it for years so I didn't know it
integrates Clangd now.
p0w3n3d wrote 1 day ago:
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.
spacechild1 wrote 1 day ago:
Just in case anyone has missed the news: since May 2025 CLion is
free for non-commercial use.
p0w3n3d wrote 1 day ago:
I missed it too
However I guess that in the case of Jetbrains this means you get
your code infiltrated and stolen to teach the AI on
irishcoffee wrote 1 day ago:
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.
dev_l1x_be wrote 1 day ago:
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.
pndy wrote 1 day ago:
There were some rather forgotten nowadays projects like Tox, Briar,
Ricochet that should fit what you describe
dev_l1x_be wrote 1 day ago:
Thanks! I was not aware.
tracker1 wrote 1 day ago:
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.
WD-42 wrote 1 day ago:
So Matrix?
QuantumNomad_ wrote 1 day ago:
> 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.
ekjhgkejhgk wrote 1 day ago:
> 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/
miki123211 wrote 1 day ago:
Part of "good UI" is not having E2E, which e.g. gives you sync that
actually works, even on new devices, with no weird backups and PIN
codes necessary, just like the good old days.
jeroenhd wrote 19 hours 39 min ago:
E2EE can work just fine with backup and sync. Signal chose not to
do it for a long time and remains cautious, sticking to security
over tolerating security-ignorant users.
WhatsApp is end-to-end encrypted, for instance, and it's used by
billions. It being closed-source changes nothing about its feature
set.
These days, Signal supports (encrypted, even cloud) backups just
like WhatsApp or any other messenger.
The problem with UX for many of these apps is that they're designed
for people who want to be sure that the government can't read their
messages, but that's not something that's possible without
compromising on the ease-of-use of SMS and other insecure methods.
It's foolish to try to shove a Signal-shaped app into a SMS-shaped
hole. I believe Signal's mobile app and (with a better underlying
protocol) Telegram's cross-platform UX offer the best mix of secure
and safe by default.
jcelerier wrote 14 hours 29 min ago:
> WhatsApp is end-to-end encrypted, for instance, and it's used
by billions.
and it causes no end of pain when you switch phones (esp. if you
loose one).
Of all the chat services i use, Telegram is the only one that
NEVER, EVER LOST ANY OF MY MESSAGES. Maybe for some people
privacy is more important ; for me, not loosing any message I
have under absolutely no circumstance is the n°1 baseline
requirement for something to even be called a chat app.
aledue wrote 1 day ago:
Partly, but Signal etc. could just as well have a fast and polished
client, and Telegram a clunky electron sloth. Even if you restrict
yourself to one device (so no syncing) the difference in quality is
undeniable.
jeroenhd wrote 19 hours 33 min ago:
Using Molly to get cross-device Signal support works pretty well,
though the Android-only approach requires Waydroid or a
deprecated Windows feature to run on desktop, unfortunately.
Still, it's a lot better than the alternative (which from
Signal's side seems to be "none, be glad we support desktop sync
at all").
methuselah_in wrote 1 day ago:
Jami is so useless that never recieved messages after few hours. And
there is no way you can make it work properly for longer duration.
tptacek wrote 1 day ago:
Just bear in mind that Signal's goals are in tension with the other 2
pole's goals.
scotty79 wrote 1 day ago:
How did we end up with this mess of disjoint chat systems each with
their own userbase? Doesn't it indicate that this market desperately
needs regulation? Would email look the same if it was left to be
invented by the corporations?
Either you provide message interchange with any other message system
operating in a specific country or you can't advertise or sell
anything in this country (also app stores must country wide ban).
Bootstrap by taking two largest chats and offering them provisional
access to the market for few months. If they can provide interchange
between them they can remain and others can follow. If not bigest one
is out, let's say for two years and the third one (pre-ban) tries to
establish interchange with the remaining of the two biggest.
JuniperMesos wrote 16 min ago:
> How did we end up with this mess of disjoint chat systems each
with their own userbase? Doesn't it indicate that this market
desperately needs regulation?
Why do you assume that the regulation that would actually get
passed by the actual government would result in effective chat
interchange between different protocols, and not just entrench some
existing platform while making it technically illegal for another
organization to try to compete with them?
> Either you provide message interchange with any other message
system operating in a specific country or you can't advertise or
sell anything in this country (also app stores must country wide
ban).
Would this make it technically illegal for me to use F-Droid to
install an open-source implementation of a novel chat protocol that
doesn't support interchange with existing chat platforms yet? Does
this make it possible for me to force existing chat platforms to be
suddenly illegal by releasing a novel open-source chat protocol
without coordinating it with those platforms?
> Would email look the same if it was left to be invented by the
corporations?
Probably not, but email is a heavily-flawed protocol, so I'm not
sure that's a good thing. Also, although email was invented in the
1970s, making it one of the oldest internet protocols still used,
it's been extended over the years, and I'm sure at least some of
those extensions were developed by various for-profit companies
(perhaps ones which no longer exist).
bruce511 wrote 1 day ago:
This is going to be a terribly cynical comment, but I've noticed a
trend here on HN to introduce laws to fix problems.
The short version is that, no, you can't law yourself out of this
(or pretty much anything. )
Firstly, laws have national jurisdiction. There are no "all the
countries agreed to this" laws.
Secondly, the US can't actually pass any laws anyway. Congress is
deadlocked. It can't even get around to killing daylight saving
clock changes (which passed the senate with unanimous support.)
Plus any laws (or, more recently executive orders) just end up in
court forever. And when passed may, or may not, be enforced (or
enforceable. )
And that's before I point out that big tech buys (sorry, "lobbies")
govt in the first place. Apple, Meta, Google would all pay to make
this bill go away.
Lastly, everyone seems to forget that interoperability leads to
spam. Email is open and completely flooded. SMS is open and
basically unusable. Whatsapp grew their user base in part because
the experience was spam free. So even if laws declaring openness
were proposed they would be far from universally supported.
cosmic_cheese wrote 1 day ago:
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.
PunchyHamster wrote 1 day ago:
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
sznio wrote 20 hours 20 min ago:
>Maybe chats like Discord spoiled me
Discord UI is abysmal, especially on mobile. Every time I start it
I shudder, stare at a stuttering UI that takes way too long to
become responsive. It feels like it will make my phone explode.
bluecalm wrote 1 day ago:
We are comparing it to WhatsApp that lags (very significantly) on
keyboard input and doesn't even have a way to paste code.
mananaysiempre wrote 1 day ago:
> especially when talking about code or other stuff that benefits
from more richer formatting
Telegram has GFM-style fenced code blocks including language
indication for syntax highlighting (e.g. ```python), what else
could one want for code? (I guess syntax-highlighted inline
monospaced blocks, it does indeed not have them.)
I wouldn’t say Telegram is perfect. The polish and the actual
experience of using it are great. Yet when you look closely, it’s
as rickety as you’d expect given the insane rate of shipping
features that they’ve sustained until quite recently. (For
instance, there were a few weeks where porn spambots in public
chats would post single—thus animated—emoji, seemingly because
the UI didn’t allow you to open the context menu on those in
order to report spam, because the usual single-tap handler for that
was overriden by the handler that would play the emoji animation.)
And the discoverability is in the toilet. Did you know that you can
preview a chat without marking its messages read by long-pressing
on the image? That works on Android—except on a tablet where your
screen is large enough that you get the two-pane view; I thought
for weeks they had removed that feature until I realized the tablet
was the problem. And the only thing that mentions its existence is
AFAIK an item in release notes from 2018[1,2]. Did you know that
you could pop out individual chats into their own AIM/ICQ-style
windows on desktop? I don’t think it’s documented anywhere, but
it’s in the context menu.
If it were the 2000s I wouldn’t have given Telegram any HCI
design awards. But everything else is considerably worse, with the
possible exception of (indeed) Discord. (I prefer Telegram’s
abundant tools for scrubbing through history though, it’s one of
the few things in that category that’s actually better a calendar
of posts like blogs used to have.) [1] (it didn’t even make the
headline!) [2] Just found out (via the comments in [2] ) that this
actually exists on desktop too: Alt-click the chat. Argh.
[1]: https://telegram.org/blog/unread-replace-2x#and-three-more...
[2]: https://bugs.telegram.org/c/52
AdrenalinMd wrote 1 day ago:
> Telegram: Best UI
Hard no. Have you tried activating encryption in personal chats?
QuantumNomad_ wrote 1 day ago:
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.
immibis wrote 1 day ago:
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.
01HNNWZ0MV43FF wrote 1 day ago:
On Android you can use UnifiedPush so just one app gets
background permissions and it wakes everything else up. Chat apps
are starting to support it
scotty79 wrote 1 day ago:
Not just FOSS. Many corporate apps have exactly the same problems
with notification delivery. Those systems barely work.
ekjhgkejhgk wrote 1 day ago:
I never had that experience because I never found another person
with Jami.
johannes1234321 wrote 1 day ago:
> 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.
tcfhgj wrote 1 day ago:
does Jami store messages server side like Telegram to enable access
to messages everywhere?
ekjhgkejhgk wrote 1 day ago:
They all store messages server side.
prmoustache wrote 21 hours 11 min ago:
jami doesn't store message on a server, at least not in 1:1
connection. It is one of the Achille heel in the sense that if
you send a message, your recipient is offline, then you go
offline before your recipient goes online the message will not
have been delivered and will wait until both are online at the
same time. It is particularly annoying because most android
firmware + iphone kill the app when it is in the background so
that people tend to think it is the app that is not working well
whereas it is really the operating system that aggressively kill
it and prevent it from working well.
A workaround for the messages not being received is to have an
opened session on the desktop version running 24/7 at home.
I read that group chats (swarm) are implemented using git and I
think the changes are pushed between clients directly. Again it
is nice if you have a permanent group to have at least one client
running 24/7
jatins wrote 1 day ago:
Not whatsapp afaik
ekjhgkejhgk wrote 1 day ago:
- 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?
tcfhgj wrote 1 day ago:
Well, not exactly what I meant.
Burn your phone, setup a new phone, log in, view your
messages was what I meant.
toyg wrote 1 hour 59 min ago:
.... That also works? Unless you believe that your entire
chat history is magically encoded in a QR code...
fooker wrote 1 day ago:
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)
__jonas wrote 1 day ago:
It does not just do that, no.
It has the option of doing that, it asks you if you want to
enable the backups.
It also allows you to encrypt the backups with a passkey or a
password that you can manually set, client-side.
It didn’t always have the encryption option I think.
toast0 wrote 1 day ago:
> 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.
4gotunameagain wrote 22 hours 14 min ago:
Of all the things you listed, which are surely important, you also
said the single most important factor in the end:
> once you have enough users, that becomes its own reason to join.
There's not really a way to jump start it
So, a monopoly that was lucky enough to be the first one to solve
some (minor, if I may) technical problems.
We need forced interoperability. Facebook has no right to control
the communications of so many billions of people, just because
Whatsapp got lucky and then facebook acquired them.
Who knows how much data they harvest.
igouy wrote 1 day ago:
> things need to work well on the devices people actually have
Until 2025, WhatsApp was even on KaiOS
ekjhgkejhgk wrote 1 day ago:
That's great, thank you.
koakuma-chan wrote 1 day ago:
"Telegram: Best UI"
[1]: https://i.imgur.com/YDaP5EH.gif
ekjhgkejhgk wrote 1 day ago:
I see "content not viewable in your region". Did I miss the joke or
something? I never had that experience in Telegram.
koakuma-chan wrote 1 day ago:
Are you in the UK? Here, hopefully Cloudflare isn't blocked for
you
[1]: https://pub-aff931c6a6424ddbaff3eccef55f4ae1.r2.dev/IMG_...
ekjhgkejhgk wrote 1 day ago:
Guys, can you make an eggplant that cums. I don't get it.
mananaysiempre wrote 1 day ago:
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.)
koakuma-chan wrote 1 day ago:
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."
<- back to front page
You are viewing proxied material from codevoid.de. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.