> В моих клиентах проверок на длину msgid (и не только длину) нет. Есть только проверки на эху (если в строке есть точка, то это эха), но могу добавить двойной фильтр, если что.

человек может сменить сеть, и при этом захотеть сохранить архивы эх. дело не в длине, а в том, чтобы софт понимал, что это такое

> Если на сервере за время до фетча появились сообщения в количестве больше n, то клиент не сможет их зафетчить.

это организационнная проблема, а не техническая. кроме того, если в n сообщений нет ни одного знакомого, можно запросить ещё n, а потом ещё. в фидо тоже и сообщения терялись и всякое бывало - любят его не за это :) софт должен оперировать актуальными данными, а предания старины глубокой - только по запросу. например, зачем мне сейчас весь архив pipe.2032? мне нужны только последних 100 сообщений, где я в дискуссии. и именно по таким принципам должен работать софт в gk11.

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

я уже где-то показывал, как работает acceptts. у меня на этом принципе полные бандлы срезов для bosfor делались. но бандлы для 10000-1M сообщений генерировать очень долго, поэтому в gk11 бандлов не будет, принцип старый - сначала списки с msgid, потом сами сообщения. и не нужно хранить acceptts для каждого сообщения, нужно хранить для каждой эхи. в любом случае, это всё заботы клиента.