Hacker News new | comments | show | ask | jobs | submit login
Telegram Bot Platform (telegram.org)
261 points by thiagoperes on June 24, 2015 | hide | past | web | favorite | 90 comments



Just yesterday I was trying to get a bot working on the TextSecure platform. A vastly disappointing experience: almost not existing libraries, sparse and incomplete documentation, unstable protocol breaking without any kind of notice (https://github.com/JavaJens/TextSecure/issues/6, for example). And still no way to register without a phone, which would be amazing for this kind of project: https://github.com/WhisperSystems/TextSecure/issues/1085

I think Telegram is succeeding in what TextSecure is failing: attracting a widespread community of developers. This is only a confirmation, in my opinion.

EDIT: and, by the way, while Telegram security is no good, I wonder why we cannot have both (security & developer-friendliness)


Try using libtextsecure instead of interacting with websockets directly. We publish artifacts, and while the API might change over time, if you stick with a versioned artifact you'll be good. http://open-whisper-systems.readme.io/v1.0/docs/textsecure-j...

We have a few bots in production that use libtextsecure and have been running fine for almost a year without any maintenance.


Last year I wanted to help out with the TextSecure browser (chrome extension) project and had a similar experience as the OP.

I was a bit at loss about where to begin, as I couldn't find documentation about getting the extension setup for dev/testing. Specifically I couldn't get past the QR-code auth screen as I seemed to be missing some special configuration to connect with the servers.

I just assumed it wasn't really ready for outside devs yet.

But I just checked back in on the repo and it looks like a new CONTRIBUTING doc has been added, which is great: https://github.com/WhisperSystems/TextSecure-Browser/blob/ma... This is the type of stuff I was looking for.

I'm happy to see WhisperSystems making contributing more accessible. I probably could have learned this stuff by asking the devs, but I didn't want to bother them, I much prefer reading docs and playing with it myself first.


Thank you for your answer and for your time.

My language of choice for the bot was Clojure. I was interfacing with libaxolotl-java and basically rebuilding libtextsecure in Clojure (that was months ago).

Yesterday, when I discovered libtextsecure-java (while exploring Github repositories, by the way, I didn't notice your website had been updated in the meantime), I started a rewrite, using README as my primary source of documentation (the only piece of doc I could find, actually).

Ok, so what's this `KeyHelper`? Ok, I'll search on Github. Fine, it's actually `org.whispersystems.libaxolotl.util.KeyHelper` - luckily I knew it was in a completely different project. The same goes for `AxolotlStore`, which is actually `org.whispersystems.libaxolotl.state.AxolotlStore`, and it's not even mentioned on libaxolotl-java README because the latter is outdated.

Then: what is `TrustStore`? Good luck finding out that! Basically it is a wrapper around a binary file - which I had to download from TextSecure source repo without knowing what there was inside, and which by the way is encrypted with the password whisper (documentation: nowhere - thank you @AsamK for your textsecure-cli sources on github).

Ok, and finally figuring out - turning to TextSecure-Server docs - what is a signaling key, what are the specifics for the client-generated password (which by the way is sent over SSL via Basic authentication - probably not the most secure method ever, but probably there are many reason for that) and what is an install ID, I finally had the opportunity to debug obscure security problems on Java and to meet in person a Fedora bug https://bugzilla.redhat.com/show_bug.cgi?id=1167153). Not to mention the fact that apparently libtextsecure-java doesn't work over websockets but only over GCM (https://github.com/WhisperSystems/libtextsecure-java/pull/5) - however I won't be surprised if it did.

A really nightmarish experience. Maybe this summer I'll try to reimplement libtextsecure in another language and then document thoroughly my efforts. Who knows.


Any chance of providing an api that is more friendly to be used from other languages? Java is not the easiest thing to work with.

Also, does this library work on other systems besides android? I've noticed `android` appearing multiple places and google specific api (`GoogleCloudMessaging`).


I'm using Cyanogenmod and I wanted to try TextSecure. There is a version for SMS pre-installed, but I'm not a fan of paying money for 128 bytes of data.

I don't have any Google Services installed.

So I tried finding it on F-Droid, but it wasn't there. I found out there has been a lot of discussion about this. [0][1]

I decided to compile it on my own. That requires to use use Google Libraries, oh well. I managed to get that done and was disappointed when I tried to use it. It also requires to have Google Services installed on your phone for push notifications. I don't have that.

I tried finding a solution, and other people complained about this and there was the idea to use websockets instead of google push notifications [3]. Someone forked TextSecure and started working on it [4].

Unfortunately that fork isn't stable yet, and it doesn't communicate with 'producion' users of TextSecure [5].

This is where I gave up. It shouldn't be so hard to install a free app on a free system.

Also, the websocket fork is somewhat dead [6].

0: https://f-droid.org/posts/security-notice-textsecure/

1: https://github.com/WhisperSystems/TextSecure/issues/127

3: https://github.com/WhisperSystems/TextSecure/issues/1000

4: https://github.com/JavaJens/TextSecure

5: https://github.com/JavaJens/TextSecure/issues/10

6: https://github.com/JavaJens/TextSecure/issues/15


I had the same experience. I am using CyanogenMod as well and as much as I dislike Google I did install the Play services. I can't even remember why but I think I needed it to use the google voice app.

Anyway, google play apparently tried to auto-update and bricked itself; now it just says "no connection" when I launch the play store.

Last week I tried to install TestSecure but it would not run. It just gave an error message about needing to update play services.

I ended up installing the Telegram app in F-Droid.


I've had Play Services brick itself a few times, but uninstalling all updates tends to fix it.


After all that effort, do you regret not just buying it?


What are you saying the comment parent should have bought? TextSecure is free-libre-open-source software, it isn't sold anywhere. It depends on the Google Play Services, and cannot be run effectively if the framework is not installed on the device.


> There is a version for SMS pre-installed, but I'm not a fan of paying money for 128 bytes of data.

I think I misread this as saying there was a paid-for version available for install, but I have no idea how I got that, since it's clear that it's the SMS charge he doesn't want to pay for.


My TextSecure Golang package has a command line client with a simple echo-bot mode included. While the API is far from finished or very clean, it can be used for making simple bots.

https://github.com/janimo/textsecure


I briefly looked at Telegram's crypto code a couple months ago. Here's a few funny things I spotted:

Telegram's message format uses ambiguous padding, so they have to try all padding lengths when validating a message: https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/...

That loop leaks timing information, as does the "Utilities.arraysEquals" method it uses. I'm not sure if it opens up a timing attack, but it's suspect: https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/...

There is another spot where they pad with zero bytes without any authentication. This may leave room to mess with the protocol: https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/...

There are also some weird things throughout the code, like using SecureRandom.nextDouble() all over: https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/... https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/...


What does leaking timing information mean?


Nate Lawson has a good explanation of timing attacks (against my own code): http://rdist.root.org/2009/05/28/timing-attack-in-google-key...


Response timing can be indicative of the key, especially if you have the crypto algorithm's code (source/IR/machine code).


I've beeing developing this https://github.com/yagop/telegram-bot for a year. Currently most Telegram Bots uses my proyect for building bots.

Now it's deprecated and I'm really sad about that.


Hey! I found your work really useful. Thanks very much for your effort :) I look forward to your next project!


I'm really sorry about that.

telegram-bot and tg are great projects. Rest assured, many people (including myself) appreciate all your hard work.


thank you for the effort.


I was one of the users of your bot! Thanks for all that you did.


OT:

Awesome, great, APIs are good.

Know what's better? Open specifications and federated services. It's called XMPP and if it's not enough, then something better should be developed.

Is this the replacement of SMS? Not sure what people would have thought at the time if they could not send SMS to other mobile carriers. It saddens me even more to see public institutions moving their SMS infrastructure to the new 'carriers'.

Protocols are not a new thing. Let's not go back to the time were computers could not talk to each other.


Anecdote:

In our company, we recently switched from Jabber to Telegram.

Telegram is easier to use on multiple devices (it synchronized automatically and you don't have to worry that if you leave one device open, you won't get the message elsewhere), has both a usable mobile app and a usable web/desktop app, it has the "private" chat that's much easier to use than OTR (Pidgin, Gadjim and Adium each implement OTR differntly and it never works right cross-client), and, as one co-worker noted, it finally looks like something from 21st century.

TextSecure/Signal/what's the name now has - in addition to confusing branding cross-OS - strange SMS reliance and no working desktop app. I would prefer it to Telegram though, if they had some reliable destop application, but they don't.


That's why we should be worried. The ease of using Telegram over any other service is clear and that's why most companies and public institutions are moving their old messaging services to Telegram. Without wanting to say that Telegram's job is easy (it's not), it's too easy to run a centralized service and make it easy to use.

