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

>>5596
>Борда это не ее контент, а ее контингент. Т.е. не способ, а именно генераторы контента объединенные общей идеей
Бытие определяет сознание. А в данном случае технология определяет контент. Не зря ведь, в зависимости от реализованной технологии, различаются и сообщества.
Кроме того, я под бордой имел в виду не столько культуру имиджборд, сколько способ отображения контента. И то, что я предлагаю - это как бы развитие идеи борд.
>но попробовать можно, правда я не могу в летающий цирк
А во что можешь? Мне, в принципе, без разницы - импрувить питон, или изучать что-то новое.
Но, мне кажется, язык должен быть максимально распространенным, так больше людей смогут присоединиться.

>>5598
>А во что можешь?
C и Перол.

>>5599
Мне кажется, си слишком низкоуровневый для этого (или нет?). А перл подходит. Подождем, пока подтянется еще хотя бы немного народа, и тогда решим, что выбрать.

>>5600
Ну, на самом деле оба этих языка не очень сильно подходят под "веб". Для веба я собирался покопаться с руби, но на данный момент я немного занят.

>>5601
Ну, собственно, сама программа, являющаяся узлом сети, может быть написана хоть на си. А веб-морду можно и на руби делать.

>>5602
Гораздо проще будет все-таки на скриптах. В данном случае "скорость разработки" > "оптимальности кода".

>>5603
>Гораздо проще будет все-таки на скриптах. В данном случае "скорость разработки" > "оптимальности кода".
Согласен. Значит, пока в качестве кандидатов перл (?), питон и руби.

>>5595
Кто посмел вынуть идеи из моей головы? Только вы забыли украсть оттуда автоматический парсинг ОП-постов, вытаскивающий ключевые слова, примерно определяющие тему или, например, наличие нецензурной лексики. У каждого пользователя по идее должен быть список интересующих его ключевых слов, и чёрный список, которые автоматически отсекают часть контента. Эдакий превентивный куклоскрипт.
P.S. немного знаю python и erlang(язык заточенный как раз под сеть), плюсы довольно хорошо.

>>5610
Я думаю, имеет смысл реализовать функции парсинга/автозамены/поиска/шифрования отдельными скриптами. Юник-вей во все поля. То есть, у каждого пользователя есть сервер/клиент, который связывается с другими узлами, и передает контент. А все остальные функции можно реализовать с помощью других программ. Это дает гибкость и свободу с одной стороны, и позволяет избежать чрезмерного раздувания и усложнения программы, с другой.

>>5610
Питон это хорошо.

>>5612
Может и так, но пока в треде не появится анон, сведущий в p2p, желательно не теоретик простой, этот разговор довольно бессмыслен.
>>5611
Ну, это уже вопросы к архитектуре.

Я рублю в маршрутизации. Можете задавать свои глупые вопросы.

Такие распределенные борды уже существуют например во Freenet и в Perfect Dark.
Но конечно никто не запрещает сделать свою. Просто чтоб знали написал.

>>5595
Зачем делать еще одну борду?

>>5638
Наверное туда можно будет добавить фич - картинки и так далее

>>5645
Как будто обычные борды не поддерживают картинки.

>>5638
Так ведь не просто борду, а распределенную борду. Ее даже и бордой-то не совсем правильно называть. Но не социальной сетью же ее называть, правильно?

>>5657
Кроме того, анон правильно сказал про новые фичи. Современные борды (и не только борды, кстати) развиваются разве что в сторону "веб 2.0", под которым подразумеваются кнопки "запостить этот пост в моем фейсбуке" и скрывалки тредов. То етсь, ничего принципиально нового. Тогда как распределенная бордо-сеть позволит делать всякие интересные вещи. Ну, например, возможность прикреплять не только картинки, но и торрент-файлы (те, которые безтрекерные), или потоковое видео, но не с копирастического ютуба, а, опять же, с помощью п2п. Ну и так далее, вплоть до записей в БД, почему нет, собственно? Кроме того, широкие возможности по фильтрованию контента.
Для этого, например, можно использовать некоторые идеи распределенных VCS, те же репозитории. Удобно же, когда у тебя на локальной машине есть репозиторий с бордой/бордами, который ты настраиваешь под себя как хочешь, и решаешь, какие именно данные скачивать с чужих репозиториев. Кстати, можно и настройки доступы сделать, и шифрование, что понравится параноикам и любителям огораживания. Ну и так далее.
Собственно, я и предлагаю сначала решить, как это все будет выглядеть, а потом уже думать, на каком языке это все равлизовывать и т.д.

>>5658
Судя по опыту Frost http://jtcfrost.sourceforge.net/ , основная проблема в таких системах это спам.
Сортировать все сообщения в ручную, не решает проблему, так как перед фильтрацией их всё равно приходится скачивать, а учитывая скорость p2p сетей, это может серьёзно повлиять на производительность.
В FreeTalk часть проекта freenet это решили регистрацией+WOT и фильтрации постов по рейтингу пользователей, но это вряд ли подойдёт к концепции АИБ.

>>5661
>основная проблема в таких системах это спам.
Я уже об этом толковал в >>5610
Т.е. при создании сообщения пирам отсылается не оно само, а нечто, содержащее набор тегов. А клиент сам решает, что скачивать, а что - нет. Дело за малым - придумать анализатор текста, защищённый от вмешательства.

>>5662
Как тогда быть с вайпом картинками и прочими, не текстовыми сообшениями торрент-файлы, потоковое видео, и.т.д. ? их почти не возможно анализировать.

