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

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

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

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

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

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

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

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

Проблемы экономии трафика я не вижу, я каждый раз нажимая F5 в браузере потребляю трафика больше, чем в ii клиенте потратил бы за день. Но для этого всё равно есть list.txt, который можно даже кэшировать. lim только для новоподключившимся к большим эхам. стандарта на годовые эхи не будет, но для себя, если эха разрастётся, то поедет в эха.25 и так далее. это не вопрос спецификации, это вопрос реализации на конкретной станции.

list.txt кэшировать на сервере, чтобы уменьшить нагрузку на него

поменял list.txt

кстати, к народному фольклору. какую эху можно посмотреть клиентом но нельзя в большинстве веб-интерфейсов? эху list.txt. потому что раньше postfix обязан был быть цифрой, а теперь получили такую забавную коллизию. это можно даже как-то использовать, в духе "пиши в эху list.txt, там никто не увидит" :)

мемо забыл проставить. ну хоть так, метамемо поставлю

+++ memo:iiiiii

А, ещё. Хочу использовать два первых символа хэша для указания года (только не решил, будет ли memo иметь приоритет или нет, наверное будет, это будут именованные сообщения)

пишу тут: http://ii.blcat.ru/naste.ne.notes

ahamai> кстати, к народному фольклору. какую эху можно посмотреть клиентом но нельзя в большинстве веб-интерфейсов? эху list.txt

А потому что нефиг завязываться на точку было. Сделали бы 1) что-то в духе /u/l (в моём новом несовместимом протоколе будет /r/l вместо list.txt), 2) в выводе /u/e после каждой эхи (для отличия от msgid) ставить двоеточие. И всё, никаких коллизий.

ahamai> мемо забыл проставить. ну хоть так, метамемо поставлю

Что такое memo

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

http://ii.blcat.ru/memo00