nheko VS telegram-bot-api

Look at this, notice anything different? https://github.com/Nheko-Reborn/nheko/issues/new/choose

Nheko has been around for a number of years. Never used it myself though.

https://github.com/Nheko-Reborn/nheko

Matrix clients hit different than pretty much any other chat client I've use before. Theres multiple clients I've found like nheko, moments, element that are a pleasure to look at and smooth as hell. Even better you can have users use web services like Element Web to sign-up and chat. Its sick.

The Nheko flatpak is official. Just compare the source to the nightlies we build and upload to our nightly repo.

Like almost every client out there it has no support for e2ee. I was happy to find https://nheko-reborn.github.io (I'm a KDE user so Qt apps are preferred).

There's also FluffyChat or Nheko if Element is too heavy.

I probably wouldn't have guessed that `e.dataTransfer.items` gets cleared at the first await (since I'm not a proficient web developer), but I would've been extremely wary of this code in general. Additionally (not tied to async-await but race conditions in general), is `item.getAsFileSystemHandle()` a TOCTTOU vulnerability where the type of an item can change between folders and files and symlinks etc., while this code is running?

Rust's & vs. &mut system largely eliminates shared state hazards in both threading and asynchronity (&mut is exclusive/unaliased and can't be mutated by other threads or event loop jobs, and & is difficult and unidiomatic to mutate), though it doesn't solve async cancellation errors (https://carllerche.com/2021/06/17/six-ways-to-make-async-rus..., discussed at https://news.ycombinator.com/item?id=27542504), or filesystem TOCTTOU (https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html as well as user code).

Qt event loop reentrancy is fun(tm) as well. It looks like a blocking call, but spawns a nested event loop which can do anything (but rarely enough to lull you into a false sense of complacency), resulting in segfaults like https://github.com/Nheko-Reborn/nheko/issues/656 (workaround at https://github.com/Nheko-Reborn/nheko/commit/570d00b000bd558..., I didn't look into it). And Qt lacks "easy" await syntax and a framework based on calling red functions (though I didn't look into C++20 coroutines yet, perhaps https://www.qt.io/blog/asynchronous-apis-in-qt-6 or https://github.com/mhogomchungu/tasks or https://blog.blackquill.cc/asynchronous-qtquick-uis-and-thei...?).

Is not that hard, they have amazing documentation about it: https://core.telegram.org/bots

You can make authorization via Telegram another way. It works. But today we want to do the classic OAuth Authorization. Before you begin, you need to create a Telegram bot and obtain your bot token. You can do this in @BotFather in Telegram. For more information on initiating a bot, read the Telegram Bot API documentation: https://core.telegram.org/bots

Absolutely possible. Here's the github page to the Telegram bot API. You would just need to check for incoming messages, check the body of the message for a word or phrase, and then send a message back with a photo or gif and an encouraging message.

Creating a Telegram bot is fun: there's no website, no sign up, no forms — you just use a... bot. Yes, a bot that creates bots. It's called the BotFather 😂

Telegram has a bot API server that provides API to control the bots and get updates. Their own instance has some restrictions like you cannot download files bigger than 20MB. So, using a self hosted bot API server, you can overcome those limits.

General Bot Platform Overview

$ curl -4 -v https://api.telegram.org * Trying 149.154.167.220:443... * TCP_NODELAY set * Connected to api.telegram.org (149.154.167.220) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server accepted to use h2 * Server certificate: * subject: CN=api.telegram.org * start date: Mar 24 15:21:45 2022 GMT * expire date: Apr 25 15:21:45 2023 GMT * subjectAltName: host "api.telegram.org" matched cert's "api.telegram.org" * issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; OU=http://certs.godaddy.com/repository/; CN=Go Daddy Secure Certificate Authority - G2 * SSL certificate verify ok. * Using HTTP2, server supports multi-use * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * Using Stream ID: 1 (easy handle 0x555fdb2de2f0) > GET / HTTP/2 > Host: api.telegram.org > user-agent: curl/7.68.0 > accept: */* > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * old SSL session ID is stale, removing * Connection state changed (MAX_CONCURRENT_STREAMS == 128)! < HTTP/2 302 < server: nginx/1.18.0 < date: Tue, 18 Oct 2022 00:00:24 GMT < content-type: text/html < content-length: 145 < location: https://core.telegram.org/bots < strict-transport-security: max-age=31536000; includeSubDomains; preload < access-control-allow-origin: * < access-control-allow-methods: GET, POST, OPTIONS < access-control-expose-headers: Content-Length,Content-Type,Date,Server,Connection < 302 Found 302 Found nginx/1.18.0 * Connection #0 to host api.telegram.org left intact

It's done via bots, which let you add clickable options to posts. Here's an FAQ on bots: https://core.telegram.org/bots