Ok guys, so here's the deal.
Wrapping Telegram Desktop for Web in the plugin API was a rather trivial process.
Once I fixed the issue with the plugin API in general it took all of about an hour to get Telegram's web client integrated.
In the course of doing so I uncovered problems.
Secondly the CSS from telegram literally stomps all over the NRS CSS so I had to strip that out completely. The UI needs a lot of help without it's CSS, but that can be fixed by walking the CSS line at a time and sorting out which ones are really causing the problem. Hopefully it's only one or two.
Unfortunately, Telegram uses it's own custom encryption library.
This encryption library as well as several others exist in the global name space and are overridding the ones provided by NRS.
This CAN be fixed via namespacing. Basically I go in and find the conflicting functions and rename them, then go through and find every place that the old function was called, updating it to the new name. It's complex, but mostly just time consuming, but I've faced worse.
Here's my problem though and why I'm bringing it to your attention. In order to do this integration I had to do a deep dive into the code.
What I found just kind of shocked me. Yes it works, but it's doing a lot of dangerous things.
Let me stress. These things are not very dangerous if it's just you and a buddy having a chat. But if your buddy sends you a specially formed message it would compromise your wallet. If I remove that, then other pieces of this house of cards begin to fall down.
As soon as I saw that, I stepped back for a bit to think and do some research. I'm a programmer, but it's not the main thrust of what I do professionally.
Mainly I analyze things, poke holes in them, find ways around things. In short I try to find ways to make things happen. I had never heard of telegram before this, but I took the bounty because it seemed like something nice I could do for the community. The community believes it's secure, so I let that drive my opinion. Then I saw the code and I have to be honest, there just isn't any way I can think of to secure this.
I'm hardly alone in my opinion...https://yalantis.com/blog/whats-wrong-telegram-open-api/
I agree with everything that guy says and he's only refering to the android version, I'd take it a step further.
Once I realized that their code was insecure I decided it might be a good idea to go back to the API docs and build my own implementation from scratch.
Maybe that could allow me to deliver on this.
Unfortunately, the API docs are written in such a way that you can't just read them and do an implementation. It's a form of obfuscation. They make it look like they've provided useful and important information, but it's not in a format that is designed for building a new implementation.
Interestingly, the bot API looks fine. https://core.telegram.org/bots/api#making-requests
That could be wrapped, but it's not really designed for a desktop chat, it's meant for remote control purposes.
The regular "core" API docs look like this...https://core.telegram.org/method/users.getFullUser
What this does is define a custom binary protocol and the specification of that protocol is done in their own custom language.
Normally when you're specifying a binary protocol you specify it in c or protobuf syntax, these are considered standard.
The binary protocol makes a sort of sense, the amount of data you can send out via mobile push is limited, so they probably tried to accommodate that.
The normal way to do push messaging is to keep it very simple... You have X new messages and then have the app pull in the rest of the details off the server.
Because they diverged so much from best practices, Telegram really went lone wolf and the way they did it feels to me like they are intentionally obfuscating it. There are two reasons I can think of for doing that. Firstly maybe they don't want independent implementations. It's more money in their pocket if they can charge a consulting fee. I can respect that, but I'm not paying these guys after reading the code they did publish. Secondly, it could just be a mindset. If people feel like they can see the code, even though it might be out of their league, then they'll feel comfortable, in the meantime you can hide bugs and flaws behind a wall of impenetrable syntax.
There's a saying about this... "If you can't dazzle them with brilliance then baffle them with BS".
I read the docs, then I read the spec of the language they created to specify the api. I have to be perfectly honest here, it just feels like an attempt at obfuscation in hopes of a paying gig. It looks professional to a layman, but to a professional it looks like they're hiding something bad.
Understand I'm not saying they actually have a backdoor. I'm simply saying that if I were going to hide one, this is one way I could think of to do it.
I presented this information to MrCluster and Damelon. Between the two of them they have paid for over half the bounty, but then I realized that others in this community have paid into the bounty as well so I asked to bring it here for everyone to talk about. MrCluster agreed, but Damelon was offline, nevertheless this seems like the type of thing he would support.
Here's the rules. I will never knowingly release buggy or insecure code to any client. Whether it's open source or paid, if it has my name attached to it it doesn't leave my desk until I feel certain it can't be exploited. I cannot guarantee that with any option involving Telegram.
However the bounty is for a Telegram plugin. So here's the potential solutions.
#1 I could namespace what I've got here, fix what I can and release it under a best effort basis. The plugin would be limited to signin and check/send message functionality and I can bring in the contacts to make a sort of buddy list. This would be moderately secure, but the thing is built like a house of cards, touch one thing and it can come crashing down on you. I cannot guarantee security.
#2 I could toss the work done so far and implement the bot API from Telegram. This is enormously more secure because it's a from scratch rewrite and doesn't have the house of cards effect. The drawback is that much of the desktop functionality is missing. Bot API is intended more for remote control style operations. Chat can be done, but it's clunky and heavy. Functionality would be limited to these methods... https://core.telegram.org/bots/api#available-methods
and you'll need to get your own bot key https://core.telegram.org/bots/api#authorizing-your-bot
#4 We could forget Telegram and slack and go with pubnub. This would allow rapid signalling and messaging. Essentially chat, remote control and things like balance updates coming into your phone. I would ONLY be implementing basic chat and a buddy list, but the code is easy, open and extensible. The drawback is that with PubNub you have to pay beyond a certain number of messages a month and it requires signing up for an API key with a credit card. Also two people on separate API keys would be in segregated channels. I use pubnub for communications between cash machines and backoffice services, I've found it to be highly reliable and secure, but for who knows how many users to send pictures of their cats I dunno if it would be appropriate. We could get choked off.
In the interests of full disclosure, you should know that when I presented this information to Damelon & Mr Cluster I also presented a 5th option. This option is to implement a high speed message passing api over the existing peer to peer network that we already have with NXT. I called this solution NXT2NXT
It would be a sidechannel communications mechanism and would be using the addons API to open a couple of new ports. I based the design on a retail inventory and point of sale system I architected a few years back that updated inventory levels in near real time even if there were internet connectivity issues. However looking at the addons API, I think it's a whole separate project. So I'm backing off that one for now.
If we used the slack API for chat and instant messaging, we could revisit NXT2NXT at a later date. The telegram bot API is also somewhat similar but something about Telegram is giving me pause for concern. However the Telegram Bot API would meet requirements best...
Hopefully we will use the Arbitrary Message system as certified e-mail (https://www.youtube.com/watch?v=ycPv0eFJw-k) and Telegram as instant messaging app.
Much better than any other option.
So I'm going to leave the way forward up to the community on this. Damelon, MrCluster and abctc will have final say, but I'm interested in all thoughts from the community.