> Просто парсить надо будет вручную

это не есть прозрачная замена. прозрачная замена, это когда ты в любом клиенте просто прописываешь этот url вместо нужного, и ровно ничего не меняется кроме того случая, когда фильтр срабатывает, независимо от того, знает ли нода что-то или нет. если добавлять везде ?sf, то нода с запросом ?q=, ничего не знающая о ?sf, на запросе брякнется

вот /lim/ совместима с любыми существующими клиентами, просто меняешь url в конфиге и всё.

Я вообще не про это. Я про то, что не надо было трогать протокол, который для трогания совсем не предназначался. В чём проблема была вместо проверки x/feautures всяких просто использовать новый, а при отказе - фэлбекаться? Ну самый же очевидный дизайн. Зачем там, где всё было предельно просто, зачем-то совершенно ненужно это усложнять?

или пойдёт. у меня уже столько расхождений между текущей станцией и 0.7, что надо на 0.7 переползать и уже в неё изменения вносить. в общем, вся хрень типа девочек-аватарок и advent удаляется, я перееду на 0.7

даже list.txt подстраивается

http://ii.blcat.ru/lim/100/list.txt

> Если нет проверки на то, что тебе не подсунули мусор, то это неработоспособное решение - как POC для запуска в песочнице для ограниченного круга лиц - годится, а для реальных применений в массах - нет…

ЕСЛИ МУСОР - ПАДАЙ. Не надо разбирать мусор. Топология сети такая, итить. Ты качаешь с доверенных узлов по предварительной договорённости. Формат бандла определён. Если оттуда летит мусор, то это уже красный код, не надо с него качать и не надо ничего разбирать, надо снимать с фетча.

Какое, итить, неработоспособное решение, если оно работает. Сколько раз повторять, что /u/e/ это базовый фалбак и он должен быть простым и легко воспроизводимым, нигде не должно быть проверки в коде и в стандарте. Как работает твой конкретный фетчер, по барабану. Есть базовая реализация, эталонная. И она должна быть максимально простая. И она должна быть одна.

Это базовый вопрос - НАХРЕНА ВЫ ЛЕЗЕТЕ В /U/E, ЕСЛИ ВЫ ТУПО ДАЖЕ НЕ ПОНИМАЕТЕ, ЧТО ЭТО И ЗАЧЕМ ЭТО НУЖНО???

ну я читаю такую ахинею
> Если нет проверки на то, что тебе не подсунули мусор, то это неработоспособное решение
и вижу люди тупо не понимают, о чём это вообще.

> а для реальных применений в массах - нет…
для каких млять применений в каких млять массах. ii это реализация строго конкретной задачи. основным критерием этой задачи является максимальная простота. НИКТО, НИКТО МЛяТЬ В ЦЕЛОМ СВЕТЕ НЕ МЕШАЕТ ТЕБЕ НАВЕШИВАТЬ СВОИ НАВОРОТЫ. Ну оставь ты млять в покое /u/e, это лингва франка, это база, это долгими бессонными ночами вытачивалось, чтобы удалить всё лишнее и оставить только базу, из которой можно свинтить что угодно, хоть босфор, хоть улисс - и никто при этом не трогал /u/e. Когда человечество вымрет и останутся только ветки и палки, чтобы можно было быстро собрать /u/e, как базовый компонент. И ПОЭТОМУ ОН МЛЯТЬ ДОЛЖЕН БЫТЬ ОФОРМЛЕН, ПРОСТ И ОДНОЗНАЧЕН, чтобы любая макака могла написать его реализацию. Любая. На любом языке. С любым млять навыком. Не мусор собирала.

И это млять не POC. Это и есть млять сама концепция сети. Нахрена переписывать базовый класс, наследуйся от него и потом пиши, как хочешь. А основные 4 стержня, которые работают в любых, любых млять условиях, они для того и сделаны такими простыми чтобы быть такими простыми. Без проверок, х..рок и прочей хрени. Обмен между нодами регламентируется ТОЛЬКО самими нодами. Могут хоть через git обмениваться и индексы по timestamp генерировать, это изначально была валидная версия обмена. Но помимо этого должна быть база, которая должна работать ВСЕГДА, ВЕЗДЕ, она должна быть МАКСИМАЛЬНО ПРОСТОЙ и МАКСИМАЛЬНО ВОСПРОИЗВОДИМОЙ. Поверх этого уже какие хошь расширения, это вообще пофиг, лишь бы клиент и сервер поддерживали. Но когда есть два стандарта на работу /u/e (один мой, другой неправильный (ц)) - это уже маразм.

Я смотрел старую переписку и кто какие фишки предлагал. Это могло быть перетряханием стандартов, какой из них стандартнее, уже тогда. Но я волевым решением отправил всех в лес и зафиксировал самую базовую базу, которая могла быть. Поэтому это всё и работает, поэтому и не было обсуждений стандартов а просто всё работало, а простота рекламировала эту технологию саму за себя. А потом /u/e взяли и изнасиловали.

+++ memo:marazm

Многие проблемы решаются кодом, а ещё большие её отсутствием. Плохой дизайн нельзя исправить кодом, или стандартами. Как пример это e-mail/smtp.

и да, если ты делаешь расширяемый формат, то делай его РАСШИРЯЕМЫМ. потому что кроме x:y это расширение не умеет, и добавить туда, не делая очередные псевдозаменители эх. Типа /эха/x;y/эха/x:y

bosfor имел полноценное key/value api, и при простой внутренней структуре позволял делать крутые вещи, типа выборок "дай мне сообщение с такого-то таймстампа по такой-то таймстамп", хоть в конкретных эхах, хоть во всех, хоть с выборкой по юзеру. и при этом был в обе стороны полностью совместим с ii. можно было просто сделать api, и там кто хочет в серверах, кто хочет в клиентах, использует хоть выборку по сообщениям, хоть выборку по msgid, а клиент/фетчер уже схемой в конфиге указывает, что и где он берёт. отсутствие нужного фильтра просто не фильтрует по этому параметру. у босфора просто ни одного клиента не было, чтобы это где-то использовать :) но когда люди сами пишут клиентов - это самая разумная схема. нет, надо наделать проверок в клиенте, проверок в сервере, чтобы хакнуть /u/e, и теперь у нас два /u/e

/u/e и /u/m захаркожены в урлах именно потому что они топорные, примитивные и неизменяемые. у босфора был свой неймспейс /bb, который решал все задачи и слайсов, и ...яйсов. делай выборку так, как тебе хочется, делай проверку так, как тебе хочется. кода каждая проверка занимала примерно одну-две строчки. Поэтому любое расширение добавить дело было пары минут. И это расширение даже не надо делать мейнстримным, это может быть расширение, которое служит чисто для удобство обмена двух нод (как твой /h/x). И вообще ничего нигде не ломает и не хачит by design. Единый урл, который собирает все key/value в словарик, примерно как тэги в первой строке каждого ii сообщения типа repto, которые тоже позволяют развивать формат, добавляя свои тэги, которые не понимающие их станции игнорят (см. elp, там были тэги topicid и tags, и elp тоже отлично гейтовался в ii)

кстати, я нашёл в инете сырцы bosfor. поменять размер msgid с 11 до 20 и добавить обязательные точки в эхах - и будет вообще полноценная прозрачная замена, полностью совместимая с ii и при этом обладающая развитым api

хотя нет, чёт там всего много :)

> Каких нахрен доверенных узлов?

таких же как в фидо

> Оно всё в интернет торчит голыми жопами - кто-то напишет сырой клиент который при переполнении чего-нибудь где-нибудь зашлет тебе дамп своей памяти вместо корректного запроса и чо?

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

> А вдруг не игнорят? Там ведь может быть только либо ii/ok, либо repto/msgid если там не ii/ok то это должно быть repto - где написано что там может быть мусор? :)

парсинг сообщения это вообще другая тема, с запросом сообщений не связанная

а вообще, ii/ok там только для того, чтобы в любом случае не было пустой строки, которая где-нибудь может отфильтроваться.

> если бы создатели сетевых протоколов всецело доверяли друг другу, то интернет бы давно умер…

если бы все протоколы были одинаковые, они были бы не нужны, достаточно было бы одного

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

голдифицировал ябическую тему "Вестям Linux не нравится". На это ушло несколько недель, исправления адского форматирования, перевода с транслита. Из более 200 сообщений выбрал в итоге 89. Думаю, другие выбранные темы будут попроще.

глянуть можно здесь: http://ii.blcat.ru/rr/lor.gold/Ct8espwtEvwcPsbg9bTU

ну или тянуть lor.gold с меня :)

ёпт, там с пробелами беда. но в любом случае, это гораздо читаемее, чем было изначально.

это простая смена эндпоинта:

где было прописано http://ii.blcat.ru/u/, будет написано http://ii.blcat.ru/lim/100/u/

какая разница где эндпоинт задан? он всё равно записан в конфиге, и туда можно написать как первую строку, так и вторую. с запросом ровно ничего не делается, он ровно такой же. /list.txt, только эндпоинт другой

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

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

На вопрос "где архив, где посмотреть сообщения за какой-то год" говорят "архив не нужен, эхи для общения". Это IRC для общения, а формат сохранения сообщения предусматривал их сохранение. Если это для общения, зачем тогда вообще нужны эхи на кучу тысяч сообщений, почему их не trunc-ать со старостью. То есть, в архив выгрузить эху нельзя, но старые сообщения хранить будем. Но будем рекомендовать их не выкачивать. Зачем делать распученые эхи, таская архивы, которые и не архивы вовсе. То есть, взяли идею "каждая эха это законченная капсула, которая или в активной работе или в архиве", потом сделали из неё чатилку, потом сделали средства бороться с оверхедом, которые это породило, сейчас надо бороться с последствиями последствий. Когда всё изначально работало ровно так, как задумано. Шарман.

Окей, если это средство общения, то зачем нужен стандарт. ДЛЯ КОГО он нужен? Что он стандатизирует. Что он декларирует: idec это чатилка или idec это для хранения сообщений на века или idec это для экономии трафика. Это разные вещи, а чатилка и на века вообще противоположные. Стандарт должен быть не для отношения нода-нода, тут вообще никогда стандарта не было, в этом и смысл гибкости сети, стандарт нужен был для написания новых клиентов и новых серверов. И он должен был давать что-то. Когда /u/e бывает и таким, и таким, это не стандарт. Когда возникает вопрос "если есть разное количество сообщений в эхах и надо их взять" и ответ "не нужно" - это не стандарт, есть механизм срезов но он неясен непосвящённому (мне, например, до сих пор неясен). И это в сети, которая была простой и элегантной. А этот неявный и грубый хак вообще неэлегантен - это именно хак. Я хочу чтобы непосвящённому объяснили про адаптивный фетч, чтобы он понял. Я, например, не понял. Про "сравнение двух списков и взятие элементов из одного, которого нет в другом" я могу объяснить даже пробегающей мимо кошке. Это основа дизайна сети и от неё все пляшет, поэтому это стандарт. А так, для каких софтописателей это стандарт, чтобы трём пользователям между собой общаться? А нафига вам стандарт-то нужен, сами не можете договориться?

За 10 лет каких то продвижений и изменений нет. И да, я 100% уверен, что я хотел сказать. Ибо умные люди притчами говорят, а глупые в них за частности цепляются, не видя целого.

Зато у вас новый стандарт будет. Ура!

Можно вопрос. На каких вещах я настаиваю. Хоть на одной. Хоть на одной единственной,? Я ВООБЩЕ НИЧЕГО НЕ ПРЕДЛАГАЮ. НИЧЕГО. НИЧЕГО. Неужели это так трудно заметить? Я только разбираю кривой дизайн idec 10 летней давности. Всё. То есть это абсолютно всё. Как можно увидеть то, чего нет вообще, мне непонятно.

У меня тогда две. Там три строки понятного прозрачного кода.

Проблема собственно только в том что вы проблемы не видите. Только и всего.

