Brooklyn 0.1 is out there: full Telegram and IRC support

I'm glad to announce that a first stable version of Brooklyn is released!
What's new? Well:
  • Telegram and IRC APIs are fully supported;
  •  it manages attachments (even Telegram's video notes), also on text-only protocols through a web server;
  • it has an anti-flood feature on IRC (e.g. it doesn't notify other channels if an user logs out without writing any message). For this I've to say "thank you" to Cristian Baldi, a W2L developer which has this fabulous idea;
  • it provides support for edited messages;
  • SASL login mechanism is implemented;
  • map locations are supported through OpenStreetMap
  • you can see a list of other channels' members typing "botName users" on IRC or using "/users" command on Telegram;
  • if someone writes a private message to the bot instead of in a public channel, it sends him the license message "This software is released under the GNU AGPL license.";
As you may have already noticed, after talking with my mentor I decided to modify the GSOC timeline.We decided to wait until Rocket.Chat REST APIs will be more stable and in the meantime to provide a full-working IRC/Telegram bridge.
This helped me providing a more stable and useful software for the first evaluation.
We are also considering writing a custom wrapper for the REST APIs because current solutions don't fits our needs.

The last post reached over 600 people and that's awesome!
As always I will appreciate every single suggestion.
Have you tried the application? Do you have any plans to do so? Tell me everything in the comments section down below!


  1. Would have definitively tried it if it was not done in Java :(

    1. Agree.. Why Java? :'(

    2. What's wrong with java?

    3. Hi. Java is the best choice for this project.
      We should (I've to do that too) stop focusing on languages wars and more on choosing the right language for the right project.
      Everytime someone creates a project in X there is always someone else arguing that X is not a good language.
      Give it a try and tell me what's wrong :)

  2. I think that the concerns about using Java comes from th fact that it's not directly usable from c++. It could be ok in client server app where the UI is a separated process and thus written in a different language. But to be honest this is not always the case for KDE apps that are written in c++ and use Qt.

    1. This project is just meant to run on a server, so I think the programming language doesn't really matter, does it?

  3. If it is used server side or in a server process than it doesn't matter much which language is used (even if this can slow the adoption and reuse of other KDE API or components). But i think that your KDE mentor already considered this

    1. Hi. It is used server side, please read what Brooklyn is:)
      There are no reasons to wrap it in another application, it's not a component nor a GUI application ^^

  4. Interesting project

    One possible problem is the name, Brooklyn is an Apache project for doing cloud management. They might get annoyed at the clash and so might anyone deploying them.

  5. How easy is it too add other protocols, like Gitter and Signal?

    1. Hi! It is modular, you've only to create a class that implements bots.Bot interface!
      Feel free to look at the source code (e.g. RocketChatBot which is easy to read).
      I don't know how Gitter and Signal APIs are designed, but I don't think you have to put too much effort to implement it.


Posta un commento

Post popolari in questo blog

Stop writing code like we're in the '90s: a practical approach (PART I)