> На моё сообщение ты как-то очень непрямо ответил.

я ровно в каждом сообщении пишу ровно одно и то же.

1. меня не интересуют стандарты и технологии. как я могу ответить вопрос про стандарты и технологии, если мне это неинтересно, и для меня это вообще не проблема, какой бы стандарт в итоге не приняли.

2. вспомните 2014 год. у меня каждое сообщение ровно про одно - вспомните 2014 год. всё. ни о чём другом я не пишу. и про технологии я пишу только в этом разрезе.

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

речь была о мусоре в /u/e который нужно игнорировать

а какая разница в запросе??? бандл он нужен только для одного, получить информацию. если тебе нужна информация, ты делаешь конкретный запрос. а так, ты сделал некорректный запрос, ну тебе выдался список пустых эх. И ЧТО.

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

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

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

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

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

и чем проще формат и чем меньше непонятных букв, тем больше может возникнуть желание написать клиент. для принятия решения нужно 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