Opened 3 years ago

Last modified 7 weeks ago

#22011 assigned enhancement

Implement telegram bot for gettor

Reported by: hellais Owned by: alwayslivid
Priority: Low Milestone:
Component: Applications/GetTor Version:
Severity: Normal Keywords:
Cc: ilv, cohosh Actual Points:
Parent ID: #28231 Points:
Reviewer: Sponsor:

Description

Somebody on twitter suggested we add a telegram bot for gettor: https://twitter.com/DarthJahus/status/855040650831462400.

I see this also being something useful for bridges.tpo.

Originally reported here: https://github.com/TheTorProject/gettor/issues/18

Child Tickets

Change History (10)

comment:1 Changed 3 years ago by ilv

Priority: MediumLow

comment:2 Changed 19 months ago by traumschule

Parent ID: #28231

Make #28231 parent of GetTor distribution methods.

comment:3 Changed 8 months ago by cohosh

Cc: cohosh added

cc'ing cohosh on open GetTor tickets.

comment:4 Changed 8 months ago by gaba

Owner: ilv deleted
Status: newassigned

Removing ilv as onwer of many of the tickets. He can take back the ticket he will work on if he comes back into gettor.

comment:5 Changed 8 months ago by gaba

Status: assignednew

comment:6 Changed 3 months ago by alwayslivid

I'm interested in working on this.

comment:7 Changed 3 months ago by cohosh

Owner: set to alwayslivid
Status: newassigned

comment:8 Changed 3 months ago by alwayslivid

Here's an initial repository/"mock-up" that I'm currently using for experimenting:

https://github.com/AlwaysLivid/OnionSproutsBot

It's not functional, as noted in the README.md file as of the time of this writing, but any sort of feedback would be appreciated. I can also provide screenshots/instructions.

comment:9 Changed 3 months ago by alwayslivid

I have started working on this and I have prepared the "boilerplate" code for it, which means that it's nearly feasible to shift the focus on developing the bot itself on top of that.

I spent some time studying the source code as I was working on this, and I think I understand that the way gettor works is by checking up Twitter and e-mails and responding to them once every 10 minutes.

However, since Telegram is solely an instant messaging service, one could make the bot in a way where someone simply sends a message and gets a reply (even after a given interval), but I'm not sure whether that would be the most optimal way to go, as I'm an outsider that's not way too familiar with the project coordination, and as such, I'm not really very aware of the long-term goals of this project.

For instance, Telegram is home to some very user-friendly bots that provide GUI menus (inline keyboards, which are essentially buttons, see more here) and the way they are structured reminds of desktop programs, which is a very good feature that could make the bot far more accessible. Should the responsiveness be overlooked, the bot would not seem as consistent with the rest of the bots offered by the service.

With all of that in mind, I'd like to pose the following questions regarding the direction that I'll need to take:

  • Should the Telegram bot make use of fancy features that could make its use much easier and more widely accessible, such as the inline keyboard?
  • Should the Telegram bot respond instantly? Should the Telegram be always available? (If so, the interval system would have to be revamped or changed completely, sacrificing consistency. Private messages on Twitter could also count as a form of "instant messaging".)
  • Since Telegram is used by populations in sensitive areas, would it make sense to provide an option for multiple different languages? (This would work way better with an inline keyboard, in my opinion)
  • With all of that in mind, should pyTelegramAPI, which is the module that I'm currently using, be avoided in favor of requests and JSON? (again, for consistency)
  • Would it be perhaps a good idea to create a secondary project that's separate or simply related to the original source code of gettor?

The design that I initially came up with before shifting my attention to gettor itself after being recommended to do so by the IRC here, which is also the design that I'd like to propose.

The work that I've done so far as of the time of this writing can be found here. (The interval options do not work and are simply a placeholder-- moreover, the actual Telegram implementation has not been completed yet, due to the aforementioned issues.)

My tree can also be found here.

I tried to explain everything I could in detail-- I hope that I didn't get too redundant. I can provide screenshots, in case that I wasn't concise enough. All sorts of feedback is immensely appreciated.

Last edited 3 months ago by alwayslivid (previous) (diff)

comment:10 Changed 7 weeks ago by alwayslivid

I spent a while studying the source code of gettor, and after attempting to build a bot directly on top of gettor would seem difficult, due to the fact that certain functions that the whole program depends on (e.g. get_new()) would simply not fit together with the design of an interactive bot that responds immediately to all queries.

So, I'm moving on with the idea of creating another bot and then making use of snippets that are mostly in the upload folder, in order to handle uploading in a way that could also be more easily backported to the upstream version of gettor in the long term (... in case that does happen).

Here's the issue I'm currently dealing with; I initially used the GNU GPL v3 license for my own code, but since I wanted to adapt certain pieces of source code from gettor, I think that changing the license to one that's more similar to the one that gettor has should be enough. I tried to reach out and ask about that in the IRC and got no response, so I'm just leaving this here in the case that any issues could potentially arise from the decision that I made.

Note: See TracTickets for help on using tickets.