As the first minimally viable step of #102, I propose us to do the following:
Add database support to Emulsion (should be optional: I host a plenty of Emulsion instances already, and not every one of them demands a separate database).
We should store the correspondence between Telegram message/content ids and our internal ones in said database.
Every content-rich message gets that nanoid included instead of the current message link (like https://codingteam.org.ru/tg/<nanoid> instead of https://t.me/<tgid>).
Create a HTTP service which will serve requests to https://codingteam.org.ru/tg/<nanoid>, and just redirect them to the corresponding https://t.me/<tgid> instead.
This will require us to store both Telegram message id and content id together. Collisions are possible if there are several messages with the same content id (not sure how, but technically possible). In such cases, just generate several entries (for each content id + message id pair).
At a later point, we may migrate and renormalize the database if we decide that the message ids aren't required.
As the first minimally viable step of #102, I propose us to do the following:
https://codingteam.org.ru/tg/<nanoid>
instead ofhttps://t.me/<tgid>
).Create a HTTP service which will serve requests to
https://codingteam.org.ru/tg/<nanoid>
, and just redirect them to the correspondinghttps://t.me/<tgid>
instead.This will require us to store both Telegram message id and content id together. Collisions are possible if there are several messages with the same content id (not sure how, but technically possible). In such cases, just generate several entries (for each content id + message id pair).
At a later point, we may migrate and renormalize the database if we decide that the message ids aren't required.