The only exception is emojis.
Also changed direct download encoding field names to be more generic
when used in mixed manner depending on peer type.
Direct downloads are still somewhat inefficient as they require an API
round trip to succeed but we can cache things in the database if needed.
The default is 512kB and the RPC request overhead has more impact
on download speed than having half smaller chunks.
Next level speed improvement would be to use parallel downloads and
have an on-disk buffer to stream out the rebuilt file on-the-fly when
we consistent stream of data available.
When logging out, we should first handle network level logout and after
that ensure the client is disconnected before removing state to avoid
having event handling during disconnect from touching anything anymore.
I don't know why we nilled the client but since so many places use it
we'd rather get errors rather than panics if it's being used after
logging out but previous lifecycle fixes should avoid that.
It's always gunzipped, so should never send the application/x-tgsticker mime.
Also, video/lottie+json was recently registered with IANA, so use that instead
of the old image/lottie+json: <https://www.iana.org/assignments/media-types/video/lottie+json>
This will hopefully make it so that if the preview gets edited in by
Telegram at a later time, it will be bridged.
Signed-off-by: Sumner Evans <sumner.evans@automattic.com>
Previously, the getAvailableReactions function was only called with a
logged in client. However, now that it is called in the GetCapabilities
call, the client is no longer guaranteed to be logged in.
This was causing an NPE due to the (*TelegramClient).client being nil.
This commit makes the getAvailableReactions function not panic when the
client is not logged in.
Signed-off-by: Sumner Evans <sumner.evans@automattic.com>
For some reason, even though we provide an offset, Telegram sometimes
sends us more events than we request, including newer events than the
offset ID. Messages beyond the offset are then chopped off by the
bridgev2 code, but we continue trying to backfill the portal thinking
that there is more to backfill. This causes infinite backfill loops.
Signed-off-by: Sumner Evans <sumner.evans@automattic.com>