И это вы раздули тему, рассуждая о том, что я не говорил. Я надеялся на обсуждение типа тут сделано так, тут сделано так. А разговор ушёл в тему тут сделано так потому что тут сделано так. И прочего лишнего. Разговор от ДИЗАЙНА перешёл к ДЕТАЛЯМ и РЕАЛИЗАЦИЯМ. Эта тема меня вообще не интересовало но каждый начинает лезть в неё. Боюсь, вы вообще не поняли, о чём я. Потому что вы не делали Дизайна проекта, принимая много решений "как поступить", а базируетесь на уже готовой реализации, когда те решения, которые есть, кажутся уже сами собой разумеющимися.

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

> А почему так криво задизайнили в 2014 — это уж точно вопрос не ко мне. Но сейчас это приходится принимать как данность. Или же ломать совместимость полностью и делать как следует. Но тогда это уже будет другая сеть.

так об этом то и речь! речь не о проектировании, речь о проблеме проектирования! для чего я все последние дни весь 2014 год в ретроспективе пересказал!

вот смотри - есть какие-то данные, всё из которых, кроме несколько строк, выбираются простым фильтром. один будет писать крутой усложнённый фильтр, чтобы он отфильтровал все данные. второй применит простой фильтр а потом удалит данные вручную. это не разные программы, это разные ПОДХОДЫ. они даже задачи разные решают, один хочет написать фильтр, второй хочет получить данные.

можно простым способом решать 97% задач, а можно накодить ещё и решить 99.9% задач. это разные подходы.

ii не умел "экономить трафик"

> Ну скинь эти три строки тогда. Почему-то уверен, что всего необходимого там не будет.

url.split('/')
for ea on this
out.append([ea] + open('e/ea').splitlines()]

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

если для чего-то нужно 2 навыка, то под этот фильтр может попасть 80% людей. а если их, скажем, 5, которые чуть посложнее, то с каждым новым фильтрация будет гораздо сильнее (команду cat на лоре осилило процентов 99, а парсеры на sh - процентов 20-40). для того, чтобы не понимать, достаточно не знать одного навыка - например я знаю 4 из 5, но я не понимаю, как работают срезы, потому что в разных языках разные нумерации, и я этого просто не понимаю.

этим и отличается простое от очень простое. для того, кому и то и то просто, не видит разницы.

я не говорю, какой путь правильный - правильного пути нет. я говорю о том, как изменилось ПРОЕКТИРОВАНИЕ ii при переходе в idec. Правильно-неправильно, хорошо-плохо - это вообще не важно. Раз тут началась тема с новым стандартом, я просто хотел напомнить 2014, когда делали расширения для ii, чтобы экономить трафик. Почему все на внешнее смотрит и ни один вообще не посмотрел вглубь? Зачем код, причём здесь код. 10 лет назад делали расширение. Я напомнил, как это было, в деталях. Расписал отличия и недостатки НА МОЙ ВЗГЛЯД. Из этого, блять, вообще не следует, что это недостатки для других. Я ПРО РАЗНИЦЫ ПОДХОДОВ. Если кто-то говорит, что старые /u/e и новые одинаково простые, он вообще не с той стороны смотрит. Но с другой стороны так никто и не посмотрел. Ладно. Кто как хочет, тот так и делает, жаль только обсуждение сразу ушло в совсем другую сторону. Но зато сейчас ты знаешь историю в ретроспективе, подумай об этом :) Ну или может кто ещё зайдёт и подумает.

> Если у тебя это не так, чини ноду.

я не могу починить референсную ii 0.3, которая является базовым и законченным стандартом ii, потому что она осталась в 2014 году

ps. проблема не в /u/e

> Даже не вчитываясь в on вместо in... А где здесь проверка на то, что тебе валидные имена эх подсунули? Хотя бы на наличие точки и длину от 3 до 120 символов?

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

> В общем, как раз то, о чём я и говорил.

Нет. это то, о чём я говорил. Последние несколько дней.

> Не понимаю, чем это знание мне поможет в плане грядущей реализации своей ноды.

оформление полиси, соглашений, стандартов и прочего - это вообще не технология. это политика. сначала политика определяет стандарты, потом стандарты технологию. так было с ii. дважды.

Блин. я специально старался писать не ответы, а новые темы, чтобы не было обсуждение деталей, а всё опять сходится к обсуждению деталей. :)

> В современном мире применителя второго подхода взломают за считанные дни. Забывать о таком подходе надо.

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

Ещё в первоначальной версии было написано, что сторонники обоих подходов считают свой подход единственно верным.

Зря я две этих строчки удалил, видимо, хотя мне казалось, что так будет лучше :)

ps. Я считаю, что правильного подхода не существует.

> Ну теоретически если кто хранит мессаги в MySQL или SQLite, то время добавления можно и сохранять

так было в босфор. я ща гляжу на него, прикольная была штука, только клиентов и фетчеров для него не было :)

> Он не то чтобы его заменяет, а решает бОльшую задачу - sync только новых сообщений. При этом /x/h не нужен, так как решена более общая задача. Но хеши надо хранить для всех эх всех нод с которых мы фетчим...

x/h единственный валидный триггер. он бывает в двух состояниях "эха изменилась" и "эха не изменилась". всё остальное не даёт полных гарантий.

> Собственно это и есть краеугольный момент. Либо мы воспринимаем особенности ii проблемами либо нет. Я согласен, можно проявить аскетичность, смирение и "вложить" себя в базовый ii который предполагает:

Это не проблема. Это основа. Хотел вчера ответить revoltech, но отвечу сразу здесь.

ii это социальная сеть малых сообществ. Так она всегда и называлась. Она не про технологии, она про любительское программирование, радиолюбительство, клуб юного техника и прочие порождения Дворца Пионеров. Чтобы каждый мог собрать свою ноду и общаться со своим хомячком. Потому что это просто. Весь протокол постоянно упрощался. Какие вообще слайсы?

Ещё мне там понравилось, что второй человек уже указывает, что в выводе /u/e может быть мусор. Они походу вообще не понимают сути. Ты синкаешься с доверенным узлом по предельно формализированному и простому формату. Единственный вариант, когда там может быть мусор - это СБОЙ. И как можно в этой ситуации поступать "ну давайте что-нибудь попробуем вычленить". Да ты можешь получить 800 дублей или ещё чего похуже. Вся история и фидо, и ii, говорят об этом.

> Ты можешь мне сказать где ты? Вроде бы ты на пп1, но при этом я вижу в твоих сообщения обсуждения решений тогоже sf, h которые вроде бы демонстрируют что то из пп3.

меня не интересует стандарт. ВООБЩЕ. у меня есть /u/e, который проживёт ещё 100 лет и переживёт всех модернизаторов.

я просто напоминал о 2014 году, когда делали стандарт. сейчас 2024 год и опять делают стандарт. на этом всё. умному - достаточно.

О. Третий. Гы-гы, проблемы проектирования... попытка решить болезни роста прежде чем они возникнут - погубило не одну сотню проектов. ii выжил, и именно благодаря своему проектированию и своему позиционированию. С технологией у текущей сети нет проблем, вообще. Есть проблемы с контентом.

> Изменения ради изменений. Ты бы классно вписался в современную IT-индустрию с такими подходами.

я вообще не трогаю технологию. она по мне изначально идеальна. я про внедрение проекта, новых пользователей, новый софт и прочая инфраструктура - ничего этого нет. при Стали^W мне каждую неделю новые клиенты выходили :) была куча юзеров, эх и прочего. сейчас всё глухо, несколько месяцев активность вообще была околонулевая. Даже shaos свой форум в эху не переформатировал. :) Я думаю, если бы жизненные обстоятельства мне не помешали, и сеть и технология сейчас были бы куда популярнее. Сейчас я тоже хочу заняться именно контентом, есть несколько идей, но жизненные обстоятельства сейчас куда хуже, к сожалению. Попробую. Ваши форматы меня не интересуют вообще, idec я прочитал только несколько дней назад, новый не читал.

Я ПРОСТО НАПОМИНАЛ 2014. Делали формат, который ПОЛНОСТЬЮ совместим с ii, но при этом экономит трафик. Итог:
1.
2.

Мне, старому фидошнику, непонятно, зачем фетчить сразу несколько станций. :) лично я качаю только с shaos

ты бы хотя бы посмотрел, что они выдают :) у тебя нет http, по нему нет никакой отдачи.

> 2) Невозможно "чётко" подобрать лимит такого захлёста. Сколько надо ставить чтобы и разброс порядка не влиял и интенсивность чата? 100? А если сисоп уехал в круиз а за пол года его отсутствия пришло 10000 пользователей? Нет, не надёжно.

полный фетч периодически необходим. и он решает все вопросы. вопросы "уехал в круиз на полгода" тоже решает полный фетч. а лимиты, как и любой другой k/v, можно легко добавить вообще не ломая совместимость с любой версией ii, просто меняя endpoint (что было заложено изначально, когда схема /z менялась на схему /u)

но вообще причина не особо понятна. я опрашиваю shaos каждые 5 минут, сейчас слайсами раньше полным фетчем. до h/x и с полным фетчем это 12 мб в сутки (при этом я тяну rss-эхи). после h/x и с полным фетчем 2-4 мб в сутки. (со слайсами, кстати, трафик почему-то нифига не уменьшился). в http есть gzip, который тоже экономит трафик.

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

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

> Дык я и начинаю собирать свою ноду. Слайсы мне в этом вообще не помешают.

ты программист, наверное. а речь про любителей.

> А ты уверен, что ты сам-то суть понимаешь? Это не про доверенные узлы вообще. Для запроса /u/e пароль не нужен, тебе запрос с дичью вместо эхонеймов может прислать вообще кто угодно, когда угодно и в каком угодно количестве.

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

ps. при запросе (запросе от тебя) система автоматом разбирается. если есть файлик, то это эха с данными, если всё остальное - то это пустая эха. и ты выдаёшь такой же полностью корректный бандл, где просто перечисляется куча пустых эх. вот тебе вход, список, чего угодно, любой ахинеи. вот тебе выход - ответ на твой запрос, что эха КРАКОЗЯБЛ1 и эха КРАКОЗЯБЛ2 пусты. это полностью корректный и абсолютно формализуемый бандл. бандл состоит только из двух вещей, msgid и эхи, и выдаёт такой бандл, что бы у тебя не запросили вообще.

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

> Или сознательная атака.

то есть, тебя собирается атаковать собственный аплинк. И ТЫ ПРИ ЭТОМ ПЫТАЕШЬСЯ ВАЛИДИРОВАТЬ какие-то данные? ты вообще сам понимаешь, что говоришь - тебе дают заведомо некорректные данные, а ты говоришь "нет, не отлуп давать, а пытаться хоть что-то свалидировать, ВДРУГ ТАМ ЧТО-ТО хорошее?"

+++ memo:absurd

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

а, ну ещё проблема в сути вопроса - нахрена, чтобы навредить, давать НЕКОРРЕКТНЫЙ БАНДЛ??? вот тут вообще непонятно. логичнее давать абсолютно корректный бандл, содержащий, например каждый раз тысячу разных msgid с некорректными данными или просто со случайным флудом

> Не вижу смысла минимизировать число запросов.

ну, в 2014 это было проблемой, раз /e заменили на /u/e. а вообще запрос вещь дорогая, это и лишние tcp-фреймы, и лишняя нагрузка на сервер, и лишняя строка в логах :) упаковка в один запрос лучше в любом случае. иначе можно было бы на /m и /e остаться. и мы бы остались, если бы запросы не были столь дорогими, пришлось прикручивать изначально ненужные бандлы. я не знаю, в текущих реалиях можно было бы, если создавать сеть сейчас, остаться на /m и /e - это бы сильно всё упростило :)

> У меня и сейчас опрашивается в одном потоке одна эха и работает все быстро.

u/e для этого вообще не нужна, достаточно e/

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

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

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 кэшировать на сервере, чтобы уменьшить нагрузку на него