>>5602
Программу, являющаяся узлом, лучше взять готовую, из уже работающих сетей.
Так как большее количество пользователей сети увеличивает её анонимность,
у 3,5 анона, можно будет быстро привязать действия пользователя к его йп.
Да и не все хотят палить свои йп анону.

>>5666
>Да и не все хотят палить свои йп анону.
Вроде хотели через i2p делать.
>Как тогда быть с вайпом картинками
Хэши, как уже выше говорили. А вообще, можно начать с чисто текстовой борды.

>>5667
>Хэши
Изменив пол пикселя в картинке, у неё полностью поменяется хэш.
Но если делать не BlackList, а WhiteList хэшей, может сработать.

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

Можно сделать рейтинг сообщений + поле "спам" (если много проголосуют, что это спам - не скачивается).

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

Рейтинг сообщений, звучит хорошо, но на деле его будут использовать как средство самовыражения, минусуя все не понравившиеся посты пример: FreeTalk+WOT в Freenet'е.


Можно выдавать пользователям временный id на 10 минут, например в пределах доски/треда, тогда будет возможность "скрыть посты этого пользователя" семёны не оценят, но ничего лучше в голову не пришло.

>>5661
>Судя по опыту Frost ttp://jtcfrost.sourceforge.net/ , основная проблема в таких системах это спам
Можно продумать систему прав доступа. Ну, то есть, если сеть будет сделана по типу (виртуальной?) файловой системы, то каждый тред, например, будет файлом. И, собственно, фильтрация спама будет заботой владельца этого треда. Понятное дело, что любой человек может скачать себе копию этого треда, и спамить в него. Но это решается с помощью тех же цифровых подписей. Ну, то есть, можно подписаться только на доверенных пользователей.
А дальше, такой пользователь создает тред и подписывает его, причем, подпись меняет хэш, и, соответственно, можно настроить клиент так, чтобы он скачивал только подписанные версии нужных тредов.
Ну, это один из возможных вариантов. И мне кажется, точно не нужны плюсики и кармочка. Это все ведет в тупик, всегда.
>Программу, являющаяся узлом, лучше взять готовую, из уже работающих сетей
Можно на основе безтрекерных торрентов, например. В этом случае и через i2p все работать будет.
>i2p не поддерживает распределённые хранилища данных
А как же I2P tahoe-lafs?

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

>>i2p не поддерживает распределённые хранилища данных
>А как же I2P tahoe-lafs?
Tahoe-lafs может работать через I2P. Но I2P, сам по себе, ничего подобного не предоставляет.

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


Один из вариантов это Freenet: A Distributed Anonymous Information Storage and Retrieval System:
http://freenetproject.org/

[+]Анонимная p2p сеть.
[+]Все данные хранятся у пользователей.
[+]Возможность подключения сторонних приложений в виде плагинов, или через TCP Freenet Client Protocol.

[-]Java.
[-]Потребляет относительно много ресурсов зависит от скорости и шифрования.
[-]Очень долго подключается к сети разработчики рекомендуют вообще его не выключать.

>>5707
капча?

>>5713
Ручной вайп?

О каком вайпе идет речь? Тред и сообщение может храниться хоть вечность, пока его не удалят на всех компьютерах сети.

О какой капче речь? Кто ее будет выдавать и проверять? Юзер может подделать капчу расковыряв программу.

Можно делать так: каждое сообщение имеет идентификатор, который есть хэш сообщений. При каждом приеме сообщения каждый компьютер сети проверяет верность этого хэша. И при попытке подделать хэш сообщения или если при пересылке/хранении сообщение повредится - его просто уничтожают и дальше не распространяют (автоматически).
Чтобы было труднее подбирать хэш и чтобы сообщение имело подпись - оно шифруется "открытым ключем", а другой ключ - для расшифровки - передается вместе с сообщением. Вот совместный хэш зашифрованного сообщения + ключа и будет абсолютно уникальным идентификатором сообщения.
Все остальные сообщения в треде, которые отвечают на это сообщение должны содержать ссылку на этот уникальный идентификатор (то есть ссылаться сообщения друг на друга будут по ID).

Также сообщения должны содержать идентификатор треда - это ID самого первого сообщений, открывшего тред.
Кстати, можно будет строить очень разветвленное дерево тредов, ответвлять боковые треды и т.д. - Достаточно лишь указать ID ообщения как

....Достаточно лишь указать что ID сообщения на которое отвечаете - это ID нового треда (или ветви).

>>5719
Оче много криптографии для полутора посетителей.

>>5719
О фичах: можно добавить тэги, рейтинг (учитывать или нет рейтинг можно отключать в самом клиенте), ссылки на ресурсы (встроенные или приаттаченные).

>>5721
Совсем криптографии не избежать. Это же анонимная сеть. А вообще бояться не стоит - криптографию можно подключить даже не разбираясь в ней. Сейчас уже куча готовых библиотек и куча людей, которые помогут только попроси.

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

>>5720
>Все остальные сообщения в треде, которые отвечают на это сообщение должны содержать ссылку на этот уникальный идентификатор.
>Достаточно лишь указать что ID сообщения на которое отвечаете - это ID нового треда (или ветви)
Вот если я создам моного ОЧЕ МНОГО! таких сообщений с расчленёнкой и ниграми, это сильно затруднит поиск действительно интересных тредов, вызовет дискомфорт при чтении уже имеющихся и хотя тред и сообщения могут храниться хоть вечность хотя хранимому объёму, всё же, есть предел, найти их в куче нигров, будет очень сложно.
Кроме того
>Все будут скачивать негров с расчленёнкой, вместо постов
Что сильно скажется на общей производительности системы.

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

>>5719
Отличная идея, бро. Мне кажется, это именно то, что нужно. Остается решить, как лучше это реализовать.

>>5719
Можно ведь забанить на своем компе сообщения с очень низким рейтингом или помеченные кем-то как спам.

>>Выдавать и проверять капчу если понадобится капча может пир, через которого клиент, отправляет пост в сеть.
А что помешает спамеру сделать цепочку из программ (взломанных), чтобы обойти барьер "первого узла"? Имхо, нужно заложить невозможность подделки сообщений в фундамент всей системы. Для этого хороши хэши. Капча - довольно раздражающая вещь, но можно и ее конечно добавить (хотя кто захочет обойти - обойдет).

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

>>5724
Анонимность с точки зрения государства и инквизиторов-самоучек - уже "плохое" само по-себе.

>>5726
Ну само по-себе оно не появится ;) Кто-то должен же начать. Вот топикстартер например.

>>5729
>идентификатор автора.
>анонимность
Регистрация а любые средства идентификации пользователя её подразумевают может решить очень много проблем, но хотелось бы без неё.
Хотя вариант с временной регистрацией, мог бы подойти так как "деанонимизирует" только в пределах нескольких постов.
>Можно выдавать пользователям временный id на 10 минут, например в пределах доски/треда, тогда будет возможность "скрыть посты этого пользователя"

>Можно ведь забанить на своем компе сообщения с очень низким рейтингом или помеченные кем-то как спам
>помеченные кем-то
Практика показывает, что этот кто-то, скорее всего, будет метить не только спам, но и всё что ему не понравилось по аналогии с SAGE! SAGE!!! .

>>5731
Идентификация не человека, пишущего пост, а самого поста из потока поддельных постов.
>Практика показывает, что этот кто-то, скорее всего, будет метить не только спам, но и всё что ему не понравилось
Поэтому лучше обойтись без плюсиков-минусиков. Просто если не понравился пост - удаляешь его из ФС, и его рейтинг автоматически падает (т.е. можно настроить клиент на скачивание постов только с количеством пиров выше определенного числа), равно как и скорость закачки.
>Хотя вариант с временной регистрацией, мог бы подойти
Зачем регистрация? И как ее осуществить в распределенной системе? Где, собственно, человек будет регистрироваться?
Нет, анон выше правильно писал, систему нужно строить на открытых ключах и хэшах. И тогда, например, ты опубликовал годный контент, подписал его ключом, и когда ты потом публикуешь другой контент, подписывая его этим же ключом, к нему будет доверие. Если же постишь спам или нигр - доверие к этому ключу падает. И деанонимизации нет, и идентификация работает.

>>5729
>Ну само по-себе оно не появится ;) Кто-то должен же начать. Вот топикстартер например
Думаю, сначала нужно решить концептуальные вопросы (что мы вообще собираемся делать, и как это будет выглядеть), а потом уже думать над архитектурой.

>>5732
>Идентификация поста из потока поддельных постов.
Не совсем понятно, что такое поддельный пост?

>Зачем регистрация? И как ее осуществить в распределенной системе? Где, собственно, человек будет регистрироваться?
Получение уникальной пары ключей для подписи сообщений и есть регистрация. а так же трип-кода, псевдонима или чего либо другого что насильно отличает одного пользователя от другого

>И деанонимизации нет, и идентификация работает.
Под деанонимизацией, я имел ввиду установку факта, что несколько не связанных между собой постов, были написаны одним автором.
Хотелось бы избежать обсуждений что "0xJ4I3GE678@" постил в /h, какой "0xQ56DF45B4@" мудак и дуэли цитатами.
Останется только написать куклоскрипт, который для удобства вместо 0xJ4I3GE678@ и "0xQ56DF45B4@" будет вставлять "Вася и Петя"-кун и вести историю сообщений.

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

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

>>5736
Если для каждого поста можно легко использовать уникальный ключ что вайпер определённо и сделает, тогда в чем их смысл? неймфажить?

>>5719
Нет, для идентификации не нужна регистрация (вернее можно без нее). Если человек выберет себе случайный идентификатор, который станет его "псевдонимом", никак не привязанным к его айпи или адресу, и если это идентификатор не сможет подделать другой человек - то регистрация не нужна.
Парадокс цифровых подписей и открытой криптографии - человек открыто распространяет половину ключа, с помошью которой можно и проверить он ли является автором письма. И этот же ключ может быть его идентификатором. Подделать не удасться, так как чтобы прочитать сообщение - нужно использовать эту половинку ключа. А чтобы его зашифровать - другую половинку, которая никому кроме настоящего автора неизвестна. Так как это довольно случайные числа, то подобрать будет нереально трудно или невозможно.

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

>>5734
>Просто если не понравился пост - удаляешь его из ФС
Тогда сообщения не будут расходиться - свеженаписанное сообщение есть только на одном узле, потом только на двух, трех, ...

>>5734
Поддельный пост - это когда пытаются выдать свое письмо за чужое, например топикстартера. Понимаешь, анонимность может быть разной - например, когда все под одним именем (но реальной анонимности нет, так как у тебя один пароль записан во всех сообщениях + свой айпи записан в логах). А может быть анонимность когда твоегно адреса, имени и айпи неизвестно, но у тебя есть типа сетевого псевдонима, никак с твоей реальной личностью не связанного и никто не сможет связать. Если цель абсолютная одинаковость всех - когда все сообщения непонятно от кого, тогда конечно нужно отказаться от постоянных идентификаторов и генерировать новые ключи при каждой отправке сообщения.

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

Можно настраивать для разных тредов или досок разные подписи-идентификаторы, но более-менее вручную, чтобы не помогать спамерам "плодить ники". Хотя может и это необязательно и можно сделать режим авторегенерации.

>>5737
Можно ограничить пропускную способность узла - принимать от доного узла не более N сообщений в день.

В общем, все эти проблемы решаемы. Главное - чтобы кто-то принялся делать.

Сделать распределенную "борду" через транспорт обмена сообщениями (вроде перфект-дарка) очень просто.

1. Публикуется "публичный маяк" - идентификатор файла, по которому его нужно будет искатьлибо заключается соглашение о наименованиях файла. Файлов будет много, гораздо больше чем участников сети, точнее, фалов будет столько же, сколько будет постов.
2. В сеть, собственно, выкладываются "сообщения" в установленном формате.
3. Программа "сборщик" выкачивает список файлов доступных на данный момент (неплохо бы маркировать файлы еще и временем создания, это упростит управление данными когда размер базы сообщений превысит астрономический порог).
4. собственно "двигатель" извлекает "сообщения" из "новых" файлов и встраивает их в локальную бд.
5. Пользователь делает запрос в локальную бд и получает "готовый html".

Причем, PD используется не потому, что АНАНИМНАСТЬ а как распределенная сеть хранения, гарантирующая, что файло пролежит в ней некоторое время. Принципиального различия между системами хранения нет, можно использовать хоть email, хоть bittorent, хоть фриварный хостинг, куда будут помещаться сообщения.

Все бредни школьников выше не читал.

>>5739
А у Perfect Dark есть API, к которому можно подключиться, чтобы свои сообщения там пристраивать?

>>5738
>все эти проблемы решаемы
Обозначить проблему, уже половина решения.

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

Вся проблема сделать что бы:
>абсолютная одинаковость всех - когда все сообщения непонятно от кого
И при этом, оставить возможность их эффективной фильтрации и защиты от спама.

>принимать от данного узла не более N сообщений в день
Сообщение "Лимит сообщений для вашего узла исчерпан, попробуйте повторить через 24 часа", будет раздражать ещё больше чем капча и не поможет, если будут спамить всей школой.

>>5740
В данном случае распределенное хранилище используется именно как хранилище т.е. - составляется файл, публикуется там - дальше его разбирают другие "клиенты" и пишут ответы - после чего локальный "собиральщик" опять выкачивает новые ответы и запихивает их в базу. Т.е. в сеть используется только для хранения-распространения. Всем остальным занимается ПО на клиенте. Не обязательно делать "распределенный сервер без админа", проще сделать "распределенную базу" где каждая нода отвечает только за свои сообщения и соответственно обрабатывает все сама. Самое главное - договориться о протоколе. Все остальное - частности. Врядли именно у ПД есть биндинги вне "клиента ПД"

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

>>5744
Некоторые аспекты фильтрации, вполне реализуемы. методы описаны выше
Не вижу ничего плохого в цензуре, пока она не глобальна. ты не пользуешься adBlock'ом, не скрываешь посты, не сагаешь треды?
А возможность каждому выбирать, только нужную ему информацию из всей возможной, это одна из основных идей этого проекта.
Да и передавать ВСЕ сообщения, при определённой популярности доски, будет очень затратно или даже невозможно.

>>5745
1. Адблок - цензура на стороне клиента. Уже после передачи всей инфы т.е. html для вырезки передается целиком.
2. А возможность каждому выбирать, только нужную ему информацию из всей возможной, это одна из основных идей этого проекта - получается, что сервер должен будет хранить у себя информацию и выдавать только то, что хочет клиент.
Т.е. нужен немодерируемый сайт, который сожрет предположительно бесконечное количество информации. Морда не треснет?

>>5748
>цензура на стороне клиента. Уже после передачи всей инфы
html передаётся целиком, но не желательная информация баннеры итд не скачиваются.
Тоже самое и здесь, индекс передаётся целиком, а не желательные посты, доски, треды, картинки не скачиваются.

>получается, что сервер должен будет хранить у себя информацию и выдавать только то, что хочет клиент.
>написать распределенную борду, весь контент которой хранится у конечных пользователей.
А если какой то контент, никто не хочет у себя хранить, значит он никому не нужен.

>>5719
А сколько то сообщение весит? До 1000 байт? Можно хоть миллион таких сообщений в день передавать. Картинки - лежат отдельно. Но это конфликтует с концепцией N ообщений в день от узла.

>>5741
> Сообщение "Лимит сообщений для вашего узла исчерпан, попробуйте повторить через 24 часа", будет раздражать ещё больше чем капча
Ты пишешь больше 100 сообщений в день?

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

> Т.е. нужен немодерируемый сайт, который сожрет предположительно бесконечное количество информации. Морда не треснет?
Старые треды, на которые уже никто не отвечает, могут прибиваться на всех компах сети автоматом. Если не закрепить их как фавориты (и тогда они будут храниться только у тебя на компе), а если вдруг понадобятся кому-то эти старенькие анналы - твой комп выдаст.

>>5749
> индекс передаётся целиком, а не желательные посты, доски, треды, картинки не скачиваются.
Так как речь о p2p сети, то нет выделенных серверов для управления и синхронизации, а также выделенных хранилищ.
Так что скачивать придется всё, чтобы передавать дальше, даже если не читаешь. Это как в PD - еслть техническое хранилище на 40+ гигабайт, которое само наполняется и что-то передает, а есть твой программа-клиент, которым ты фильтруешь что читать, заказываешь что-то на скачивание.

>>5750
>Картинки - лежат отдельно
Хранить и передавать их тоже надо.

>Ты пишешь больше 100 сообщений в день?
Если через одну точку, сидят несколько человек?

>От всего не защититься.
Но если есть возможность, предусмотрительность не помешает.

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

>>5752
>Если через одну точку, сидят несколько человек? Ну несколько человек уже не один узел. Что-нибудь придумают :) Будут разделять лимит, играть на него в карты, а там подтянуться шлюхи с шампанским. Короче они выигрют ;)

>Программа же должна только передавать ему запросы на скачивание, закачивание данных и обрабатывать результат.
Верно, можно разделить на 2 программы - отдельно клиент сетьи, отдельно читалка борды. А можно объединить в одной программе. Но проще конечно иметь готовую сеть, а к ней пристроить свою борду (в виде читалки).

>>5753
>Короче они выигрют
А в этом что то есть. Наверное будет первая практическая реализация валюты имиджборд.

>разделить на 2 программы
Не только можно, но и нужно. Так как готовых сетей вполне хватает.

>>5754
какое у тебя практичное мышление :)

>>5758
>Всем р2р трафиком, а так же размером хранилища и его актуальностью, удалением старого, распространением нового и прочее, занимается клиент самой сети и как это происходит, зависит только от самой сети и её конфигурации.

Носмешил. Молодец. Т.е. мне достаточно будет сделать "новую" пустую базу и она "убьет" базы данных у всех клиентов (которые синхронизируются), просто потому, что у нее более поздняя версия? Жопой читаем тред? Из файлообменной сети данные могут "пропасть" только, если их удалят у себя все реплицировавшие их пользователи, либо сами ноды решат, что данные "устарели".
Не может быть никакой цензуры впринципе, со спамом придется мириться, убивать на нодах с помошью компрессии, либо блеклистить спамерские хэши (здравствуй кармачка :) ) и можно никуда не ходить, так как гуглоплюс, форумы похапебэбэ и борды с модерацией уже немножко более двух месяцев назад придумали и реализовали
Пересылать весь трафик - это не желание, это необходимость, и не только потому, что люди вроде тебя не в состоянии вычленить полезную информацию даже если ее обвести болдом, но и потому, что ее ценность может меняться со временем. Т.е. то, что сейчас считается спамом может стать олдфажной фаготрией и т.п.

Кулибины, блджад

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

>Пересылать весь трафик - это не желание, это необходимость
Контроль трафика, это задача клиента сети, здесь же, обсуждается программа обмена сообщениями.
Поэтому вопросы, сколько хранить, когда удалять, кому пересылать, кэширование, криптография, синхронизация и пр. уже решены, в виде клиентов к сетям вроде i2p, PD, freenet и т.д.
Программа обмена сообщениями же, должна только передавать запросы клиенту сети, на скачивание и закачивание сообщений, примерно как в >>5739

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

Например:

А, загружает своё сообщение в сеть без подписи.
В, скачивает сообщение А так как оно не подписано, В не может определить автора сообщения, анализирует его содержимое как здесь >>5610 , добавляет соответствующие теги школота, САЖА, ЕОТ, "ололо"х85 раз, размер, вложения, и т.д., подписывает своим ключом и загружает его в индекс.
С, проверяет если ключ В состоит в белом списке, если да загружает его индекс и скачивает или не скачивает сообщения с определёнными тегами.

>>5770
Невозможности ... , можно добиться в случае, ...
fix

>>5770
Это интересная идея - чтобы сам автор не мог подписывать, а вместо него подписывал и добавлял тэги кто-то случайный и посторонний. Но кому будет интересно так обрабатывать чужое сообщение? Это ведь может быть даже дольше, чем написать само сообщение.
Про то, чтобы не узнать кто автор: в нормальной анонимной p2p сети вроде все узлы являются транзитными. Поэтому сказать точно - написал узел это сообщение сам или получил и переслал от кого-то трудно. А в хороших анон-p2p сетях, например Perfect Dark, кажется вообще делают все, чтобы нельзя было проследить кто является реальным источником.

>>5772
>кому будет интересно так обрабатывать чужое сообщение?
Здесь предполагалась автоматическая обработка сообщений, с минимальным участием пользователя.
Но вариант, что некоторые пользователи отключат этот модуль, стоит предусмотреть.
Возможно мотивировать фильтрацию, чем-то вроде >>5754

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

>>5770
>В, скачивает сообщение А так как оно не подписано, В не может определить автора сообщения, анализирует его содержимое как здесь >>5610 , добавляет соответствующие теги школота, САЖА, ЕОТ, "ололо"х85 раз,
Слишком сложно. Можно так: А пишет сообщение, оно парсится, передаётся соседям. Там оно парсится точно по такому же алгоритму, если результат отличается (А у себя подмухлевал), то оно просто не передаётся дальше.

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

>оно просто не передаётся дальше
В хороших р2р сетях такого не предусмотрено, иначе никто бы никому ничего не передавал.

>>5788
Вот поэтому обычная p2p сеть может и не подойти. Как проверять тогда, что первоначальное сообщение не изменено? Нужно хотя-бы обеспечить достоверность сообщения - что оно такое, каким его отослали и никто не редактировал по дороге.

>>5791
А как вообще можно установить подлинность сообщения, не зная его автора?

>>5793
>А как вообще можно установить подлинность сообщения, не зная его автора?

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

>>5770
Доработанная версия, с капчей и WoT: оба опциональны, WoT нужен, только чтобы не перебирать в ручную over9999 пиров

(1.) PEER{1}:
загружает файл с новой капчей и своей подписью в сеть. [.sign]капча-410-b
в капчу входит: капча и рандомный ключ, зашифрованный кодом капчи +мета данные, дата, версия ит.д..
ждёт, пока кто нибудь загрузит файл, подписанный этим ключом. [.ключ]решение-капчи
через timeout переходит к шагу(1.)

(2.) PEER{2}:
загружает своё сообщение в сеть.
скачивает несколько рандомных капч (руководствуясь подписями, рейтингами WoT и датой скачанной капчи). [.sign]капча-410-b
извлекает из них ключи расшифровывая их кодами капч.
загружает файлы, с ссылкой на своё сообщение, подписанные ключами из капч. [.ключ]решение-капчи
случай, когда разные пользователи, загружают файлы с одинаковыми именами, обрабатывается клиентом сети
*загружать сразу несколько копий файлов, с разными подписями нужно, чтобы уменьшить последствия манипуляции с сообщениями, PEER'ами >>5794
ждёт, пока PEER'ы загрузят файлы с статусами обработки сообщения. [.sign]капча-410-b-[ключ]
проверяет что ссылки на сообщение в статусах, ссылаются на его сообщение.

(3.) PEER{1}:
скачивает файл с ссылкой на сообщение. [.ключ]решение-капчи
проверяет сообщение. >>5610
загружает индекс с результатами проверки, ссылкой на сообщение и подписывает его своей подписью. [.sign]личный индекс мод тян
загружает файл с ссылкой на обработанное сообщение. [.sign]капча-410-b-[ключ]
переходит к шагу (1.)

(4.) PEER{9}:
скачивает все индексы, на которые подписан (руководствуясь подписями и рейтингами WoT). [.sign]личный индекс мод тян
скачивает сообщения, по ссылкам в индексах, в соответствии с установками пользователя, тегами и пр.
при (не)соответствии тегов одного сообщения, в разных индексах, пользователь регулирует список подписей и локальные рейтинги WoT.
переходит к шагу (2.) и (1.).

Было бы интересно узнать, в каких случаях оно может не сработать и как можно сделать лучше.
inb4: никто не будет это реализовывать

>>5719
>Самый простой способ - каждое сообщение складировать, это позволит иметь на руках все варианты и действовать по обстоятельствам.
Но отличить реальное сообщение от фейка будет невозможно. И вообще так можно засрать любую ветку и никто ничего не сможет сделать и отфильтровать.

>Способ посложнее - статистически проверять чексуммы (и по количеству пиров, с которых пришли сообщения установленного образца определять какое из имеющихся сообщений было модифицированно),
> Очень трудоемко, медленно, не все пиры могут быть онлайн, и как первоначально отличить реальное сообщение от поддельного - ведь в распределенной p2p ты видишь только маленькую часть пиров, имхо, и сообщения медленно расходятся.

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

>>5799
Капча сама по себе неудобное зло. О ней можно думать только если вообще других вариантов не будет.
Пока я несколько раз пытался прочитать твое сообщение у меня сгорел мозг. Вышли мне новый на замену. ...фэйл я не помню адреса. он был в сгоревшем мозге. делайте бэкапы.

>>5801
>Капча сама по себе неудобное зло.
Зато она очень эффективна, и помогает экономить ресурсы сети, отсеивая часть спам-ботов.
Думаю вопрос, о необходимости капчи решится сам, во время эксплуатации.

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

>Пока я несколько раз пытался прочитать сообщение

http://rghost.ru/32112541/image.png
Надеюсь так будет немного понятнее.

>>5801
>И вообще так можно засрать любую ветку и никто ничего не сможет сделать и отфильтровать.

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

>Непонятно. Подпись можно менять (генерировать новую) для каждого сообщения. При этом все равно гарантируется проверка на изначальную подлинность и целостность, хотя такая проблема как идентификация автора исчезает - не получится идентифицировать по случайно сгенерированной "подписи" (она генерируется для каждого сообщения).

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

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

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

Например...

Возникла еще такая идея - при приеме сообщения принявший узел подписывает сообщение и указывает ОТ КОГО он принял его. Тогда мы получаем путь, через который проходят сообщения, и можно вычислить спамера и принять меры, даже автоматически блокировать спамера, рассылающего гигатонны сообщений. Идентификаторы узлов возможны временные. И в любом случае физически человека нельзя будет вычислить, только его виртуальный (м.б. временный) адрес

>>5802
Может быть я тупой, но схема сложноватая - я мог что-то непонять.
1) Как я понимаю, упор сделан на "барьер из одного узла" - того, кто первым принимает сообщение от автора. А дальше кто гарантирует достоверность и антиспам-защиту? Спамер может поставить цепочку из программ, может взломать программы подправив код. И сказать, что всё ок - качай, сообщение не спам.

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

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

>>5810
> ОТ КОГО он принял его.
Что будем делать, если релей не виноват, "он просто разместил объяву"? Пример - standalone сервер без оператора, который используется как хаб файлообменной сети и хранилище, одно из. В сети вообще их много, но мы имеем доступ к этому (допустим, до него у нас выделенная оптическая линия, до остальных - 64кбита) естественно, что логичнее пользоваться тем, до кого у нас канал шире, но если он окажется тем, от кого мы приняли спам - мы блэклистим его и получается таки сосем, поскольку скачиваем сообщения с низкой скоростью.

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

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

>мог что-то не понять.
Всё правильно понял. Просто я не умею хорошо объяснять.
Только:
-Вместо "барьера из одного узла", барьер из ограниченного количества узлов в примере использовалось 7 узлов (PEER 1-7).

>дальше кто гарантирует достоверность и антиспам-защиту?
Дальше достоверность гарантирует цифровая подпись и пользователь сможет скачивать сообщения, только с проверенными подписями.

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

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

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

>>5812
>Это очень сильно затруднит попытки, внедрить глобальную цензуру.
>Цифровая подпись.

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

>>5813
Сеньор, не криптограф, но общие представления о цифровых подписях имеет. на самом деле подпись, это хэш подписываемых данных, зашифрованный закрытым ключом.(системы подписи, с симметричными ключами тут не рассматриваются, из за сложности их реализации)
При проверке, хэш данных вычисляется заново и сравнивается с хэшем из подписи.
Данный метод почти гарантирует, что все подписи, удачно расшифрованные одним и тем же открытым ключом, были зашифрованы одним и тем же закрытым ключом. Что может говорит об одном авторе этих подписей. (в случае, если автор не опубликовал, свой закрытый ключ)

>>5814
А известно ли вам, что вся эта система зиждется на том, что существует центр сертификации, который может однозначно подтвердить, существует был ли выдан сертификат или нет? (именно поэтому при входе на самозашифрованную страницу браузер начинает вопить, что сертификат левый и самопальный). "Подписывание" пакетов само по себе ничего не даст, без центра, который будет следить за тем, какие подписи "хорошие" а какие - нет.
Короче, подпись пакета самосгенерированной подписью не будет препятствием для спама. Введение же центра аудита сертификатов сделает цензуру очень простой, у автора будут просто отзывать сертификат. Т.е. "цифровая подпись сообщений" как мера борьбы со спамом в распределенной системе не нужна. И дело тут в основном в том, что наличие определения того, что в сети нужно, а что не нужно уже делает архитектуру централизованной, а значит подверженной цензуре и, следовательно, предвзятости.

>>5815
Это всё верно для одного отдельного центра сертификации, но в р2р сети, у каждого пользователя, может быть свой независимый "центр" сертификации и каждый сам себе может решать, какие подписи "хорошие", какие - нет и т.д.

>>5816
Генерируем на каждое сообщение новую подпись - где твой бог теперь?

>>5817
Скачиваем сообщения только с определёнными подписями. whitelist

>>5818
А зачем тогда городить огород? Форум с регистрацией уже изобрели :)

>>5819
Весь огород вокруг того, чтобы автор оригинального сообщения оставался анонимным.

>>5820
... vpn + tor + trashmail + липовая инфа в профиле - 100% анонимности. Более анонимным быть просто невозможно Для любителей хардкора по хардкору - можно использовать для выхода на этот форум виртуальную машину на криптованом разделе.

>>5820
... vpn + tor + trashmail + липовая инфа в профиле - 100% анонимности. Более анонимным быть просто невозможно Для любителей хардкора по хардкору - можно использовать для выхода на этот форум виртуальную машину на криптованом разделе.

>>5821
Под анонимностью, имеется ввиду >абсолютная одинаковость всех - когда все сообщения непонятно от кого

>>5823
>абсолютная одинаковость всех - когда все сообщения непонятно от кого
>whitelist по цифровым подписям авторов сообщения
/0

Спам не такая уж большая проблема. Значительное его количество будет блокировано, если отфильтровывать сообщения с урлами на "коммерческие" ресурсы. Никто не будет набирать 100500 символов адреса, указаной в рекламной листовке вручную - а если спамер не получает экономического выхлопа - спама не будет. Точно так же можно отрезать и большинство вайпа - основная цель любого вайпера - угробить базу данных сообщений всего форума при такой модели распространения будет недостижима - положить точку, раздающую контент он не сможет - переполнить буферы и забить все доступные ресурсы вайпом предположительный атакующий так же не сумеет (если сумеет, то и подписи валидные он будет генерировать потоком), зафлудить тред он так же не сможет, так как каждый пользователь будет удалять то, что он считает хаутой сам себе (и следовательно не получится, как в случае с мод-тян парализовать целиком весь сайт на несколько недель, просто потому, что админу некогда заниматься им). Короче говоря, механические проблемы типа вайпа и зафлуживания будут самым меньшим злом.

>>5824
>whitelist по цифровым подписям авторов сообщения
>подписям авторов сообщения
??
>>5770

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

>>5826
>whitelist по цифровым подписям авторов сообщения
>подписям авторов сообщения
>??
Каждая нода будет генерировать свой собственный код -> анонимность будет такая же как и в случае "vpn + tor + trashmail + липовая инфа в профиле", не надо забывать, что при "маршрутном" подписывании (когда сообщение на каждом узле подписывается самим узлом) можно менять подпись пакета пересылая его различным серверам ->это не эффективно, как мера фильтрации - спам все равно будет передан, просто его загрузят с другого узла.

>Практика, как раз показывает обратное.
"переполнить буферы и забить все доступные ресурсы вайпом" вполне возможно, из за низкой пропускной способности р2р сетей.

Нельзя. Нужно понимать, что "пересылается медленно" и "вообще недоступно" это разные вещи. "Забить канал" в p2p сети - все равно, что пытаться заддосить передачу файлов в битторенте - даже если один из серверов будет блокирован - остальные будут продолжать работу. В системе электронных писем (аналог которой мы сейчас обсуждаем) процент мусорного трафика ушел за 90 (это гигабайты мусора в секунду), а все равно она эффективно работает и не тормозит - а происходит это потому, что нет центрального сервера, который можно заблокировать, так же буждет и в описываемой мной системе.

>>5827
>анонимность будет такая же как и в случае "vpn + tor + trashmail + липовая инфа в профиле"
Анонимность отдельной ноды, да. Но анонимность автора так как он не подписывает своё сообщение будет максимально возможной, для данной сети.

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

>"пересылается медленно" и "вообще недоступно" это разные вещи.
Второе вытекает из первого.
Не думаю что у всех есть возможность в отличии от почтовых серверов, которые только этим и занимаются обрабатывать гигабайты мусора в секунду.
И мало кто захочет сидеть на борде, где для просмотра нового сообщения нужно ждать несколько часов, пока клиент перекачает все гигабайты мусорного трафика.
Скорость, это основная причина непопулярности большинства р2р сетей, поэтому этим параметром не стоит пренебрегать.

>заддосить передачу файлов в битторенте
Это почти не возможно только потому, что сейчас на заре торрент протокола, очень часто "убивали" популярные раздачи, внедрением мусорного траффика у большинства торрент клиентов есть механизмы защиты анализ траффика + бан по IP и пр..
Сети, в которых этих механизмов почти нет е2к, gnutella1,2 и.тд находятся сейчас, не в лучшем состоянии %over999 фейков, "битые" закачки и пр.%%.

>Каждое сообщение подписывается только один раз, первым получателем и от этой подписи зависит, загрузят ли его другие узлы или нет.
Интересный подход. Т.е.
>Что будем делать, если релей не виноват, "он просто разместил объяву"? Пример - standalone сервер без оператора, который используется как хаб файлообменной сети и хранилище, одно из. В сети вообще их много, но мы имеем доступ к этому (допустим, до него у нас выделенная оптическая линия, до остальных - 64кбита) естественно, что логичнее пользоваться тем, до кого у нас канал шире, но если он окажется тем, от кого мы приняли спам - мы блэклистим его и получается таки сосем, поскольку скачиваем сообщения с низкой скоростью.

Т.е. ответственность со спамера перекладывается на релей. При такой схеме обмен сообщениями даже не начнется.

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

Ну, хуле. Увы. По другому не получится. Архивация + селективное скачивание только "новых" постов только так.

>Сети, в которых этих механизмов почти нет
Ну, никто не мешает встроить эти механизмы в клиент, который будет обрабатывать траффик (например, если сразу установить максимальный и минимальный размер "сообщений" это так же повысит "прочность" системы).
Торент представляет собой целый файл разбитый на множество мелких кусков. Для него целостность критична - текстовое сообщение+ картинка могут потерять значительное количество составляющей их информации и все равно "дойти".

>>5829
>ответственность со спамера перекладывается на релей.
Релей ответственен только за маркировку сообщений, как здесь >>5610 . За содержание он ответственности не несёт.
Но если он не помечает мусор, спам или что то другое как положено, пользователь уберёт его из белого списка.

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

>Увы. По другому не получится.
Почему?

>>5830
>Релей ответственен только за маркировку сообщений

Но, получается, что любое сообщение будет цензурироваться. Если релей будет потрошить любую почту - он сможет туда что угодно написать и что угодно оттуда достать. Или просто не передавать "очень важную информацию". Это будет похлеще FIDО возведеного в степень ичана по отношению к анониму в плане модерации. Анонимностью при такой схеме даже и не пахнет, не говоря уже о том, что это получится премодерируемый форум с регистрацией, а не форум с принудительной аноимностью.

>Разбирать исходники клиента сети, встраивать нужные модули, обходить конфликты в работе с сетью и не модифицированными клиентами, повторять каждую новую версию.

"Клиент" - это программа, которая будет "разбирать почту" вытащенную из p2p-сети. сама передача данных в сети - это то, что нас не волнует. Гипотетически к нам постоянно поступают с небольшой скоростью новые сообщения оттуда, наша задача свести к минимуму количество добра, которое будет отображено в браузере. Основная работа по фильтрации флуда\спама\вайпов будет происходить на нем, а не в сети.

>Почему?
Если кто-то решает за тебя, что тебе нужно, то чем это отличается от уже существующих служб -жежешечкаконтактик еще что-нибудь?

>>5831
>чем это отличается от уже существующих служб?
>получается, что любое сообщение будет цензурироваться.

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

>свести к минимуму количество добра, которое будет отображено в браузере.
Это не решает проблему скорости сети.
Надо сводить к минимуму вытаскивание "почты" из p2p-сети. Зачем загружать сообщения, которые не будут отображаться?

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

>Это не решает проблему скорости сети.
Скорость самой сети это то, чем будет заниматься "чорный ящик" p2p. Т.е. нас она не волнует.