Of course companies should use whatever is most cost effective to run their private communications. But when running a public communication channel restricting to a centralized service should not be an option.


I get it. And we actually did try to use Jabber for a long while.

But the moment we tried Telegram, we just didn't want to move back.


As some sort of an XMPP fan and a Telegram user:

Multiple devices should be a non-issue today, really. Usable web and desktop apps is quite subjective, I think? I do admit that the Telegram desktop app looks slick.

The OTR problems seem weird, because as far as I'm aware Pidgin and Adium share the very same implementation for example?

It sounds like you were mostly unlucky to me. On the other hand: Maybe that's already another blow against XMPP, if it doesn't "just work".

I would love to get your coworkers feedback on something like this [1] - because 'looks like something from the 21st century' is not something I get immediately.

1: https://play.google.com/store/apps/details?id=eu.siacs.conve...


> 'looks like something from the 21st century' is not something I get > immediately. > 1: https://play.google.com/store/apps/details?id=eu.siacs.conve....

I'll bite. If i would be a non-techie the things i would notice are:

* What's Jabber / XMPP? I don't know what that is. Why should it be in the title?

* All the screenshots (there are many!) basically look the same. I don't understand the conversations in the screenshots.

* It's not free.

* The first line "Conversations is an open source Jabber/XMPP client for Android 4.0+ smart phones.". What's open source? What's Jabber/XMPP? What's a 'client'? The only words i understand in this sentence are 'Android' and 'smart phone'.

