makkarpov
commented
6 years ago Well, I had tried to analyze that implementation. It's very strange, poorly written, overengineered and completely unreadable.
Additional encryption key retrieved from the server (looks like it's used to connect to DCs)
It is initialized in aes_load_pwd_file (net/net-crypto-aes.c), hashed with MD5 and used as AES key. Original secret is discarded. Proxy uses this secret in a message with type 0x7acb87aa (I can't find it inside official TL schema). It seems that original proxy server implements full MTProto parsing & serialization (while all of these community servers just forward traffic back and forth).
Tag for managing promotion channels and stats
Message with type 0x36cef1ee (RPC_PROXY_REQ, defined in mtproto/mtproto-common.h). No official TL specs for this message either.
Updatable DC list
It seems to be already implemented. But old approach with traffic forwarding does not work with these DCs for me.
LDVSOFT
dotcypress
Is your feature request related to a problem? Please describe. There is another MTProxy that looks in code like it's actually one to become official: https://github.com/TelegramMessenger/MTProxy. It actually supports optional promoted chanels and more security options. The problem for me is it's overcomplicated and has strange bugs, and I think implementing missing features here would give a better result ;)
Describe the solution you'd like Just implement such features as
Describe alternatives you've considered I just belive that implemeting there features in clean Rust solution is better compared to what the heck it going in that C solution, and they don't look that hard.