[Bug 293318] New port net/telemt - MTProxy for Telegram on Rust + Tokio

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293318

--- Comment #22 from vova@zote.me ---
mtg and telemt are quite different software solutions:

Telemt vs mtg

High-level positioning

mtg:

* Single-purpose MTProto proxy
* Minimal configuration
* Minimal operational overhead
* “Install and forget”

Telemt:

* MTProto proxy platform
* User/account management
* Quotas and limits
* APIs
* Relays and masking infrastructure
* Designed for larger deployments

Feature comparison

Feature                              Telemt    mtg

⸻

Classic MTProto                      Yes       Yes
Secure MTProto (dd)                  Yes       Yes
FakeTLS (ee)                         Yes       Yes
SNI Fronting                         Yes       Yes
Replay protection                    Yes       Yes
IPv6                                 Yes       Yes

AdTag support                        Yes       No
Multiple users                       Yes       No
Per-user secrets                     Yes       No
Per-user quotas                      Yes       No
Per-user statistics                  Yes       No
Per-user limits                      Yes       No

Management API                       Yes       No
Runtime user management              Yes       No
Quota reset API                      Yes       No

Middle-end relays                    Yes       No
Traffic masking                      Yes       Basic
Advanced fallback handling           Yes       Basic
Fairness scheduling                  Yes       No

Rate limiting                        Yes       No
Active IP accounting                 Yes       No
Unique-IP limits                     Yes       No
Abuse controls                       Yes       Limited

Observability                        Extensive Basic
Metrics/statistics                   Extensive Limited

Docker support                       Yes       Yes
FreeBSD support                      Yes       Yes

Configuration complexity             Medium    Very low
Operational complexity               Medium    Very low

FakeTLS quality

mtg:

* Implements FakeTLS
* Implements SNI fronting
* Optional fallback site
* Focus on simplicity

Telemt:

* Much larger investment in TLS fidelity
* TLS 1.2/1.3 handling
* ALPN support
* Better SNI handling
* Certificate management
* Active probing resistance improvements

Traffic masking

mtg:

Client
  |
  v
MTProxy
  |
  +--> Telegram
  |
  +--> fallback website

Telemt:

Client
  |
  v
MTProxy
  |
  +--> Telegram
  |
  +--> masking subsystem
          |
          +--> relay
                  |
                  +--> HTTPS target

Multi-user operation

mtg:

Secret
  |
  v
Proxy

Telemt:

Proxy
  |
  +--> User A
  +--> User B
  +--> User C
  +--> User D

Each user may have:

* own secret
* quota
* limits
* statistics
* API-managed lifecycle

Resource usage

mtg:

* Smaller binary
* Lower memory usage
* Fewer dependencies
* Easier to audit

Telemt:

* Larger codebase
* More memory
* More background state
* More features

Deployment recommendations

Use mtg when:

* One secret is enough
* Family/friends deployment
* Lowest maintenance required
* Smallest possible footprint
* Simplicity is the primary goal

Use Telemt when:

* Multiple users
* User quotas
* AdTag support
* Management APIs
* Traffic accounting
* Abuse prevention
* Advanced DPI resistance
* Large public deployment

mtg feels like:

OpenSSH

Small, focused, conservative.

Telemt feels like:

HAProxy + OpenSSH

A significantly larger system with many operational features.

Bottom line

If your goal is:

"I need a reliable MTProxy"

then mtg is probably the cleaner solution.

If your goal is:

"I am running a service and need users, quotas, APIs,
 statistics, abuse control and extensibility"

then Telemt provides a substantially larger feature set.

-- 
You are receiving this mail because:
You are the assignee for the bug.