* "Design principles" is not something i care about. Simply tell me what this product does.

* Clicking on 'Read more' gives me a text that is so technical i don't understand a single word of it ("XEP-0065: SOCKS5 Bytestreams - or rather mod_proxy65"?)


Hmm.. I was talking about the UI (I think that's a rather pretty client, comparable to the current WhatsApp/Telegram/whatever thing).

Again, comparing to Telegram [1] (see disclaimer in my previous post: I use that as well):

* Jabber/XMPP is a weird point. You wouldn't need Conversations if you wouldn't have a server to use. You pick up Conversations because a) some friend tells you to install it and connect it to their server or b) you have a server of your own. If you don't know what XMPP is, then yes - this client is not for you.

* Really? Can you look at the Telegram screenshots? Let me bite this time:

Hey Lucy, got a second?

As in the duration of 551557906200 periods of the radiation corresponding between the two superfine levels of the ground state of the caesium 133 atoms? Yes, I might.

We need some data extracted from a secret chat…

* It's free. [2, GPL] I know, Joe User isn't going to build it, but again: You need a server for this to work. If you care about that, I'd say you have ways to save the 2.38 EUR if necessary.

The rest of your points are certainly valid (marketing for XMPP sucks), but again entirely different problems. I highly doubt that most people read the description of the Telegram or WhatsApp apps. Friends recommend it, people install it, use it, done. XMPP is a different case, because it requires a friendly server (and the post installation configuration step where you select one), but that's not quite relevant for the 'looks like something from the 21st century' discussion, is it?

