Иногда конструкторы user и channel имеют меньшее количество атрибутов (но атрибут id всегда присутствует) и флажок min. Это сделано для повышения скорости работы и конфиденциальности.
При получении этих конструкторов, клиент всегда должен в первую очередь проверить, присутствует ли в локальном кэше объект user или chat без флажка min. При их наличии клиент должен игнорировать конструкторы с min и использовать локальные.
Дальнейший текст подразумевает, что клиент получает конструктор с флагом min, не имея полного объекта в локальном кэше.
Клиент обязан хранить контекст (как и параметр file reference), в котором был обнаружен пользователь или канал. Позже, когда клиенту необходимо применить пользователя или канал в качестве аргумента ввода (например, при получении информации о профиле, отключении уведомлений или блокировании), контекст используется для генерации конструктора input*FromMessage, а не привычных inputUser, inputChannel или inputPeer.
Значение access_hash, если оно задано, подходит только при использовании в inputPeerPhotoFileLocation, позволяя напрямую загружать профильные изображения каналов и пользователей без необходимости генерировать inputPeer*FromMessage, а просто используя inputPeer* с заданным хешем доступа.
Обычно конструкторы с min встречаются в сообщениях внутри групп и каналов.
Когда находится сообщение, упоминающее (в качестве отправителя, переславшего, принявшего и т.д.) нужного пользователя или канал, конструктор должен быть ассоциирован с ID сообщения и с чатом, где это сообщение было найдено.
Допустим, сообщение с ID 34 было получено из супергруппы (технически, канала) 123456789. Это сообщение было отправлено от пользователя с from_id=102424212. В контейнере updates, хранящем сообщение, присутствует пользователь с ID 102424212 в атрибуте users, но установлен флажок min, и отсутствует access_hash (а значит нельзя использовать для генерации конструктора inputPeerUser для отправки сообщений и других действий).
Действия клиента следующие: он ассоциирует 102424212 с каналом 123456789 и ID сообщения 34. Когда (и если) клиенту понадобится взаимодействовать с пользователем 102424212, он сгенерирует один из упомянутых выше конструкторов *FromMessage, задав значения:
msg_id равное 34peer в InputPeer, ассоциированный с каналом 123456789user_id — 102424212user_id также может быть присвоено ID пользователей, обнаруженных в fwd_header (сообщения, пересланные от пользователя, которые можно использовать для взаимодействия с изначальным отправителем, если у него не указаны соответствующие настройки конфиденциальности для пересылки сообщений).
То же самое работает и для min-каналов.
В качестве живого примера такого подхода можно привести Telegram для iOS и tdlib.