> Зачем рассылка при общении тет-а-тет?

> Как быть с почтой, когда IDEC будет использоваться без интернета?

> А при чём тут почтовая рассылка?

> Это вообще не то самое. Это костыль сбоку, который Пётр прилепил на безрыбье.

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

>> Зачем рассылка при общении тет-а-тет?
Anotheroneuser> Ну если будет общий тет-а-тет

>> Как быть с почтой, когда IDEC будет использоваться без интернета?
Anotheroneuser> Это для меня уже сложный вопрос, потому что я не знаю, как IDEC можно использовать без интернета..

>> А при чём тут почтовая рассылка?
Anotheroneuser> Мне почему-то казалось, что она — быстрейший способ и можно начать пользоваться ею прямо сейчас.

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

AL> Ну idec позволяет производить обмен информацией по любому каналу передачи данных. Хоть флешками. Просто пока что интернет это самый доступный вариант.

>>> А при чём тут почтовая рассылка?
Anotheroneuser>> Мне почему-то казалось, что она — быстрейший способ и можно начать пользоваться ею прямо сейчас.
AL> Ну как альтернатива рассылке здесь и сейчас есть эха. Не требует участия третьей стороны или настройки своего почтового сервера.

+++ Caesium/0.4 RC1

Anotheroneuser> Кстати, я подписался на скрытоэху. Как мне теперь передать её остальным?

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

Anotheroneuser>> Кстати, я подписался на скрытоэху. Как мне теперь передать её остальным?

AL> Напиши анонс, например, в эху idec.talks. Там уже пользователи клуба сразу подтянутся, а остальные по мере подключения других узлов сети.

Какая же это тогда скрытоэха? Если название эхи известно, то мы всё так же общаемся у всех на виду.

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

Anotheroneuser>>> Кстати, я подписался на скрытоэху. Как мне теперь передать её остальным?

AL>> Напиши анонс, например, в эху idec.talks. Там уже пользователи клуба сразу подтянутся, а остальные по мере подключения других узлов сети.

vit01> Какая же это тогда скрытоэха? Если название эхи известно, то мы всё так же общаемся у всех на виду.

Не обратил внимания чтт речь о скрытоэхе.

Вообще, считаю скрытоэхой всё, чего нет в list.txt =)

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

AL> Вообще, считаю скрытоэхой всё, чего нет в list.txt =)

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

AL> ...Нужно не прятаться, а делиться. Для разобщения есть целый интернет, а мы тут для другого.

AL>> ...Нужно не прятаться, а делиться. Для разобщения есть целый интернет, а мы тут для другого.
Anotheroneuser> Всё верно, так и есть. Но могут же некоторые мысли быть неподготовленными, преждевременными.
Anotheroneuser> Допустим, когда люди снимают кино, не делятся же они подробностями съёмки. В таком духе))сайты

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

vit01>> Мы уже давно хотим ввести нетмейл, но всё никак не договоримся :)

AL> Я планирую им заняться сразу после того, как в очередной раз подниму вопрос о u/point через POST-запросы и отказ от ограничения на 64 килобайта =)

Насчёт /u/point через POST запросы не понимаю, о чём ты. Оно и так в большинстве реализаций через POST пашет, см. в первоисточники.

https://github.com/idec-net/ii-db-utils/blob/master/sender.py
https://ii-net.tk/idec-doc/?p=protocol

Насчёт лимита в 64 килобайта я против :)
Клиенты не будут переваривать огромные сообщения и начнут тормозить (IDEC Mobile уже подтормаживает на больших рассказах из lit.14 и creepy.14). А ещё появляется риск засорения базы данных на серваке.

Если у поинта есть дневной лимит на количество сообщений, то мы точно знаем, что он за 1 день не вылетит за лимит в N мегабайт.

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

vit01>>> Мы уже давно хотим ввести нетмейл, но всё никак не договоримся :)
AL>> Я планирую им заняться сразу после того, как в очередной раз подниму вопрос о u/point через POST-запросы и отказ от ограничения на 64 килобайта =)
vit01> Насчёт /u/point через POST запросы не понимаю, о чём ты. Оно и так в большинстве реализаций через POST пашет, см. в первоисточники.
vit01> https://github.com/idec-net/ii-db-utils/blob/master/sender.py
vit01> https://ii-net.tk/idec-doc/?p=protocol

vit01> Насчёт лимита в 64 килобайта я против :)

vit01> Клиенты не будут переваривать огромные сообщения и начнут тормозить (IDEC Mobile уже подтормаживает на больших рассказах из lit.14 и creepy.14). А ещё появляется риск засорения базы данных на серваке.

vit01> Если у поинта есть дневной лимит на количество сообщений, то мы точно знаем, что он за 1 день не вылетит за лимит в N мегабайт.

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

vit01>> Насчёт /u/point через POST запросы не понимаю, о чём ты. Оно и так в большинстве реализаций через POST пашет, см. в первоисточники.
vit01>> https://github.com/idec-net/ii-db-utils/blob/master/sender.py
vit01>> https://ii-net.tk/idec-doc/?p=protocol

AL> В стандарте этого нет.

Вот я тебе скинул ссылку на стандарт, на нашу же документацию, там чётко написано, процитирую ещё раз:

> GET /u/point/pauth/tmsg или POST /u/point
> ...
> В случае POST параметры называются так же: pauth и tmsg.

Поддержка POST была всегда, ещё со времён Ромы.

Можешь глянуть вот сюда, это первая версия ii-php, коммит от 6 апреля 2014, даже тут оно есть, потому что в стандарте было зашито изначально:

https://github.com/idec-net/ii-php/commit/c5b7d89b28520d189631f20a72deb0c4a9c35054

vit01>> Клиенты не будут переваривать огромные сообщения и начнут тормозить (IDEC Mobile уже подтормаживает на больших рассказах из lit.14 и creepy.14). А ещё появляется риск засорения базы данных на серваке.

AL> Если программа тормозит от 64 килобайт текста, то значит с программой что-то не так. А засрать базу никто не мешает и так. Скрипт пишется на коленке и можно тысячи сообщений отправить по несколько десятков байт каждое. И это будет большим уроном, чем одно сообщение в мегабайт.

Клиент занимается парсингом цитат, блоков кода, подсветки и так далее. Построчно, на регулярных выражениях. И не забывай, что sqlite не очень шустрый, особенно на мобилках. Чтобы грузить все сообщения мгновенно, придётся грузить их все фоном в ОЗУ (потребление вырастет очень сильно), и для сообщений каждое в мегабайт 20-30 обход регулярными выражениями - вещь крайне печальная. CutieFeed делает синхронные запросы в базу, а IDEC Mobile - заранее, опережая пользователя на одно сообщение. Но, тем не менее, репарсинг и рендеринг в HTML заставляет и его на больших сообщениях подтормаживать.

Насчёт урона тысячи сообщений по десятку байт. Больше опасаюсь, что спамеры будут слать тысячи сообщений по десятку мегабайт, а не байт.

Просто если я вижу, что клиент начал скачивать 10 000 сообщений, то сразу же могу прибить клиент (отказаться от получения), потому что знаю, что каждое из этих сообщений не превышает 64 килобайта. Если приходит 100 сообщений каждое размером до 10-20 мегабайт, то ты плохо понимаешь, что там внутри. И обнаруживаешь, что клиент жрёт гигабайты трафика, уже ПОСЛЕ того, как эти сообщения скачал. Это утеря контроля пользователя над своим трафиком и над своими ресурсами.

vit01>> Если у поинта есть дневной лимит на количество сообщений, то мы точно знаем, что он за 1 день не вылетит за лимит в N мегабайт.

AL> А если нет? Моя нода, например, не имеет и не будет иметь такого ограничения. Если же это защита от случайных флудеров на узлах с авторегистрацией, то регистрацию можно также проходить автоматически и срать в сеть тысячами мусорных сообщений. Урон по прежнему будет больше, чем одно сообщение в мегабайт.

Так у ответственных нододержателей есть лимит ещё и на количество зарегистрировавшихся в день, и на количество сфетченного в день.

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

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

vit01>>> Насчёт /u/point через POST запросы не понимаю, о чём ты. Оно и так в большинстве реализаций через POST пашет, см. в первоисточники.
vit01>>> https://github.com/idec-net/ii-db-utils/blob/master/sender.py
vit01>>> https://ii-net.tk/idec-doc/?p=protocol
AL>> В стандарте этого нет.
vit01> Вот я тебе скинул ссылку на стандарт, на нашу же документацию, там чётко написано, процитирую ещё раз:
>> GET /u/point/pauth/tmsg или POST /u/point
>> ...
>> В случае POST параметры называются так же: pauth и tmsg.
vit01> Поддержка POST была всегда, ещё со времён Ромы.

vit01>>> Клиенты не будут переваривать огромные сообщения и начнут тормозить (IDEC Mobile уже подтормаживает на больших рассказах из lit.14 и creepy.14). А ещё появляется риск засорения базы данных на серваке.
AL>> Если программа тормозит от 64 килобайт текста, то значит с программой что-то не так. А засрать базу никто не мешает и так. Скрипт пишется на коленке и можно тысячи сообщений отправить по несколько десятков байт каждое. И это будет большим уроном, чем одно сообщение в мегабайт.
vit01> Клиент занимается парсингом цитат, блоков кода, подсветки и так далее. Построчно, на регулярных выражениях. И не забывай, что sqlite не очень шустрый, особенно на мобилках. Чтобы грузить все сообщения мгновенно, придётся грузить их все фоном в ОЗУ (потребление вырастет очень сильно), и для сообщений каждое в мегабайт 20-30 обход регулярными выражениями - вещь крайне печальная. CutieFeed делает синхронные запросы в базу, а IDEC Mobile - заранее, опережая пользователя на одно сообщение. Но, тем не менее, репарсинг и рендеринг в HTML заставляет и его на больших сообщениях подтормаживать.
vit01> Насчёт урона тысячи сообщений по десятку байт. Больше опасаюсь, что спамеры будут слать тысячи сообщений по десятку мегабайт, а не байт.

vit01> Просто если я вижу, что клиент начал скачивать 10 000 сообщений, то сразу же могу прибить клиент (отказаться от получения), потому что знаю, что каждое из этих сообщений не превышает 64 килобайта. Если приходит 100 сообщений каждое размером до 10-20 мегабайт, то ты плохо понимаешь, что там внутри. И обнаруживаешь, что клиент жрёт гигабайты трафика, уже ПОСЛЕ того, как эти сообщения скачал. Это утеря контроля пользователя над своим трафиком и над своими ресурсами.

vit01>>> Если у поинта есть дневной лимит на количество сообщений, то мы точно знаем, что он за 1 день не вылетит за лимит в N мегабайт.
AL>> А если нет? Моя нода, например, не имеет и не будет иметь такого ограничения. Если же это защита от случайных флудеров на узлах с авторегистрацией, то регистрацию можно также проходить автоматически и срать в сеть тысячами мусорных сообщений. Урон по прежнему будет больше, чем одно сообщение в мегабайт.
vit01> Так у ответственных нододержателей есть лимит ещё и на количество зарегистрировавшихся в день, и на количество сфетченного в день.
vit01> Не будет одного сообщения в мегабайт. Будут сразу же 1000 сообщений по 10 мегабайт каждое, и твой клиент упадёт, прогружая их все в оперативку и раскрашивая цитаты. Или будет так тормозить, что им невозможно будет пользоваться.

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

vit01>> Клиент занимается парсингом цитат, блоков кода, подсветки и так далее. Построчно, на регулярных выражениях. И не забывай, что sqlite не очень шустрый, особенно на мобилках. Чтобы грузить все сообщения мгновенно, придётся грузить их все фоном в ОЗУ (потребление вырастет очень сильно), и для сообщений каждое в мегабайт 20-30 обход регулярными выражениями - вещь крайне печальная. CutieFeed делает синхронные запросы в базу, а IDEC Mobile - заранее, опережая пользователя на одно сообщение. Но, тем не менее, репарсинг и рендеринг в HTML заставляет и его на больших сообщениях подтормаживать.
vit01>> Насчёт урона тысячи сообщений по десятку байт. Больше опасаюсь, что спамеры будут слать тысячи сообщений по десятку мегабайт, а не байт.

AL> Парсинг штука тяжёлая, но зачем обходить текст построчно, если рендеришь регулярками и в html?

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

Кстати, этот алгоритм я у тебя позаимствовал откуда-то

vit01>> Просто если я вижу, что клиент начал скачивать 10 000 сообщений, то сразу же могу прибить клиент (отказаться от получения), потому что знаю, что каждое из этих сообщений не превышает 64 килобайта. Если приходит 100 сообщений каждое размером до 10-20 мегабайт, то ты плохо понимаешь, что там внутри. И обнаруживаешь, что клиент жрёт гигабайты трафика, уже ПОСЛЕ того, как эти сообщения скачал. Это утеря контроля пользователя над своим трафиком и над своими ресурсами.

AL> Это гипотетические рассуждения или ты действительно ловил такой спам?

Насчёт 10 000 сообщений это было тогда, когда по невнимательности я решил скачать содержимое всех эх целиком.

А так да, гипотетически. Ведь если дать возможность юзерам лепить огромные сообщения, то ей обязательно будут пользоваться. Кто-нибудь возьмёт и решит, что это невероятно прикольно взять 5-мегабайтную картинку, закодировать её в base64 и прилепить к своему сообщению. И всем остальным потом это скачивать (особенно через мобильный интернет).

AL> Опять таки: давай попробуем это реализовать в тестовом режиме и посмотрим сколько спама будет сыпаться? Не умозрительно, а именно в реальных условиях.

Спам - это всегда человеческий фактор. Когда нас здесь 5 человек, мы можем развлекаться как хотим и не задумываться о том, к чему это может привести.

Вот я сейчас написал выше про картинки в base64 и наверняка отпугнул людей от того, чтобы проделать такое в реале :)

Поэтому смысла особого нет, но вместо этого можно провести стресс-тест на тестовой ноде.

AL> Реальной пользы от этого ограничения нет. Только теоретическая.

Лимит какой-нибудь всё равно должен быть. Какое-то разумное, но при этом конечное число.

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

vit01> Насчёт лимита в 64 килобайта я против :)

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

vit01>> Насчёт лимита в 64 килобайта я против :)

AL> В общем, предлагаю компромисс: ограничение делать, но килобайт в 256-512. Я за последнее =)

У меня в 512к лимит в nginx стоит.

+++ картошки хватит на всех

vit01>>> Насчёт лимита в 64 килобайта я против :)
AL>> В общем, предлагаю компромисс: ограничение делать, но килобайт в 256-512. Я за последнее =)
Difrex> У меня в 512к лимит в nginx стоит.

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

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

AL> Тут Пётр предложил идейку, которая позволит прилеплять дополнительные данные к сообщениям. Так станут ненужными ни фэхи ни фреки. Я пока в свободное время, коего очень немного, попиливаю концепт этого дела. Как будет что показать, выложу на поиграться в свободный доступ.

+++ At work. idec.el/0.1

AL>> Тут Пётр предложил идейку, которая позволит прилеплять дополнительные данные к сообщениям. Так станут ненужными ни фэхи ни фреки. Я пока в свободное время, коего очень немного, попиливаю концепт этого дела. Как будет что показать, выложу на поиграться в свободный доступ.
Difrex> Кстати, а может озвучишь идейку саму? :)

::

gkCo68TG1nrIXrgMklUN:filename:image.jpg
gkCo68TG1nrIXrgMklUN:image:

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