feat: Telegram provider

[Thechi2000]

Add Telegram as a news provider. The app should be able to use messages sent through telegram channels to be used as news for the transcript generation.

DoD: The user can add/select channels used as a news provider for the transcript.

[Thechi2000]

Blocker

I've looked into this, and there are two main blocking issues:

• A Telegram Bot cannot join a telegram channel. It has to be added by an admin.
• The bot cannot list the messages on the channel, it will only receive those as updates.

Solution

I've drafted an idea to implement this provider while taking those limitations into account:

The admin of a channel can add the bot, making the channel available as a news provider. The user can then choose which channels to use, from a predefined list fetched from the database.

The bot is configured through a webhook, pointing to an Edge Function. It handles two possible updates: either "channel join" to create the entry in the provider table, or "receive message", which logs the message in a new table "telegram_news". This table will then be used to get the news. To avoid space overuse, it also keeps the date of each message, to discard those that are more than 24h old.

It would require to refactor the database to have a more relational use of the providers, where the providers can be added by anyone, are unique, and have a Many to Many relationship with the news settings. This implies a refactor of all the providers' usage as of now.

Alternative solution

Another way is to use the Telegram's users' API, but this means we need to create a virtual client, i.e. the user logs in with his telegram account on the ActualIA app, then we can fetch the news from the channels they whishes, as long as they joined them. We could also have a dedicated telegram account, to avoid managing the user's one, but we would need to use one of our Telegram account, since it requires a phone number.

---

I'd would like external opinions about that, to choose the way forward.

[quartztz]

I'll need to have a look at the telegram user API !

As for the first option, while there are pros to having the channel maintainers "opt in" to our app workflow (potential for inviting more users to our app, more transparency as to how we use their content, etc etc), I don't think we want users unable to access a given channel as a provider because that channel's admin didn't add our bot to it.

The telegram user API is - at the very least - the most "natural" way to go forwards, in my opinion. Still, considerations about privacy and security need to be maintained towards users. I might change my mind if it would allow us to read any chat and/or send any message we want to. Using our own account is possible, sure, but definitely a second option to the user registering on their own, since that would require a weirder relationship to telegram channels.

Conclusion : does the User API allow us to impersonate the user on their Telegram account, or can permissions be given on a per-app basis?

[Thechi2000]

To my understanding, there is no fine-grained permissions, the token would give full control over the API. This is the same access level as if we could access the Telegram app on their phone. This is why I strongly dislike this solution.

Using our own account is possible, sure, but definitely a second option to the user registering on their own, since that would require a weirder relationship to telegram channels.

I'm not sure to understand why this would be weirder. Using the client's API, it would allow the app to list all the messages of a channel, just like we do for GNews or the RSS feeds. The weird option is the bot one, since it would need to store the messages in the database, since their are fed to the bot through webhook callbacks.

I also agree that having admins to register their Telegram channel is not ideal, especially since bots have to be admin when added to channels, but it is the only solution that does not require to store personal access tokens in the database/Supabase secrets.

My conclusion is that the most user-friendly solution is to use one of our account, and it is also the easiest to implement, but someone needs to agree to add their personal access token to Supabase (and that person is not me). The two other solutions have strong cons (that is, having to register channels, giving admin rights to the bot or storing personal access tokens in the database).

[Thechi2000]

Since no one else expressed their opinion, I'll try the solution of the single client API access token as a PoC, refactoring the database at the same time.

[pmdlt]

Check https://rsshub.app (https://docs.rsshub.app/)

[Thechi2000]

Check https://rsshub.app/ (https://docs.rsshub.app/)

Thank you so much !!! This is incredible, so much easier. I think I'll refactor the provider management to use this for everything instead of having a polymorphic approach.