По идее на нодах со свободной регистрацией это должна быть единственная эха куда можно писать новичку, пока он не пройдёт проверку по полной программе ;)

Надо будет себе пометку на полях сделать...

Да, фетчер на Tcl. Пардон за трафик, тестировал туда-сюда.

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

А, и да, спасибо за тест, добавлю скоро опцию подмены юзерагента в tiifetch и tiipost.

> Пардон за трафик, тестировал туда-сюда.

Ну гугл тебе обогнать всё равно не удалось, так что ок ;)

С удовольствием, как только с tgi можно будет туда постить.

Кстати формат ответа неправильный:

ii/ok/repto/test
idec.talks
1729606618
revoltech
tgi,15
All
test

тест ответа

тут вместо repto/test надо писать repto/msgid где msgid является идентификатором сообщения на которое отвечаем...

Первоначальное сообщение было вот это: xXufIMsKzDC1FFJ0Dh1g

Второй тест ответа вроде ок

revoltech> С удовольствием, как только с tgi можно будет туда постить.

Не уверен что эта возможность вообще будет. Судя по всему сисоп забил на сеть. Подумываю сменить, но лень

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

revoltech> Интересно, существуют вообще таковые или нет? И если да, то как их найти?

Как минимум, существовали раньше. Как искать не знаю. Живы ли они тоже не знаю.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

revoltech>> Проверил — у тебя эта фича есть и работает, а вот на tgi нет.
revoltech>> Зачем её убирать, в принципе? Всё равно скрытые эхи в общем списке не видны. Неплохая же блог-платформа выходит. И да, мне как раз эта идея в изначальной документации понравилась тоже.
doesnm> Емнип блоги хоть и есть в IDEC (hugeping, tgi, difrex), но изначально они не задумывались ибо "ты подписываешься не на человека, а на контент"

Да фиг с ними с блогами. Я пообщаться с кем-то хочу не в общем пространстве, например. Или по какой-то новой теме. Зачем каждый раз сисопа дёргать? Если вырастет во что-то приличное, можно открыть и даже обмен между узлами начать, если не вырастет, то и пофиг.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

Сделал фетчер, учитывающи

й x/h.

у меня blcat.test, я не вижу смысла делать две тестовые эхи, а тем более их гонять :) тестовые обычно локальные эхи

shaos> А где /x/features ?

Нафиг /x/features, как по мне. Если слайсы не поддерживаются, нода просто отдаст всё из указанных эх.

> Нафиг /x/features, как по мне. Если слайсы не поддерживаются, нода просто отдаст всё из указанных эх.

проблема в том, что этот запрос выглядит, как эха, я не уверен, что на моей станции это сработает. если бы это был запрос /u/e/ea/ea/ea?s=-100:100, тогда бы посторонние ноды это проигнорировали

http://ii.blcat.ru/u/e/idec.talks/-100:100

idec.talks
nQi82oyWBVG04BKEAssb
[... cut ...]
vw94xxAktnhjmcpvvp7F
hua5b4LxCs1t9kF9HsTs
-100:100

А как тогда проверить, что оно нормально фетчится между нодами? ;)

а почему оно /u/e а не /x/e какое-нибудь. надо или делать ?s=X:X или /x/e, потому что запрос один, а реакции разные

Там же точки нету - там двоеточие
Значит проверку на соответствие имени эхи оно пройти не должно ;)

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

Это в каких таких эхах есть двоеточия в названии?

shaos> Там же точки нету - там двоеточие
shaos> Значит проверку на соответствие имени эхи оно пройти не должно ;)

Вот именно. Тоже хотел добавить.

Наверное старая нода должна ошибку вернуть если в запросе непонятное буквосочетание попалось, не?

Речь о том, как на это реагирует референсная реализация. Хреново :)

А поправить референсную реализацию? ;)

Стал забирать с тебя retro.talks

ну, во-первых, это единственные существующие реализации в сети, хранятся на github, моя нигде кроме этого сайта не хранится и начинать, наверное, надо, именно с них. не знаю, что будут делать клиенты с эхой -100:100 :)

А существующие реализации в сети не 100% IDEC уже? ;)

Ну я показал как моя станция на это реагирует

shaos> А где /x/features ?

А зачем она, если не будет расширений? Расширения были ошибкой.

shaos> Может их в виде /features.txt организовать? Всё равно это по сути статический текст…

Можно что угодно вертеть, но в стандарте этому не место.

+++ Caesium/0.4 RC1

>> Нафиг /x/features, как по мне. Если слайсы не поддерживаются, нода просто отдаст всё из указанных эх.
ahamai> проблема в том, что этот запрос выглядит, как эха, я не уверен, что на моей станции это сработает. если бы это был запрос /u/e/ea/ea/ea?s=-100:100, тогда бы посторонние ноды это проигнорировали

В тмени эхи не может быть двоеточия. Так что не выглядит. Ну и просто будет пустой индекс невалидной эхи в ответе. Это ничему не навредит.

+++ Caesium/0.4 RC1

ahamai> а почему оно /u/e а не /x/e какое-нибудь. надо или делать ?s=X:X или /x/e, потому что запрос один, а реакции разные

Делай как угодно. Стандарт есть стандарт. Большинство его соблюдает вполне успешно даже сейчас.

+++ Caesium/0.4 RC1

shaos> Наверное старая нода должна ошибку вернуть если в запросе непонятное буквосочетание попалось, не?

Надо на таверне проверить. Старше сейчас, вроде, ничего нет.

+++ Caesium/0.4 RC1

ahamai> Речь о том, как на это реагирует референсная реализация. Хреново :)

А у нас пока нет референсной реализации. Стало быть никак не отреагирует.

+++ Caesium/0.4 RC1

shaos> А существующие реализации в сети не 100% IDEC уже? ;)

У Ромы никогда не было IDEC-ноды. Блин. Научить фетчер работать без слайсов с некоторыми аплинками - задача на 2-3 лишние строки кода. Проблема высосана из пальца.

Если бы IDEC был ii, то он бы назывался ii.

+++ Caesium/0.4 RC1

ahamai> Ну я показал как моя станция на это реагирует

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

+++ Caesium/0.4 RC1

это как так? перечисляемые расширения были основной фишкой IDEC :(

вот например мой /x/features прямо сейчас:

u/e
u/push
list.txt
list.txt?h=1
listhsh.txt
blacklist.txt
x/c
x/h
x/file
x/filelist
node.json

Ну у него эхи без цифр, значит уже наполовину IDEC ;)

AL> Словарик будет отдельным документом.

Лучше в самом документе словарик иметь.

shaos> это как так? перечисляемые расширения были основной фишкой IDEC :(

Ну а теперь три из них являются частью стандарта, а остальные — нет. Вообще нет. Если я всё правильно понял.

revoltech> три из них являются частью стандарта

Пардон, /u/push не увидел. В таком варианте — даже четыре.

А как же делать кастомные расширения теперь?...

shaos> это как так? перечисляемые расширения были основной фишкой IDEC :(

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

А так, никто не мешает лепить любые расширения у себя. Просто не надо полагаться на то, что их будут поддерживать. Ситуация ровно та же, только более свободная.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos> Ну у него эхи без цифр, значит уже наполовину IDEC ;)

Да не было в ii требования эх с циферками. Это была просто договорённость, а не стандарт. Эхи без циферек там прекрасно работали всю дорогу.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

Вобщем мне никогда не нравилось, что в /u/point у вас пароль идёт прямым текстом (ну скажем https:// и POST ещё ок, но если речь идёт о ретроклиентах, которые умеют только http:// ?)

Для несекьюрных каналов можно попробовать альтернативный способ аутентификации пользователя скажем через подпись HMAC-RIPEMD-160-96. Алгоритм HMAC это hash-based message authentication code (код аутентификации сообщения на основе хеша), который использует один секретный ключ, известный обеим сторонам, и над каким-то стандартным хешом - в данном случае это RIPEMD-160 (алгоритм хеширования с наименьшей длиной хеша, который ещё не сломали), причём этот алгоритм был представлен ещё в 1992 году (т.е. ему уже 32 года!) - он в частности используется в биткоине (вместе с SHA-256). Ну и для укорачивания такой подписи берутся первые 96 бит (12 байт). Это всё стандартизовано на уровне RFC:

RFC2104 (February 1997) - HMAC: Keyed-Hashing for Message Authentication
https://datatracker.ietf.org/doc/html/rfc2104

RFC2286 (February 1998) - Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128
https://datatracker.ietf.org/doc/html/rfc2286

RFC2857 (June 2000) - The Use of HMAC-RIPEMD-160-96 within ESP and AH
https://datatracker.ietf.org/doc/html/rfc2857

Конечно было бы лучше использовать SHA-256, но RIPEMD-160 проще в вычислительном плане, а нам надо будет его считать на слабых платформах. Вобщем суть такая - секретный ключ (это может быть строка текста длиной до 20 символов) загружается на узел через секьюрное соединение (https:// или скажем через емейл сисопу) один раз. Далее когда пользователь хочет отправить сообщение на узел (в описанном выше формате) по несекьюрному каналу, то его клиент считает по телу сообщения и секретному ключу подпись HMAC-RIPEMD-160-96 и посылает 12-байтовый результат как PAUTH (можно наверное в base64url его завернуть), а сервер при получении будет считать по полученному телу сообщения свой вариант HMAC-RIPEMD-160-96 и будет сравнивать с присланной подписью - если результат совпадёт, то отправитель считается аутентифицирован (плюс будет проверена целостность самого сообщения). До кучи в урл можно добавить кодировку, на тот случай если софт поинта не поддерживает UTF8:

URL/u/point2/koi7/B64AUTH/B64STRING

для больших сообщений можно задействовать метод POST:

URL/u/point2/koi7/B64AUTH
TEXT

причём тело сообщения в данном случае можно заслать прямым текстом без кодировки (Content-Type: plain/text)

Обсуждаем? :)

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

Да - в /x/features поддерживаемые кодировки можно перечислить таким макаром:

/u/point2/utf8
/u/point2/koi7
/u/point2/koi8r
/u/point2/cp866
/u/point2/cp1251

При получении узел будет сам переконвечивать это в UTF-8 (если пришёл не UTF-8)

https://github.com/idec-net/new-docs/blob/master/iibonds.md

Минусы оригинального ii:

- Название эхоконференций от 3 до 60 символов, эха обязана заканчиваться на постфикс (точка и число).
- Когда в эхе накапливается по 3000 сообщений и более, получать индекс со станции становится долго.
- Из-за предыдущей причины приходилось "перекатывать" эхи, периодически переходя из одной в другую

Наши улучшения

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

ВСЁ!

AL>> Словарик будет отдельным документом.
tuple> Лучше в самом документе словарик иметь.

Словарик не является частью стандарта.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos>> это как так? перечисляемые расширения были основной фишкой IDEC :(
revoltech> Ну а теперь три из них являются частью стандарта, а остальные — нет. Вообще нет. Если я всё правильно понял.

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

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos> А как же делать кастомные расширения теперь?...

Я ж говорю, важна поддержка стандарта. Что там кто себе сбоку наворотил, это их личное дело и не должно влиять на всю сеть.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos> Вобщем мне никогда не нравилось, что в /u/point у вас пароль идёт прямым текстом (ну скажем https:// и POST ещё ок, но если речь идёт о ретроклиентах, которые умеют только http:// ?)
shaos> Для несекьюрных каналов можно попробовать альтернативный способ аутентификации пользователя скажем через подпись HMAC-RIPEMD-160-96. Алгоритм HMAC это hash-based message authentication code (код аутентификации сообщения на основе хеша), который использует один секретный ключ, известный обеим сторонам, и над каким-то стандартным хешом - в данном случае это RIPEMD-160 (алгоритм хеширования с наименьшей длиной хеша, который ещё не сломали), причём этот алгоритм был представлен ещё в 1992 году (т.е. ему уже 32 года!) - он в частности используется в биткоине (вместе с SHA-256). Ну и для укорачивания такой подписи берутся первые 96 бит (12 байт). Это всё стандартизовано на уровне RFC:
shaos> RFC2104 (February 1997) - HMAC: Keyed-Hashing for Message Authentication
shaos> https://datatracker.ietf.org/doc/html/rfc2104
shaos> RFC2286 (February 1998) - Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128
shaos> https://datatracker.ietf.org/doc/html/rfc2286
shaos> RFC2857 (June 2000) - The Use of HMAC-RIPEMD-160-96 within ESP and AH
shaos> https://datatracker.ietf.org/doc/html/rfc2857
shaos> Конечно было бы лучше использовать SHA-256, но RIPEMD-160 проще в вычислительном плане, а нам надо будет его считать на слабых платформах. Вобщем суть такая - секретный ключ (это может быть строка текста длиной до 20 символов) загружается на узел через секьюрное соединение (https:// или скажем через емейл сисопу) один раз. Далее когда пользователь хочет отправить сообщение на узел (в описанном выше формате) по несекьюрному каналу, то его клиент считает по телу сообщения и секретному ключу подпись HMAC-RIPEMD-160-96 и посылает 12-байтовый результат как PAUTH (можно наверное в base64url его завернуть), а сервер при получении будет считать по полученному телу сообщения свой вариант HMAC-RIPEMD-160-96 и будет сравнивать с присланной подписью - если результат совпадёт, то отправитель считается аутентифицирован (плюс будет проверена целостность самого сообщения). До кучи в урл можно добавить кодировку, на тот случай если софт поинта не поддерживает UTF8:
shaos> URL/u/point2/koi7/B64AUTH/B64STRING
shaos> для больших сообщений можно задействовать метод POST:
shaos> URL/u/point2/koi7/B64AUTH
shaos> TEXT
shaos> причём тело сообщения в данном случае можно заслать прямым текстом без кодировки (Content-Type: plain/text)
shaos> Обсуждаем? :)

Да чего тут обсуждать? Нормальное расширение -- делай.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos> Ну т.е. теперь исключается сама возможность торкнуться на узел специальным образом, чтобы узнать одним списком а какие собственно расширения он поддерживает...

Почему? Хочешь сказать, что со старым стандартом исключалась сама возможность получить у тебя /list.txt с хешиками?

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos> https://github.com/idec-net/new-docs/blob/master/iibonds.md
shaos> Минусы оригинального ii:
shaos> - Название эхоконференций от 3 до 60 символов, эха обязана заканчиваться на постфикс (точка и число).
shaos> - Когда в эхе накапливается по 3000 сообщений и более, получать индекс со станции становится долго.
shaos> - Из-за предыдущей причины приходилось "перекатывать" эхи, периодически переходя из одной в другую

Имеет смысл читать ii, а не кривую документацию по IDEC.

shaos> Наши улучшения
shaos> - Название эх от 3 до 120 символов, из них обязательный символ - только точка (без цифровых постфиксов)
shaos> - Небольшие расширения, которые помогают экономить трафик, защищают от переполнения эх и делают ещё пару полезных вещей.
shaos> ВСЁ!

Да.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

https://vk.com/@hatahack-ii-idec

> На официальном сайте сказано о наличии “филиала” IDEC в сети Tor по адресу mtgbjhifvi4sl773.onion, но сейчас он не работает (закрыт по причине непопулярности). Клиенты IDEC Mobile и CutieFeed по заверениям разработчика поддерживают настройки прокси, и в том числе успешно тестировались им на сетях Tor и i2p.

AL> Имеет смысл читать ii, а не кривую документацию по IDEC.

Между прочим, а где её найти? На лоре ссылки на умерший 51.ru, который тот самый с девочками, судя по веб-архиву. В интернете - IDEC.

shaos> Да - в /x/features поддерживаемые кодировки можно перечислить таким макаром

Вот это в стандарт точно тащить не надо. Кому в 2024 году нужно что-то, кроме UTF-8? А всякие кои и 1251 за пределами постсовка и раньше никому не нужны были.

По передаче паролей — ума не приложу, как люди с паролями по plain http раньше жили. Конечно, времена поменялись, но зачем городить огород с хэшами? Не проще ли сделать что-то типа HOTP/TOTP и использовать одноразовый код в качестве authstring, если уж так приспичило? Но опять же, это вопрос реализации, в стандарт это тоже тащить не стоит, имхо.

tuple> > На официальном сайте сказано о наличии “филиала” IDEC в сети Tor по адресу mtgbjhifvi4sl773.onion, но сейчас он не работает (закрыт по причине непопулярности)

Это очень старый onion-адрес, сейчас они гораздо длиннее. Такие уже даже давно не резолвятся вроде бы.

tuple>> > На официальном сайте сказано о наличии “филиала” IDEC в сети Tor по адресу mtgbjhifvi4sl773.onion, но сейчас он не работает (закрыт по причине непопулярности)
revoltech> Это очень старый onion-адрес, сейчас они гораздо длиннее. Такие уже даже давно не резолвятся вроде бы.

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

AL>> Имеет смысл читать ii, а не кривую документацию по IDEC.
tuple> Между прочим, а где её найти? На лоре ссылки на умерший 51.ru, который тот самый с девочками, судя по веб-архиву. В интернете - IDEC.

Не знаю. Мы уже давно отдельно.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

Ну я добавил их в /x/features и типа сразу видно что оно у меня есть ;)

> Да.

Ну дык значит bloat уже на половину IDEC :)

O - вот этот текст я искал ;)

Оригинал давно протух…

Ну это типа кастомное расширение

HOTP потяжелее наверное - и там ведь ещё больший «огород с хешами» ?

blcat

чортова автоисправлялка…

> Вот это в стандарт точно тащить не надо. Кому в 2024 году нужно что-то, кроме UTF-8? А всякие кои и 1251 за пределами постсовка и раньше никому не нужны были.

cp1252 ещё можно добавить т.к. оно ещё вполне в ходу :)

https://en.wikipedia.org/wiki/Windows-1252

"It is the most-used single-byte character encoding in the world. Although almost all websites now use the multi-byte character encoding UTF-8, as of July 2024 1.2%[4] of websites declared ISO 8859-1 which is treated as Windows-1252 by all modern browsers (as demanded by the HTML5 standard[5]), plus 0.3% declared Windows-1252 directly,[4][6] for a total of 1.5%. Some countries or languages show a higher usage than the global average, in 2024 Brazil according to website use, use is at 3.4%,[7] and in Germany at 2.7%.[8][9] (these are the sums of ISO-8859-1 and CP-1252 declarations)."

shaos> HOTP потяжелее наверное - и там ведь ещё больший «огород с хешами» ?

Нет, не больший. И преимущество оного в том, что можно в случае с TOTP вынести этот нюанс в какой-нибудь Aegis/Authy/гугловский аутентификатор, а в случае с HOTP — вообще в отдельный аппаратный ключ. И не нагружать бедный ретроклиент.

Ну вот - аппаратный ключ городить ещё

А на сторонние аутентификаторы совсем не хочется завязываться - всё должно работать даже в случае тотального отключения глобальных сервисов...

shaos> А на сторонние аутентификаторы совсем не хочется завязываться - всё должно работать даже в случае тотального отключения глобальных сервисов...

Сторонний аутентификатор, работающий так же, как и всё вышеперечисленное, пишется максимум за полчаса на любом мейнстримном ЯП.

https://www.rfc-editor.org/rfc/rfc6238

Кстати - если этот номер перехватить, то его ведь можно тут же зареюзать пока время не прощло?

В моём случае зареюзать не получится т.к. оно зависит от контента

" All the communications SHOULD take place over a secure channel, e.g.,
Secure Socket Layer/Transport Layer Security (SSL/TLS) [RFC5246] or
IPsec connections [RFC4301]."

Это show stopper...

shaos> Кстати - если этот номер перехватить, то его ведь можно тут же зареюзать пока время не прощло?

Нельзя. Ну как минимум сервер должен такие попытки пресекать и заставлять пользователя ждать следующее 30-секундное окно. Это в случае TOTP.

Легитимный пользователь в пределах 30 секунд 2 сообщения не отправит. А если надо, пусть отправляет через /u/push.

shaos> " All the communications SHOULD take place over a secure channel, e.g.,
shaos> Secure Socket Layer/Transport Layer Security (SSL/TLS) [RFC5246] or
shaos> IPsec connections [RFC4301]."
shaos>
shaos> Это show stopper...

Это should, а не must, а на самом деле пофигу вообще. Между клиентом и сервером только начальная регистрация ключа должна быть секьюрной.

should = must

Американцы не любят слово must

т.е. ты предлагаешь вводить код ручками при каждой посылке? Нет спасибо :)

В моём варианте всё считается автоматически - нажал на Send и оно ушло…

shaos> Ну я добавил их в /x/features и типа сразу видно что оно у меня есть ;)

Ну так и оставь их в /x/features. Никто ж не мешает ;)

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos>> Кстати - если этот номер перехватить, то его ведь можно тут же зареюзать пока время не прощло?
revoltech> Нельзя. Ну как минимум сервер должен такие попытки пресекать и заставлять пользователя ждать следующее 30-секундное окно. Это в случае TOTP.
revoltech> Легитимный пользователь в пределах 30 секунд 2 сообщения не отправит. А если надо, пусть отправляет через /u/push.

Ты шутишь сейчас? Лигитимный пользователь может подряд сколько угодно сообщений подряд отправлять. А /u/push вообще не для пользователей, а для других узлов сети. В том же цезии я не отправляю по одному сообщению, а отвечаю сразу на всё, что нового прилетело, а потом они пачкой по одному улетают. Зачем ломать клиенты?

Или ты предполагаешь, что клиент, отправив сообщение, будет ждать 30 секунд перед отправкой следующего? Нафиг такой клиент нужен тогда?

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

А у пуша какой пароль - пользовательский или особый сисоповский? Надо код ii-php поглядеть…

В новой спеке написано «строка авторизации узла» что по видимому намекает на специальный пароль

Тоже надо сделать свой вариант :)

Кстати зачем там echoarea если имя эти есть в каждом сообщении?…

А какой вообще формат срезов: /u/m/эха/срез/эха/срез или как?

shaos> А у пуша какой пароль - пользовательский или особый сисоповский? Надо код ii-php поглядеть…

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

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos> В новой спеке написано «строка авторизации узла» что по видимому намекает на специальный пароль
shaos> Тоже надо сделать свой вариант :)
shaos> Кстати зачем там echoarea если имя эти есть в каждом сообщении?…

Для обратной совместимости. Пуши к нам тоже из ii приехали, вроде.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos> А у пуша какой пароль - пользовательский или особый сисоповский? Надо код ii-php поглядеть…

Емнип он совпадает с паролем к sysop.php

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

ahamai> А какой вообще формат срезов: /u/m/эха/срез/эха/срез или как?

Кстати, да, присоединяюсь к вопросу. Как в одном запросе слайсить сразу несколько эх с разными смещениями и лимитами? Например, мы запрашиваем содержимое трёх эх и выяснили, что из первой надо забрать только 3 последних сообщения, из второй — 10, а из третей — 50. И что, здесь три отдельных запроса городить придётся?

ahamai> А какой вообще формат срезов: /u/m/эха/срез/эха/срез или как?

Например: https://club.hugeping.ru/u/e/idec.talks/-1:1

AL> Внёс правки по итогам замечаний и предложений. URL тот же: http://s.spline-online.ru/idec.html
AL> PS: Перед окончательной публикацией дождусь реакции hugeping.

Вроде бы всё нормально! У меня был вопрос про push как часть стандарта. Он нужен только когда нода не имеет реального IP адреса? С другой стороны, как тогда поинта забирают с неё сообщения? Какой-то изолированный сегмент сети?

С другой стороны, всё равно эта часть возможна только за счёт предварительной договорённости нод (выдача пароля), так что думаю - наличие push в стандарте не приговор, а лишь означает, что ПРИ НЕОБХОДИМОСТИ этот механизм может использоваться. То-есть, для работы в обычном режиме нам по прежнему push не нужен...

Про фичи - по идее они полезны были бы для определения, например, поддерживает ли нода слайсы. Но на практике, tgistation их не поддерживает, но в фичах есть u/e. В общем, я не жалею, что их больше нет. Стало проще. Меньше комбинаций. Ориентироваться можно на фактически получаемые данные.

P.S. Я бы оставил ещё повисеть драфт, мы же никуда не спешим? Вдруг кто-то что-то вспомнит. :)

hugeping> ahamai> А какой вообще формат срезов: /u/m/эха/срез/эха/срез или как?
hugeping>
hugeping> Например: https://club.hugeping.ru/u/e/idec.talks/-1:1

Вопрос в том, что делать, когда в запросе НЕСКОЛЬКО эх. Можно ли указать диапазоны отдельно для каждой?

Это одна эха

hugeping>> ahamai> А какой вообще формат срезов: /u/m/эха/срез/эха/срез или как?
hugeping>>
hugeping>> Например: https://club.hugeping.ru/u/e/idec.talks/-1:1

revoltech> Вопрос в том, что делать, когда в запросе НЕСКОЛЬКО эх. Можно ли указать диапазоны отдельно для каждой?

Не делал никогда так, но в стандарте написано что нет.

/u/e/area.one/area.two/0:10 запрашивает первые десять сообщений в индексе, а /u/e/area.one/area.two/-10:10 запрашивает последние десять сообщений в индексе.

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

2Shaos, хочу с тебя дёргать только последних 100 хедеров, как у тебя нода устроена?

hugeping> P.S. Я бы оставил ещё повисеть драфт, мы же никуда не спешим? Вдруг кто-то что-то вспомнит. :)

Солидарен. Оставить повисеть на неделю-две.

AL>> Внёс правки по итогам замечаний и предложений. URL тот же: http://s.spline-online.ru/idec.html
AL>> PS: Перед окончательной публикацией дождусь реакции hugeping.
hugeping> Вроде бы всё нормально! У меня был вопрос про push как часть стандарта. Он нужен только когда нода не имеет реального IP адреса? С другой стороны, как тогда поинта забирают с неё сообщения? Какой-то изолированный сегмент сети?

Ну по сути да. Если вдруг есть узел в сети с ограниченным доступом в интернет, например. Поинты у него локальные, а наружу только пуши до аплинка. Ситуация гипотетическая и с каждым годом всё менее вероятная, хотя, с другой стороны, с этими всеми взаимными блокировками может оказаться всякое :)

hugeping> С другой стороны, всё равно эта часть возможна только за счёт предварительной договорённости нод (выдача пароля), так что думаю - наличие push в стандарте не приговор, а лишь означает, что ПРИ НЕОБХОДИМОСТИ этот механизм может использоваться. То-есть, для работы в обычном режиме нам по прежнему push не нужен...

Ну да. В обычном режиме push не нужен.

hugeping> Про фичи - по идее они полезны были бы для определения, например, поддерживает ли нода слайсы. Но на практике, tgistation их не поддерживает, но в фичах есть u/e. В общем, я не жалею, что их больше нет. Стало проще. Меньше комбинаций. Ориентироваться можно на фактически получаемые данные.

Ну вот не будет фич. Будет просто стандарт. Остальное вообще не важно вне рамок каких-то локальных приколов.

hugeping> P.S. Я бы оставил ещё повисеть драфт, мы же никуда не спешим? Вдруг кто-то что-то вспомнит. :)

Ну спешить некуда.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

ahamai>> А какой вообще формат срезов: /u/m/эха/срез/эха/срез или как?
revoltech> Кстати, да, присоединяюсь к вопросу. Как в одном запросе слайсить сразу несколько эх с разными смещениями и лимитами? Например, мы запрашиваем содержимое трёх эх и выяснили, что из первой надо забрать только 3 последних сообщения, из второй — 10, а из третей — 50. И что, здесь три отдельных запроса городить придётся?

Бери один по максимальному смещению.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

hugeping>> ahamai> А какой вообще формат срезов: /u/m/эха/срез/эха/срез или как?
hugeping>>
hugeping>> Например: https://club.hugeping.ru/u/e/idec.talks/-1:1
revoltech> Вопрос в том, что делать, когда в запросе НЕСКОЛЬКО эх. Можно ли указать диапазоны отдельно для каждой?

Нельзя, так как незачем.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

Ничё не понял. Если щас задать несколько эх и дать срез, он со всех по n сообщений запросит или только с последнего

Вечером на shaos потестю. Если первое, то мне подходит

https://sprinternet.io/iii/u/e/lor.opennet/bot.habr.rss/-2:2

lor.opennet
xfSBW60zRzlgSwVk76AQ
LhwoSH409gDoNlImRkqj
bot.habr.rss
qXIZLzo3Qe9lx8MA8agu
AAGRBdSX5ijxRWvXecPm

ок

другие станции

http://hugeping.tk/u/e/retro.talks/idec.talks/-2:2

retro.talks
5B3Tra1DRJEcymDcA6Gi
XOjs0DTBN77YYkJT2drY
idec.talks
Jr1i7Uh3aExR45L4mILq
lQojMgQzCqNwlULJtw3g

думаю, это и есть стандарт.

2shaos - я с тебя буду грабить только последние 100 сообщений. и так благодаря /x/h трафик между станциями упал с 12 мб до 2 мб, а так вообще урежется :)

ahamai> Ничё не понял. Если щас задать несколько эх и дать срез, он со всех по n сообщений запросит или только с последнего

Со всех запросит. В стандарте есть пример, я его прислал. Но ты похоже его даже не читал.

https://club.hugeping.ru/u/e/idec.talks/std.hugeping/-1:1

Тогда не понял, почему стандарт такой, если в каждой эхе разное количество новых сообщений. :) Ладно, поняли-разобрались. Стандарт читал но как-то не задумывался об этом, задумался только сегодня в тронвае :)

2shaos - фетчеры обновил

у меня sf работает так: запрос вида /u/e/эха1/эха2/эха3?sf=хэш1/хэш2/хэш3, и она ищет указанные хэши в эхах, если находит, начинает выдачу эх с них. сначала не вклчая сами хэшN, но несколько дней назад я сделал, чтобы включали, на всякий случай, 21 байта не жалко, зато можно убедиться, какой именно хэш