Текущую проблему (одну из трёх) я вижу в том, что не пишут софта. Сейчас ровно один человек пишет клиент, и он программист. Раньше софт писали любители. Я сам любитель и смотрю с точки зрения любителей

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

и чем проще формат и чем меньше непонятных букв, тем больше может возникнуть желание написать клиент. для принятия решения нужно 100% пунктов, какие ты можешь выполнить. хоть одно непонятное слово может сразу подавить желание заниматься этим. желания спонтанны, но чем больше погружаешься в скуку, тем больше это тебя демотивирует. А просто меняться списками легко и приятно.

И если я решу проблему контента, я сделаю свою спецификацию, чтобы у того, у кого возникло желание писать клиент, было как можно меньше вопросов и желания всё бросить.

Там будут u/ e/ u/e u/m и u/point.

Всё. Будут ещё серверная рекомендация k/v, сейчас там только lim/XXX. это не влияет на написателей клиентов, так как это строчка в конфиге, endpoint в любом случае прописывают при начале работы в сети. это не влияет на писателей серверов, так как они делают базовую реализацию, а потом могут навешивать любые ендпоинты, и просто писать на своей станции "конфиг при подключении к станции такой-то такой-то"

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

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