I was trying to make the point that there are ~new~ and current clients for XMPP as well, even if Pidgin looks like shit.

1: https://play.google.com/store/apps/details?id=org.telegram.m...

2: https://github.com/siacs/Conversations


> Telegram is easier to use on multiple devices (it synchronized automatically and you don't have to worry that if you leave one device open, you won't get the message elsewhere)[...]

XMPP supports this, but regrettably, almost no clients implement these features. It's a huge shame that so many dev create brand new protocols+clients instead of implementing these features for existing XMPP clients. But I do admit that as-is, users can't pick up any existing XMPP client that supports this. :(

> OTR (Pidgin, Gadjim and Adium each implement OTR differently

I've been using this daily for a few years now. I've always used pidgin, while almost none of my peers have. OTR is also standard, so I'm really not sure what you're talking about.


TextSecure SMS is getting phased out.

https://whispersystems.org/blog/goodbye-encrypted-sms/


Oh ok. My phone is still annoying me with it, it still wants to use TextSecure for SMS for some reason, which is really confusing.


Encrypted SMS is, but the Android app will (apparently) continue to support unencrypted SMS.


This is why I switched to SMSSecure. It's a TextSecure fork that continues to support encrypted SMS direct to the phone and not through a server of any kind.


Telegram has an open specification, called MTProto. I guess XMPP wasn't good enough, so they DID develop something "better" (better for this specific use case).

Also federated services have their disadvantages, so I wouldn't necessarily say that's better.


The only disadvantages I can see on a federated service are security and the cost of running it.

Compared to the benefit of not restricting one-self to a platform, I would say federated is better.


It's also technically more challenging.


> Open specifications and federated services. It's called XMPP and if it's not enough, then something better should be developed.

Matrix project is an interesting effort to replace XMPP: http://matrix.org/


I got to know the Matrix project on the last FOSDEM and it definitely seemed a step on the right direction.

I guess then it's all a matter of waiting for it to happen.


> Not sure what people would have thought at the time if they could not send SMS to other mobile carriers.

Then you would have loved Japan before 2006. SMS was not a "thing" (although available hidden in the interface) and the phones would default to email.


You're right, of course. Unfortunately, the trend right now doesn't seem to be open protocols. Until the pendulum swings back again, i'd like to think that i'm beter off with a platform that isn't being run by Facebook.


That is true.

What surprises me is how lazy and clueless mobile network operators seem to be despite the power they still hold. They have all the power they need to develop or implement modern messaging protocols. Granted they can't charge for it. Still seems a better option than pushing SMS, MMS and letting new players enter their yard.

I am all up for letting mobile network operators just provide internet services. Surely the trend seems to be to flush everything down the Internet tubes and if that's the future, we need something better than a couple of companies that do not respect free choice.


> They have all the power they need to develop or implement modern messaging protocols. Granted they can't charge for it

And they do, at least here in europe: https://gigaom.com/2014/02/20/oranges-libon-messaging-app-le...


This is nice, but I really wonder why they don't focus on more important things. For example this issue I opened over a year ago, asking them to use end-to-end encryption by default and for group chats: https://github.com/DrKLO/Telegram/issues/156

Probably because features are more important than security, sigh.


I second that notion. It comes down to priorities and right now bots > security.


It's not that easy: How would you exchange the private keys when using multiple clients? This would require to user to transfer the private key files or to remember a secure password. Both options aren't possible for usability reasons if you want to beat WhatsApp.


This has been discussed a lot in the issue thread. Key exchange really isn't the issue.

Scanning a QR code or creating a secure connection between the clients to exchange the keys isn't that hard.


What when I want to login at a computer but don't have my phone with me?


Same as using 1Password — you don't.

You're trading convenience for increased security.


This is why it isn't 'by default'.


End-to-end encryption by default kills one of the advantages of Telegram - crossplatform history synchronisation.


this shouldn't be an issue when the clients share the private key.


> Telegram is about freedom and openness – our code is open for everyone, as is our API.

Open for usage I guess. It's a pity that the API (and server) source is still closed. The Bot Platform is a cool initiative anyways, so good luck!


Not only for usage. The protocol is open and the clients are GPLv3.


Telegram is not truly open source. They utilize a pre-compiled library for the actual messaging code, as seen here:

https://github.com/DrKLO/Telegram/tree/master/TMessagesProj/...

They would like to have you believe otherwise through their PR efforts, but I wouldn't trust them simply on the fact that they claim they are open source when they are not, and it's not clear what's going on in that binary lib. If they never claimed to be open source in the first place, it would be a different story.


Ehm, the "jni/" directory contains the source for those files. Running "ndk-build" (from Android NDK) in top-level dir will recompile them.

Looking at the source the libraries contain AES code, libjpeg, libwebp and libyuv to handle image decoding, some image blur algorithms and video NV21-YUV conversion routines.

Nothing out of the ordinary for an Android app - offloading CPU intensive stuff to C/C++ where it's almost always noticably slower.

Can you please, PLEASE, check your facts before jumping the gun next time?


I retract my statement. This used to be the case, but appears to no longer be so.


> Telegram is not truly open source.

Here's Telegram FAQ [0]

    Q: Why not open source everything?
    All code will be released eventually. We started with the     
    most useful parts — a well-documented API that allows developers to build new Telegram apps, and open source clients that can be verified by security specialists.
[0] https://telegram.org/faq#q-why-not-open-source-everything


Didn't see that part of the faq... it would be great if they had an ETA.


There is Telegram-FOSS [0]. I believe they have removed the binaries. It's also the version you can find on F-Droid.

Edit: Also, the maintainer of the Android app is making all his changes locally and then submits all of them in one giant commit. There are pull requests, but he just includes these in his giant commits.

People do have complained about this [1][2], but he obviously doesn't (want to) understand git.

0: https://github.com/slp/Telegram-FOSS/issues

1: https://github.com/DrKLO/Telegram/pull/76

2: https://github.com/DrKLO/Telegram/issues/1007


The telegram client is open source. But the server side isn't. At least that's what i gathered last time I read about it.


Why is there a binary blob in their Android repo, and what does it do? Is it just compiled open-source Telegram code?


Looking at it, the libs/arch/.so files are just compiled JNI/NDK libraries compiled from source of jni/* files (that's completely standard for native code on Android). Usually the compiled libs aren't checked into the source control though.

Taking my paranoid glasses off, I'd guess they're checked in so contributors don't have to deal with setting up NDK to compile the app.


wait what

What's in this thing? This isn't just some build optimization thing they're doing? Nobody's picked it apart yet?


I believe this an amazing move by Telegram. I firmly believe that open platforms tend to win in the long run.

Whatsapp should take the hint and open up their platform for developers... Curiously I was thinking about building bot-based services on their platform (largest user base in my country), but basically gave up after seing how closed they are to any initiative like this. Felt even worse after reading things like this: https://twitter.com/gcmartinelli/status/605776036358291456


http://www.whatshash.com/ Someone built whatsapp bot! I dont know if they used some official api or what.


Thanks for the reference! I've seen some implementations (https://github.com/asdofindia/python-whatsapp-bot) but usually Whatsapp bans accounts that do it.


Telegram is really cool. I have long thought about what additions and modifications I could make to my mobile texting program. Now I have to convince all my friends to move from Whatsapp.


Great news ! Check out Github bot for sure people . I am already in love ! This feature is making me remember my own simple telegram bot that helped me to convey 1000 Happy birthdays to my friend in 15 mins. https://gist.github.com/scriptnull/7877b404f33de2b7445a


Your friend sure appreciated that...


yeah ! He was surprised and so were my other friends.


I woke up one night with the idea that if WhatsApp allowed API integration, it would so awesome : you could message DHL or UPS with your waybill tracking number, and they could push updates to you.

More interestingly, the WhatsApp text box then effectively becomes a REPL shell to a remote API : you could ask for stopping updates, updates only once a day, etc; If the remote server implements a DSL, you could do a LOT.

The possibilities were endless and exciting.

But I have a feeling WhatsApp / their new owner are going to just let the opportunity pass by. If anyone at FB is reading this : guys, Business integration with WhatsApp is where the next $250 billion is. That's how FB will get a permanent, maybe even irreversible, grip on mobile. Imagine every service business providing updates via WhatsApp by integrating with their backend.


They did announce plans for B2C use cases earlier this year (and of course are already used for conducting business, but only for communicating with a human on the other end


All the comments on this news item made me really want to try this out and see how it works.

I downloaded and installed the desktop version. Created an account with my phone number (okay: if I ever lose my phone, I'll permanently lose access to my account!).

I see how to add contacts. I need their phone number. I don't know my friend's numbers. We use facebook, xmpp, email, lots of shit, but nobody still relies on SMS nowadays, and my phonebook is literally under 10 entries long (and I'm sure mum and dad won't be using Telegram).

This reliance on old networks really kills it for me. IMHO, linking an account to a device that can get stolen or lost is also something I'll never really understand.


Telegram is the company that ignores proven crypto standards, rolls their own crypto without any verification or audit, then offers a $200k bounty to "break" their crypto by requiring developers to work with an arm tied behind their back by reducing the types of attacks that could be made in the real world.

Seems MTProto is the same as its always been

https://news.ycombinator.com/item?id=6931457

http://www.cryptofails.com/post/70546720222/telegrams-crypta...



Not found There is no Telegram account with the username you provided.


I really like that they embrace HATEOAS, e.g., "what can this bot do?", even though the API might not be strictly RESTful (they call it an "HTTP-based interface").


Can telegram be considered safe? I looked at eff's guide to secure chat earlier today and was quite confused that it seeming,y scores full marks and not-full marks.

https://www.eff.org/secure-messaging-scorecard


I've always been surprised something like this never really got going. I think the issue here is that it needs to be on message platforms that people actually use (iMessage, WhatsApp, Gchat, etc). Is it really not possible to hook in to those platforms?


The moment you hook into those systems, you're segmenting your userbase. If you rely on iMessage for transport, you can only talk to Apple users. The situation is similar with Hangouts and WhatsApp - while you're not limited to one device manufacturer, there's no official API, and any attempt to do so is a hack that could break at any time with no warning.

Telegram is slightly better in that it at least has a client API, but you're still locked to a single provider (the official Telegram server).


And that provider is a tiny fraction the size of iMessage, GChat, WhatsApp, et al.


telegram is getting pretty popular around here. To the point where people you meet ask you for your telegram without explaining what telegram is


Me and 2 friends decided to get rid of WhatsApp. We told our friends to get Telegram and left the group chats altogether. They joined Telegram that same day.

I guess it's not that simple when you're alone, but getting people to switch with a few people is fairly simple.


Create you own bot with Node.js! https://github.com/orzFly/node-telegram-bot


I made a simple bot plugins based in Node.js. https://github.com/dlion/smagenBot


I'm guessing this was inspired by IRC eggdrop bots? Seem awfully similar, just different comms mechanism


I don't have any experience with Telegram. Can anyone share how it compares with Slack?


They have completely different goals, Telegram is a competitor to SMS/WhatsApp, not Slack/IRC.


This is great, nice work guys


PingBot for server health monitoring anyone? or we'll just spam chats with Elisa clones?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: