[Feature Request] Secret Chats in Telegram Desktop

This issue is a continuation of telegramdesktop#871 and telegramdesktop#16835 and is dedicated to the code bounty campaign related to lack of implementation of a Secret Chat feature (end-to-end encryption in private messages) in Telegram Desktop.

The objective is to implement the Secret Chats feature into this Telegram client: https://github.com/telegramdesktop/tdesktop

It is possible to do it with 3 different ways (but not limited to):

~~Migrating tdesktop to TDLib~~ / ~~Including TDLib to Telegram Desktop and using its Secret Chat API partly~~ comment from @lukejohnsonrp
Extracting the Secret Chats code from TDLib or telegram-api (https://github.com/vysheng/tg / https://github.com/vysheng/tgl) and reimplementing it into tdesktop
Reimplementing it from scratch based on the official public specification available here https://core.telegram.org/api/end-to-end and https://core.telegram.org/schema/end-to-end
Only protocol handlers need to be implemented, because all the cryptographic functions are already present in the Telegram Desktop (source)

This code bounty doesn't limit the programmer to any specific way of implementation, as soon as the final result will make possible to use Secret Chats on the open source Telegram Desktop (tdesktop) client on Linux and Windows in the exactly same way as it's done in mobile clients.

UPDATE 04/2022 / Funds distribution scheme:

There will be 3 payouts based on completion of the following stages:

[1/3] ~~Estabilishing Secret Chats via DH key exchange (ability to send and accept Secret Chat requests)~~ [COMPLETE] in sergiotarxz@41fcaa8
[2/3] ~~Ability to send and receive encrypted messages in estabilished Secret Chats~~ [COMPLETE] in sergiotarxz@41fcaa8
[3/3] Re-keying (PFS) and media sharing in Secret Chats

The developer(s) will receive 1 ETH for completing one of the stages from the list above, totalling 3 ETH for all stages. The source code should be available and compilable.

The adjacent functionality such as deleting and configuring Secret Chat options can be done during any phase of the work progress described in the list above, however it must be done before or with 3/3.

I have created a verified signature for my Ethereum address containing the funds for this issue: https://etherscan.io/verifySig/4431 (https://etherscan.io/address/0xd19ee4a49b9214c4c22694bb01f225baf35f6efc)

Any voluntary donations are welcome. You can send them to the address above.

My email for communication is marcovelon@protonmail.com

CURRENT PROJECT FUNDING:

The overall funding now is 13000 USDC and 1.18 ETH (~3929 USD)

The campaign has been funded with 2.2 ETH which is equivalent to 0.15 BTC (turned out it's impossible to fund campaigns with BTC on Gitcoin). The proof of funds is available in the invoice attached to the campaign available at https://gitcoin.co/issue/marcovelon/tdesktop/2/100026398

UPDATE 04/2022: the campaign has been withdrawn from Gitcoin because their platform is totally broken. The funds distribution will be performed manually by me after completion of steps written in the first post. The current funding is 3 ETH and doesn't limit this only to 1 coder.

I just want to thank you on your efforts to implement secret/encrypted chats into telegram desktop. This feature has been missing since 2015, and has been asked for regularly by the community since. Yet the developers express no interest and close any issue, referring back to a post from 2015.

I wish you and the community well and hope this functionality is implemented.

Update: currently working on adding in the logic for the secret chat, GUI is almost finished. Sometime in the next week or 2 I will be uploading my local commits to my account so the code will be available. Mods who see this, let me know if the inactivity issue has been solved, I forget we have to post regular WIP on here.

@basedcookie

Thank you so much for working on this @basedcookie.

When it's done maybe you can post a crypto address to donate to (BTC, XMR or LTC for example), because I can't for the life of me figure out how gitcoin works.

Since the bounty has been abandoned by basedcookie (no updates for more than 2 months), it is now open for a new applicant.

If you are interested to code this feature, you can enroll here: https://gitcoin.co/issue/marcovelon/tdesktop/2/100026398

I had started working on this project, and will soon be posting the updates.

@basedcookie

Sad to see them @basedcookie leave. But good to see there is still interest in this project and hopefully this feature will be implemented.

@OMTDesign

@OMTDesign Yeah, as now I am working on this project it will very soon be completed, I have expertise in cryptographic algorithms and hence it will be not a very difficult task for me

@dhruvjain1122

@dhruvjain1122 which approach are you taking? Migration to TDLib?

@arch-btw

@arch-btw can't speak for them, but back when I was working on this I was trying to implement the feature directly into the existing code, personally that proved to be a little challenging and time consuming. If I were to work on it again I would take the approach of migrating to TDLib

@dm17

Alright, I think many of you will agree with the fact we have reached some point of absurd never seen before in FOSS community and it feels like Telegram purposely instructs their open source relations team to avoid this topic with an utmost effort.

I am not sure what exactly is causing a nearly zero interest in this issue, however my suspections are that it's either one of those:

lack of marketing for this issue, yet I highly doubt it, because there is a big ask for this feature since tdesktop appearance. See Secret chat telegramdesktop/tdesktop#871 [Feature Request] Secret Chats telegramdesktop/tdesktop#68 [Feature Request] Secret chat telegramdesktop/tdesktop#118 Secret Chat telegramdesktop/tdesktop#619 Telegram Secret Chat? telegramdesktop/tdesktop#8071 [Feature Request] Add "Start secret chat" in the desktop version telegramdesktop/tdesktop#17216 no secret chat! there is no button to start a new chat telegramdesktop/tdesktop#16938 Secret chats [Question] telegramdesktop/tdesktop#16878 [Feature Request] Secret Chats on Desktop Client telegramdesktop/tdesktop#16772 [Question] Why Desktop hasn't secret chats if Unigram has? telegramdesktop/tdesktop#16409 [Feature Request] Secret Chat on Desktop (Like Signal) telegramdesktop/tdesktop#16388 Secret chat telegramdesktop/tdesktop#10162 and so on https://github.com/telegramdesktop/tdesktop/issues?q=is%3Aissue+secret+chat - the amount of requests is ridiculously high.
insufficient funds announced by me, however, I expect more people to donate crypto to developers who will achieve that, so shouldn't be the case either.
the Telegram dev community itself being influenced by Pavel Durov's dubious views on IT Security with his fallacious argumentation from here https://tsf.telegram.org/manuals/e2ee-simple#2-why-are-there-no-secret-chats-on-desktop-apps . I would even say that they practice sophistry, since all those statements are extremely misleading and here is why:

Desktops are less personal. We log in from many places on web and desktop. Many of our desktops are monitored by network administrators at work, or accessed by family members at home. We often leave our desktops and even laptops unattended. It's much easier to keep an eye on your phone. [Telegram team's argumentation]

No, they are not less personal; laptops and towers can be even more personal than mobile devices.
On desktop apps we log in with the same frequency as on mobile due to same session-preserving mechanisms. Most people don't let network administrators or family members to access their personal desktops, but in case they do, they should be aware of security risks and take measures to avoid personal data leak (why not writing about this instead of making misleasing statements?). We often leave our mobile unattended and many people don't even use proper security locking mechanisms on Android phones; desktop users are covered by automatic screen locking and login screen; many desktop users also use full disk encryption. It's also easy to keep an eye on your desktop in case it's a laptop, and tower desktops should be protected by full disk encryption. Additionally, the probability of having a mobile device stolen/lost is significantly higher than for desktop. [My counter-argumentation]

Open systems vs. Sandboxed systems. Desktop systems and browsers are much more open environments, as opposed to sandboxed environments like mobile OSs. To have Secret Chats, you need your app to store data on the device, and implementing this is slightly more complicated in open systems. The Web and Desktop apps currently get all data from the cloud on startup and discard it when you quit or log out. This would mean losing all your secret chats each time you shut down your computer. [Telegram team's argumentation]

The sandboxing on mobile devices is as insecure as desktops without sandboxing ("open systems"...); there is no storage sandboxing on mobile devices and all the apps have access to the same storage, since one app can access the files shared by/with another app located on the emulated storage; also, there are lots of efficient sandboxing for desktop, such as firejail or using VMs/containers, which is much more secure than mobile OS sandboxing solutions.
To have Secret Chats, you need your app to store data on the device, and implementing this is no way more complicated on desktops, because this is how most programs (or "apps") work since the hard drive technology was created; on desktop devices, especially running Linux with encrypted home partitions or full disk encryption, there is a thing called 'local storage' which is intended to be used for such cases; this is how browsers and other network apps store all the sensitive information as well, and nothing makes tdesktop more special than a regular browser to think or implement a different solution for such a simple task as this. The Web and Desktop apps currently get most data from the local storage on startup and don't discard it when you quit or log out, so there is no point to mislead users stating the otherwise; cloud clients synchronise the data with the local storage in most use cases. This means you shouldn't lose your secret chats at all because they should be stored on the local storage, in the same way as other desktop applications do. [My counter-argumentation]

A chaos of chats with the same person. If each chat only connects two devices, users get many different chats with the same person. Imagine two people that have a laptop, a desktop at work and a mobile device each. That’s 9 secret chats in total, and most of them are useless at any given moment. [Telegram team's argumentation]

This is not a problem at all because people who use Secret Chats on mobile devices have exactly same issues when changing their phones, so they are aware of that. Also people who use E2EE chats are mostly aware of how they work and should understand that encryption keys are always stored on the local storage. Again, this is how most other desktop apps worked for decades and making a "problem" of it seems to be a misleading and unprofessioal. [My counter-argumentation]

Search-related troubles. There’s an added twist when it comes to finding a certain message. Since no server-side search for messages is possible in the E2EE paradigm, the user would have to remember on their own where to look for a particular message (was it in this chat on this device, or in that chat on that device?). Telegram wouldn’t be able to help in any way. [Telegram team's argumentation]

It's possible to search messages in Secret Chats on mobile. E2EE paradigm use client-side search for messages and this is how search is supposed to work for Secret Chats. Users don't need Telegram's help for that, only the possibility to search messages locally, which is already implemented. [My counter-argumentation]

Temporary sessions. And if that wasn’t enough, desktop sessions tend to be a lot more transient. One of the important features of secret chats is that they are destroyed on your device when you log out. Most desktop users log out rather frequently. Telegram Web users do this even more often. [Telegram team's argumentation]

Desktop sessions work in a same way as mobile sessions. Secret chats are destroyed on your device when you log out and this is why they are secret, nothing wrong about it. Most desktop users don't log out frequently and there is a big lack of context in the original statement. Telegram Web users should know better why they use Web client, it's their own choice, however, all this is not a valid argument to not implement secret chats on Web client either, since web-browsers are even used to store cryptocurrency (Metamask and such), and there is no problem with that for people who are aware of security risks; there is no problem enlightning people on security risks associated with web-browsers usage, this is what Telegram team should do instead of writing lots of misleading reasons to not implement Secure Chats. [My counter-argumentation]

I understand that most regular users recklessly follow their misleading arguments because Durov positions himself as man of knowledge in programming, while he is not, and everything he has done so far was outsourcing programmers, not even mentioning how his brother Nikolai Durov coded everything for Pavel during startups and never continued to help him because of marketing oriented ideology of Pavel (I know this from Nikolay himself from the personal conversation with him some years ago).
But what's more disappointing, is that even young developers from Telegram open source team, such as anonymous guy john-preston do share this weird ideology, for some reason supporting everything written on their page explaining "Why are Secret Chats only available on their devices of origin".

Just look at this:

john-preston commented on Jun 23, 2020
@dm17 I say that PR with a secret chat option won't be merged because I can't imagine anyone to produce such PR in such quality that it could be merged. It is a very big task that will have changes in almost all of the application logic and a huge amount of UI changes that should be discussed with the designer of the current interface, so I just don't see any reason to discuss the PR of secret chats in tdesktop — no one will do it.

For example, multiple accounts support is a much easier feature and it has a much less UI integration and still no one PR-ed it (and no one will, but I hope to implement it some day).

See how many times this guy used the wording "no one", supposing that "no one will do it" and even if someone will, he won't merge it.
It seems that we are dealing with some amateur frontend coder who doesn't understand cryptography or has no experience with coding practical client/server applications with PKI and who is assuming that just because he doesn't know how it can be done, no one else does.
So, based on his logic, there are no programmers in the entire world who can code a simple client-side encryption.

I know that this guy has triggered skepticism from many experienced and knowledgeable people in this topic who instead of trying to prove him wrong, decided to not waste their time and just to leave Telegram. Some people even tried, but Durov often refute such stuff with well-marketed sophistry that results to work on his major part of the audience, since most of them don't have any knowledge in infosec and prefer believing what he says just because they trust him.

Another reason behind all this hesitance on this issue could be that they are afraid of letting too much users to have conversations out of their control, ensuring that they can provide users communications logs to the law enforcement when asked, since their normal "cloud" chats permit to do that easily. Actually, the increased amount of censorship in their platform lately indicates that it could be true.

Anyway, I am stopping to try finding only 1 coder for this task via non-efficient platforms such as Gitcoin (whose most important features stopped working completely and devs don't have any ETA to fix their stuff) because I think it's better if more people worked on this issue as supposed to be in the open source community.
I have asked to refund my funds from Gitcoin, which was done, and from now will watch the contributions made by particular devs to this issue. Once this task is complete, I will distribute my cryptofunds to each developer based on their amount of work, which will also allow others to donate to them. We could also try to launch the campaign on https://tallyco.in purposely for funding this issue.
My Ethereum address verification with the funds prepared for payout on this issue: https://etherscan.io/verifySig/4431

If you know how we can organize this better, please let's discuss it.

p.s.
@arch-btw he became inactive on this issue since the first week of his application

@basedcookie thanks for the feedback, and while I understand that this task may have looked challenging to you and this is normal even if your coding level is good - simply because encryption is rarely employed in C/C++ coding tasks, but I still believe it's a relatively easy task for programmers who have specific experience with coding encryption algorithms on C/C++. I also think that the lack of interest for this issue by people with experience in this field is caused by Telegram's shady policies on E2EE encryption, described by me earlier.

@marcovelon

@marcovelon - good eye!
Yes, I just think it is too difficult for them to get a well hidden and functional backdoor into the secret chat functionality on FOSS desktop. In this age of information warfare, I think it is lazy not to assume such things. If a Russian company can re-domicile as Emirati and then censor RT, way ahead of a war that ends up using Telegram as a primary information source on the opposing side... This is going to get complicated to analyze.
Of course I love Telegram - the engineering marvel - but intentions factor in when we have to spend years guessing about their insistence to avoid E2EE on FOSS desktop while mobile can afford two full implementations from scratch (Telegram and Telegram X)... It begs the context of mobile being more secure. Yes, phones are more secure - with respect to their own root-of-trust! Desktops - despite these black box operating systems running transparently with respect to the host OS called "management engines" - have still not removed root-of-trust from each user's control as effectively as mobile solutions (where the user is sandboxed away from having full permission and even ownership of their own hardware). The context of mobile being more secure is: mobile is a more secure and foolproof eavesdropping platform.

Just noticed this thread. Is the initiative currently active, stuck, or dead?

@sergiotarxz mentioned an issue regarding "self-employed taxes" - I'm sorry I haven't read the full 221 comments, but - Is this a bureaucratic issue? Lack of time due to personal matters? Are these extra expenses which weren't planned for and are making things financially unattractive for @sergiotarxz ? An update+explanation would be welcome.

Hi, I have to pay a large quantity of money for each month I am working in my own without being hired independently of if I get paid something or not and I cannot afford it anymore.

Hi, I have to pay a large quantity of money for each month I am working in my own without being hired independently of if I get paid something or not and I cannot afford it anymore.

My BS alarm is going off

In case you want to search I live in Spain.

…

On 16 July 2025 22:05:12 GMT+02:00, dm17 ***@***.***> wrote: dm17 left a comment (marcovelon/tdesktop#2) > Hi, I have to pay a large quantity of money for each month I am working in my own without being hired independently of if I get paid something or not and I cannot afford it anymore. My BS alarm is going off -- Reply to this email directly or view it on GitHub: #2 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

Maybe in some other moment I can do it, but what I need is a real job rn.

…

On 16 July 2025 22:05:12 GMT+02:00, dm17 ***@***.***> wrote: dm17 left a comment (marcovelon/tdesktop#2) > Hi, I have to pay a large quantity of money for each month I am working in my own without being hired independently of if I get paid something or not and I cannot afford it anymore. My BS alarm is going off -- Reply to this email directly or view it on GitHub: #2 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

This is a very interesting and important initiative. Thank you. However, it seems that the project has stalled after a fast start since, as progress has been slow after four years. Were Telegram programmers right about the complexity?
Is it possible that Telegram highly skilled programmers, who are paid around $1 million per year, are unable to do it? Or is it just an excuse because Durov does not want to do it?
Indeed, the fact that it is not possible to have a secret chat group with e2e encryption and cloud synchronization is another excuse from Durov from 2017 and is no longer valid today. As a counterexample, we can take Matrix/Element.

> This issue is a continuation of Secret chat telegramdesktop/tdesktop#871 and [Question] Any fork of tdesktop to support Secure Chats? Considering crowdfunding. telegramdesktop/tdesktop#16835 and is dedicated to the code bounty campaign related to lack of implementation of a Secret Chat feature (end-to-end encryption in private messages) in Telegram Desktop.

The objective is to implement the Secret Chats feature into this Telegram client: https://github.com/telegramdesktop/tdesktop

It is possible to do it with 3 different ways (but not limited to):

~~Migrating tdesktop to TDLib~~ / ~~Including TDLib to Telegram Desktop and using its Secret Chat API partly~~ comment from @lukejohnsonrp

Extracting the Secret Chats code from TDLib or telegram-api (https://github.com/vysheng/tg / https://github.com/vysheng/tgl) and reimplementing it into tdesktop

Reimplementing it from scratch based on the official public specification available here https://core.telegram.org/api/end-to-end and https://core.telegram.org/schema/end-to-end

Only protocol handlers need to be implemented, because all the cryptographic functions are already present in the Telegram Desktop (source)

This code bounty doesn't limit the programmer to any specific way of implementation, as soon as the final result will make possible to use Secret Chats on the open source Telegram Desktop (tdesktop) client on Linux and Windows in the exactly same way as it's done in mobile clients.

UPDATE 04/2022 / Funds distribution scheme:

There will be 3 payouts based on completion of the following stages:

[1/3] ~~Estabilishing Secret Chats via DH key exchange (ability to send and accept Secret Chat requests)~~ [COMPLETE] in sergiotarxz@41fcaa8

[2/3] ~~Ability to send and receive encrypted messages in estabilished Secret Chats~~ [COMPLETE] in sergiotarxz@41fcaa8

[3/3] Re-keying (PFS) and media sharing in Secret Chats

The developer(s) will receive 1 ETH for completing one of the stages from the list above, totalling 3 ETH for all stages. The source code should be available and compilable.

The adjacent functionality such as deleting and configuring Secret Chat options can be done during any phase of the work progress described in the list above, however it must be done before or with 3/3.

I have created a verified signature for my Ethereum address containing the funds for this issue: https://etherscan.io/verifySig/4431 (https://etherscan.io/address/0xd19ee4a49b9214c4c22694bb01f225baf35f6efc)

Any voluntary donations are welcome. You can send them to the address above.

My email for communication is marcovelon@protonmail.com

CURRENT PROJECT FUNDING:

The overall funding now is 13000 USDC and 1.18 ETH (~3929 USD)

Is it possible that Telegram highly skilled programmers, who are paid around $1 million per year, are unable to do it? Or is it just an excuse because Durov does not want to do it?

I'm sure many people besides Durov do not want telecommunications to be so easily secured; we can't reduce it to a person but it is obvious that a subversive power exists.
I hope this effort isn't dead, but its continued failure is inspiring me to look into what it would take to develop a FOSS telegram server, and add functionality to telegram clients such that they work normally with the official server. You could describe this as a cleverly designed option to add "federated" servers - but let's say "other" servers due to terminology baggage surrounding "federation." This would also solve the above problem as you can just invite people to join your own server when you want the additional security (or even E2EE, later perhaps). Lack of E2EE is mostly a server trust issue, after all. I figure this is the best thread to get feedback on this idea - so please critique away! Thanks to everyone involved for their continued interest in this!

@dm17

@dm17 : Do you really need a special server to establish E2EE? The two users could send unsecured info via the regular serverto help them establish a connection, plus public keys; would that not be enough?

@dm17 : Do you really need a special server to establish E2EE? The two users could send unsecured info via the regular serverto help them establish a connection, plus public keys; would that not be enough?

Of course not. But this would solve a lot more problems. The reason it could help solve the E2EE problem is because it removes a lot of need for it. But it could also allow one to create a more flexible negotiation protocol for E2EE that would not depend on Telegram (the company) at all. Please feel free to do whatever is easiest - but I believe the above idea solves a much wider set of problems.

Is it possible that Telegram highly skilled programmers, who are paid around $1 million per year, are unable to do it? Or is it just an excuse because Durov does not want to do it?

I'm sure many people besides Durov do not want telecommunications to be so easily secured; we can't reduce it to a person but it is obvious that a subversive power exists. I hope this effort isn't dead, but its continued failure is inspiring me to look into what it would take to develop a FOSS telegram server, and add functionality to telegram clients such that they work normally with the official server. You could describe this as a cleverly designed option to add "federated" servers - but let's say "other" servers due to terminology baggage surrounding "federation." This would also solve the above problem as you can just invite people to join your own server when you want the additional security (or even E2EE, later perhaps). Lack of E2EE is mostly a server trust issue, after all. I figure this is the best thread to get feedback on this idea - so please critique away! Thanks to everyone involved for their continued interest in this!

Unfortunately, Durov is opposed to releasing the server code as open source and therefore to server federation (he deleted his 2021 response, but it is still visible on the web). In addition, there are several feature requests related to open source (Publish the source code of Telegram servers under a free license) and server federation (Federation, Allow the connection to custom servers, Messaging Layer Security (MLS) support). Even just MLS support would be sufficient for true interoperability.
If you are looking for a decentralized or p2p alternative, there is Matrix with its flagship client Element, which is not only decentralised and has features comparable to Telegram, but is also e2ee and solves the TOFU problem of common messaging apps (WhatsApp, Signal, Wire, etc.) thanks to cross-signing.
So, there is no need to reinvent the wheel.

Unfortunately, Durov is opposed to releasing the server code as open source and therefore to server federation (he deleted his 2021 response, but it is still visible on the web). In addition, there are several feature requests related to open source (Publish the source code of Telegram servers under a free license) and server federation (Federation, Allow the connection to custom servers, Messaging Layer Security (MLS) support). Even just MLS support would be sufficient for true interoperability. If you are looking for a decentralized or p2p alternative, there is Matrix with its flagship client Element, which is not only decentralised and has features comparable to Telegram, but is also e2ee and solves the TOFU problem of common messaging apps (WhatsApp, Signal, Wire, etc.) thanks to cross-signing. So, there is no need to reinvent the wheel.

Matrix gets pushed so hard and is honestly the worst I've ever used. I'm sure everyone in here is familiar with those so I don't get the need to do another promo... Your comment about this being "reinvent[ing] the wheel" does not seem to apply at all.

Regarding their refusal to release the server code - that is fine. People have written open source telegram servers that work well with existing clients: https://github.com/loyldg/mytelegram
Therefore, I think the above idea is totally feasible.

While I agree matrix is not the silver bullet as advertised, writing a selfhosted telegram server seems to be more complicated than client side E2E implementation.

If we cannot even make E2E work, there is very little confidence in me to believe that the server would work.

Matrix gets pushed so hard and is honestly the worst I've ever used. I'm sure everyone in here is familiar with those so I don't get the need to do another promo... Your comment about this being "reinvent[ing] the wheel" does not seem to apply at all.

Can you tell me exactly where it is being promoted so much? I have only seen Signal being marketed. Matrix is the only truly decentralised solution we have. I agree that in terms of speed, usability and functionality, it is inferior to Telegram and even WhatsApp, but I also think you have never tried it: 90% of the main features are there and work well.

Regarding their refusal to release the server code - that is fine. People have written open source telegram servers that work well with existing clients: https://github.com/loyldg/mytelegram Therefore, I think the above idea is totally feasible.

I didn't know about this project. I looked into it and noticed some interesting things:

The project has 88 users on its Telegram channel and 155 stars on Github. LoL :)
The open source feature are very limited, the most important ones are in the pro version. Is it a paid version?
There are two contributors that forked all the Telegram repositories. Telegram desktop is 366 commits behind the official version and 23 commits ahead. Truly trustworthy. LoL

Good luck :)

I’ve noticed that the domain tdesktop.fail hasn’t been renewed (the site is still viewable on the wayback machine). Can we assume that the project has been abandoned?

I’ve noticed that the domain tdesktop.fail hasn’t been renewed (the site is still viewable on the wayback machine). Can we assume that the project has been abandoned?

Would be nice if we could contact the owner so we can take it over if domain price / upkeep is an issue.

Navigation Menu

Repository navigation

[Feature Request] Secret Chats in Telegram Desktop #2

UPDATE 04/2022 / Funds distribution scheme:

233 remaining items

UPDATE 04/2022 / Funds distribution scheme:

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

[Feature Request] Secret Chats in Telegram Desktop #2

Description

UPDATE 04/2022 / Funds distribution scheme:

Activity

marcovelon commented on Aug 23, 2021

OMTDesign commented on Aug 28, 2021

basedcookie commented on Sep 28, 2021

arch-btw commented on Oct 26, 2021

marcovelon commented on Dec 23, 2021

amritkumarj commented on Jan 6, 2022

OMTDesign commented on Jan 6, 2022

amritkumarj commented on Jan 6, 2022

arch-btw commented on Mar 11, 2022

basedcookie commented on Mar 15, 2022

marcovelon commented on Mar 15, 2022

dm17 commented on Mar 15, 2022

233 remaining items

sergiotarxz commented on Jul 16, 2025

dm17 commented on Jul 16, 2025

sergiotarxz commented on Jul 16, 2025

sergiotarxz commented on Jul 16, 2025

alfredonodo commented on Aug 23, 2025

aqbalmradyan9 commented on Oct 21, 2025

UPDATE 04/2022 / Funds distribution scheme:

dm17 commented on Dec 5, 2025

eyalroz commented on Dec 5, 2025

dm17 commented on Dec 5, 2025

alfredonodo commented on Dec 6, 2025

dm17 commented on Dec 7, 2025

christaikobo commented on Dec 7, 2025

alfredonodo commented on Dec 7, 2025

alfredonodo commented on Jun 14, 2026

dm17 commented on Jun 14, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions