ну и всякие штуки типа - если при загрузке round video не указать его размер - можно загрузить дольше минуты видео и оно будет принято если его размер <8мб примерно, при этом раньше даже можно было w:h видео поменять и клиенты его отображали в кружке другого размера - то есть бэк очевидно ниче не декодирует при загрузке, а мониторит только размер и как есть отправляет на клиенты.
.пока не появились HD превьюхи - thumbnail картинки для видео можно было ресайзить(да и до сих пор можно) - и сделать отношение сторон превьюхи отличным от видео - бэк проверял только размер файла и чтобы не более 80-100 пикселей была наибольшая сторона. А иногда бывает так что бэк при загрузке видео с thumbnail все устроило и ошибки не было, но thumbnail бэк заменяет на черный прямоугольник - выглядит как костыль бэка.
периодически баги встречаю с крашем клиента, например, если GIF определенную попытаться отправить в чат - проблема в том оказалась, что размер гифок на клиенте жестко задан максимальный, а проверка делается assert-ом бескомпромиссно - то есть клиенты полагаются на то что бэк им никогда не пришлет гифку больше 10мб, но что-то пошло не так и на беке оказалась как-то гифка в 13мб. такие вот вещи у меня формируют ощущение монолитной архитектуры

жаль продолжения нет

Вообще сетования на плохую схему мне не понятны, я писал клиентные вещи и читал эти схемы, просто нужно уметь документацию переваривать лол. Вся статья реально нытьё про документацию

Всяко лучше тысячи херов которых ни у кого нет в реальном софте

просто нужно юзать кодогенераторы

которые кстати думаю команда и юзала

например Престон про баг с thumbnail черным не смог ответить ниче - типа сам хз почему так

Так и есть, я помогал даже писать питонячие либы, всё по схеме генерит + автодокументацию создаёт

Также есть tdlib если влом писать своё

опять же - не просто так код бэка закрытый - на то конечно ряд причин есть коммерческих просто, но в том числе - думаю основная в том что это монолит из которого по максимуму выкинуты все которые можно промежуточные проверки, возможность что-то менять и тд в угоду конкурентным преимуществам и быстрой разработке и соответственно отказоустойчивость системы держится на том что никто не знает как она устроена, а реверс инжениринг успевают заметить и пофиксить

Ну так а че не поломали ещё?

с чего ты взял

Ну так у них политика сообщать о таком

Еще раз. Если один человек или десять, например, будет в десятке тысяч чатов, то ничего заметного не произойдёт, может у него разве что тормозить начнёт немного, но он может и не заметить. Если разрешить всем и это сделают миллионы человек, то ляжет вообще все, потому что внутренняя серверная инфраструктура будет перегружена. Ограничение в 500 сделали не от хорошей жизни, убирать или существенно увеличивать его можно будет только вместе с серьёзными архитектурными улучшениями серверного кода и логики.

Я согласен, что могли бы сказать, что не стоит так делать. Мне конечно с моей стороны кажется, что это правда и так понятно — что конечно вероятность, что такое вот не прикроют (создавать тысячи супергрупп кастомными языками с языковой платформы — при том, что на создание супергрупп пользователями стоят жёсткие ограничения) близка к 1 как только кто-то это заметит. Но может это мне кажется понятным из-за десятилетней работы с другой стороны — со стороны тех, кто пытается разрабатывать платформы и следит, чтобы они работали, а не внезапно переставали работать из-за того, что их кто-то абьюзит как не предполагалось.

То есть я рассуждал бы так — если есть ограничение, достаточно жёсткое, на создание чатов, значит для этого есть причины. Если где-то появился способ создавать их без ограничений — значит это баг, иначе и у юзеров бы не было ограничений. Раз такой баг, который ещё и потенциально приведёт к проблемам с нагрузками, то его закроют, как только заметят. Но жаль, что это не проговорили явно.

Его заметили спустя 2 года

Ха-ха

За это время я создал 7,5 млн чатов

вот пример