>>219292
Да.

>>219293
Нет.

Я знаю, как избежать проблемы «кончилось место на диске с картинками».

>>219330
Убрать возможность постинга картинок? Я за.

>>219330
Прикрутить распределённый бэкэнд?

>>219330
Закрыть Ычан?

>>219330
Гипервекторный текстовый Нетофид?

>>219330
Запрещать постить картинки после 10-го числа каждого месяца?

>>219338

Вот этот аноним всё понял.

Да, прикрутить распределённый бэкэнд, причём в виде распределённой файловой системы (IPFS) — то есть совершенно таким же образом, каким это ужé проделал, например, хостинг картинок http://ipfs.pics/

Как я это вижу:

1) Как только нить обсуждения достигает бамплимита, так сразу весь её HTML и иллюстрации отправляются на прикол в IPFS. Внутренние гиперссылки должны быть исправлены соответствующим образом, и внешние ссылки (с доски на нить обсуждения) также. (Для обеспéчения такого исправления придётся слегка переменить движок.) После этого нить обсуждения и её иллюстрации стираются из основной файловой системы сервера (но продолжают занимать на нём место, потому что остаются в хранилище IPFS).

2) Через неделю или месяц или другой такой срок, после которого можно быть уверенным, что читатели доски утащили нить обсуждения в свои собственные IPFS-хранилища, сервер снимает нить обсуждения с прикола в IPFS и стирает из хранилища. Для обеспéчения такого утащения придётся пропагандировать IPFS среди анонимов в виде такого примерно рецепта:

• Скачайте реализацию IPFS на комп и поместите её в каталог, доступный в PATH. После этого подайте команду ipfs init для инициализации IPFS на компе.

• После запуска компьютера подавайте команду ipfs daemon для запуска демона, обеспечивающего распределённого файлообмена.

• Установите во браузер такое расширение, которое будет брать IPFS-опубликованные данные у этого демона (то есть из IPFS-хранилища на компе). Есть https://addons.mozilla.org/ru/firefox/addon/ipfs-gateway-redirect/ для Файерфокса, есть https://chrome.google.com/webstore/detail/ipfs-gateway-redirect/gifgeigleclkondjnmijdajabbhmoepo для Chrome, и так далее.

Просто нужно удалить немножко тредов. С последних страниц!

>>219344

>С последних страниц!

Еретик.

>>219343
И всё же, лучше закрыть.

>>219343
Нужно пойти дальше! И сделать весь Ычан полностью распределённым. Лучше даже в обход сети интернет. Даже без основного узла. Тогда у каждого будет свой внутренний локальный Ычан. А основной Ычан можно закрыть. Сарказм если что.

>>219343
Только лучше не прямо вслед за бамплимитом, а после попадания в архив их туда отправлять.

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

>>219360
и не прямо вслед за бамплимитом, а непосредственно сразу после попадания в архив

После попадания в архив — поздно.

Ведь в архиве почти никто не будет читать.

А ведь для попадания материала с сайта в чужие кэши IPFS было бы необходимо, чтобы массово читали материал — настолько массово, чтобы среди читателей попадались (хотя бы время от времени) обладатели собственных установленных и настроенных хранилищ IPFS, а не только пользователи гейта IPFS→WWW.

Если материал прочтут 3½ анонима, то это никому не пойдёт на пользу.

>>219376

>Ведь в архиве почти никто не будет читать.
>Если материал прочтут 3½ анонима, то это никому не пойдёт на пользу.

GTFO

>>219376

>Ведь в архиве почти никто не будет читать.

Посмеялся. Ну да, а что ещё ожидать от поехавшего?

>>219379
Не читаю архивы, практически никогда не читаю дальше нулевой, ЧЯДНТ?

>>219380
Хорошо поставленный вопрос содержит в себе ответ.

>>219376

> Ведь в архиве почти никто не будет читать.

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

Но для начала разобраться бы с куклой и ручным добавлением. https://ipfs.io/ipfs/QmeE8WJmjBQ6nCAAZ6Lo3UyoR9shshrwTxTQxD8U7QjssL/iichan.hk-barch-3358327.html Вот почему она ломается, спрашивается? Надо бы разузнать у Степана, что тут можно сделать.

>>219382
Вы тут Архивач изобретаете? Или очередную грабилку корованов, за упоминание которой будут банить?

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

>>219390
Блджад, была уже одна p2p-борда со своим клиентом. В итоге все просто дропнули.

>>219391

>одна p2p-борда

Очередной анархокриптовозрождённый двaч.
фикс тебя

>>219395
Может, всё-таки приподнимешь завесу тайны ИТТ?

>>219395
IIchan работает на SQLite, и иногда забускается нечто, что активно пишет в БД? Но как это относится к картинкам?

>>219382

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

Не могу постигнуть логику этого высказывания.

Разве тред после бамплимита не закрывается от новых постов прямо сейчас? По-моему, закрывается, так что и переменять в этом смысле нечего.

>>219407
Ты никогда не писал в бамплимитнутых тредах? Не ври.

>>219408
Зачем ты вообще с ним разговариваешь?

Лучше всего показать на несложных примерах, что же такое этот IPFS. Допустим, мы берём фотокарточку Фланечки и аккуратно помещаем её в свою локальную IPFS-ноду. Она в ответ отдаёт нам длинный-длинный, но зато уникальный и неизменный хэш: QmcnVzRT1YzAEvW1oEpBCFMWKHmRqb17v4Cf6GBfJGSgVH. Затем мы направляемся к ближайшему публичному гейту из IPFS в веб и просим его показать нам объект с этим хэшем: https://ipfs.io/ipfs/QmcnVzRT1YzAEvW1oEpBCFMWKHmRqb17v4Cf6GBfJGSgVH. Тот находит нашу ноду, а затем копирует с неё запрошенный объект. И показывает его! Потом мы идём к любому другому гейту (или, например, к тому самому картинкохостингу) и делаем ровно то же самое: http://ipfs.pics/QmcnVzRT1YzAEvW1oEpBCFMWKHmRqb17v4Cf6GBfJGSgVH. И он в свою очередь делает ровно то же самое, только теперь он может запросить объект как у нашей исходной ноды, так и у той, второй. И точно так же любая ычанька может установить себе IPFS и наслаждаться данной фотокарточкой прямо с неё: http://localhost:8080/ipfs/QmcnVzRT1YzAEvW1oEpBCFMWKHmRqb17v4Cf6GBfJGSgVH. А ещё её можно закрепить в локальном кэше своей ноды, и тогда Фланечка точно никуда не пропадёт. И чем больше ычанек сделают то же самое, тем надёжнее она будет храниться. Также добавлять можно не только отдельные файлы, но и целые каталоги — например, с теми же самыми сохранёнными тредами. И они точно так же будут доступны до тех пор, пока будут храниться хотя бы на одной подключённой к сети ноде.
Ну, наверное, уже очевидно, что это не грабилка корованов узкого назначения и тем более не p2p-движок для чана, а нечто более универсальное, правда? Можно посмотреть видео от автора, где он более подробно рассказывает про своё творение и его возможности (https://youtu.be/skMTdSEaCtA) и показывает, что и как с ним можно делать (https://youtu.be/8CMxDNuuAiQ). Или прочитать краткое описание: https://github.com/ipfs/ipfs/blob/master/README.md.

>>219407
И опять-таки выше отметили, что постинг в бамплимитные треды работает наравне с обычными. Они не поднимаются в списке, но на то они и бамплимитные же. Разве это было не очевидно?

>>219415

>не p2p-движок для чана
>IPFS is p2p

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

>>219416
P2P protocol же, а не p2p imageboard engine.

А суть предложения в том, чтобы скрестить с ней только архив, но ни в коем случае не заменить Ычан целиком. Архивные треды уже не будут меняться, а значит, у каждого из них будет только один хэш, и создавать тысячу копий не будет необходимости. Ссылки с ними будут храниться на странице архива (примерно так же, как и сейчас), которая будет гарантировать, что ссылка с этим хэшем — именно та самая, который указывает на архивный тред. Ну а неизменность содержания обеспечит сама IPFS — подменить объект с одним и тем же хэшем невозможно.

А пример треда, сохранённого руками, сделан просто для наглядности и чтобы показать сломанную куклу. Как и при обмене сохранёнными тредами через rghost, его аутентичность гарантирует ычанька, которая его залила и запостила ссылку :3 Выглядеть ссылки на заархивированные треды будут примерно так же, но указывать по умолчанию будут наверное на собственный гейт Ычана: iichan.hk/b/arch/ipfs/[длинный-длинный хэш треда] или что-то вроде этого. И наверное, можно будет даже как-нибудь извратиться с симлинками/редиректами/ещё чем-нибудь, чтобы не сломать ссылки на уже имеющиеся архивные треды. Кстати, по этому случаю просьба к Мицголу: отправить фичреквест на добавление возможности сделать что-то вроде AllowPinnedOnly, чтобы ычаньки а в особенности, хм, не совсем ычаньки не подставляли к гейту Ычана хэши Фланечек и других посторонних объектов, нагружая тем самым сервер почём зря. Сейчас такого вроде бы нигде не видно.

>>219417

>Архивные треды уже не будут меняться

Есть случаи обатного.

>>219415

> И опять-таки выше отметили, что постинг в бамплимитные треды работает наравне с обычными. Они не поднимаются в списке, но на то они и бамплимитные же. Разве это было не очевидно?

Ах да, правда, чего это я. (Не выспался, должно быть.) Действительно, в обсуждениях можно невозбранно участвовать и после достижения ими бамплимита.

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

Прозреваю грядущий конфликт интересов: если это время будет слишком небольшим (например, 10—20 часов), то анонимы могут не успеть ни дообсудить некоторые предметы краткого обсуждения (о которых не хочется в новом обсуждении продолжать рассуждение), ни даже добавить реплику «бамплимит достигнут, переходим в такое-то новое обсуждение» с соответствующею гиперсвязью. Если же это время будет слишком значительным (например, неделя), то обсуждение утонет настолько, что читать (а значит, добавлять в собственный кэш IPFS) его никто не будет уж, кроме 3½ анонимов, и это никому не пойдёт на пользу.

Оговорюсь, что мысли о P2Pизачии движка являются сугубо теоретическими: ведь если до сих пор никто из авторов движка Иичана не осилил переправлять все гиперссылки, на обсуждение ведущие, при отправке его в обыкновенный имиджбордовый архив, то уж тем более не будут переправлять все гиперссылки, на обсуждение ведущие, при отправке его в IPFS; да и сама отправка не состоится, не состоится. Не хватит у них на то мышиной натуры их!

Сразу скажу ещё, что наиболее объёмный элемент обсуждения в действительности является и наиболее неизменным элементом его: это иллюстрации, прикрепляемые к репликам. Уж их-то можно отправлять в IPFS с сáмого начала (как это хостинг http://ipfs.pics/ делает, например), а через неделю или месяц командою ipfs pin rm откреплять и тем экономить жизненное пространство в хранилище на сервере.

Одного этого достаточно для исчезновения проблемы «кончилось место на разделе с картинками»: картинки-то не на разделе, а в IPFS! (Ну, кроме наиболее новых.)

>>219417

> Кстати, по этому случаю просьба к Мицголу: отправить фичреквест на добавление возможности сделать что-то вроде AllowPinnedOnly, чтобы ычаньки а в особенности, хм, не совсем ычаньки не подставляли к гейту Ычана хэши Фланечек и других посторонних объектов, нагружая тем самым сервер почём зря.

По названию AllowPinnedOnly я догадываюсь о том, что сервер с этой настройкою должен показывать (в Интернете) только те файлы из IPFS, по отношению к которым выполнена (на самóм сервере) команда ipfs pin add, однако не выполнена команда ipfs pin rm, так что они пришпилены (поставлены на прикол) в местном IPFS-хранилище на сервере.

Однако, так как мы тут обсуждаем решение проблемы «кончилось место на разделе с картинками», то я предлагаю освобождать это место вот каким образом:

• Складывать обсуждения в IPFS в момент архивации их.

• Складывать картинки в IPFS ещё раньше — в момент публикации их.

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

И что же получается? Получается, что с настройкою AllowPinnedOnly сервер перестанет показывать те архивы, на хранении которых он экономит?

(Или смысл этой настройки предполагается несколько другим — не напрочь отказываться от показа файла, а перенаправлять читателя на другой гейт, настройки AllowPinnedOnly не имеющий? Или что? Или как?)

>>219417
Тогда уж сразу кнопочку добавить "скачать себе весь архив".

>подменить объект с одним и тем же хэшем невозможно

Нет ничего невозможного! Скорее, через чур затруднительно для большинства смертных.

>нагружая тем самым сервер почём зря

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

>>219423

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

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

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

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

>>219418
Даже если так, то хотя бы часто и с большой скоростью меняться архивные треды не станут.

>>219419
Мод-тян — приличная женщина! Но обсуждать детали в той ситуации, когда совершенно ничего не ясно в целом, и правда немного странно. В конце концов, подкручивать такие детали можно прямо в процессе, когда (если) он настанет.

>>219420
Вариант, кстати, интересный, но как тогда картинки будут попадать в IPFS-кэш к ычанькам, если сам тред ещё активен и отдаётся через обычный сервер?

>>219421

> По названию AllowPinnedOnly я догадываюсь о том, что сервер с этой настройкою должен показывать (в Интернете) только те файлы из IPFS, по отношению к которым выполнена (на самóм сервере) команда ipfs pin add, однако не выполнена команда ipfs pin rm, так что они пришпилены (поставлены на прикол) в местном IPFS-хранилище на сервере.

Да, идея была именно такая.
А практический смысл этой настройки в том, чтобы создавать такие гейты, которые будут отдавать только связанное с целевым сайтом содержимое. По умолчанию через любые гейты, в том числе те, которые смотрят в интернет, можно запросить любой объект, верно? И если гейты общего назначения, как публичные, так и локальные, именно этим и должны заниматься, то для предполагаемых специализированных, вроде будущего ычанского, это наоборот не слишком желательно. Зачем через такой гейт, предназначенный только для отдачи картинок и архивных тредов, отдавать что-то ещё, никак с Ычаном не связанное? Не говоря уже о том, что сервер можно просто заспамить кучей запросов, объекты из которых будут забивать локальный кэш. Можно регулярно выполнять ipfs repo gc, но это не решает саму проблему, а только удаляет симптомы. Можно вообще не открывать гейт наружу, но... как тогда будут открывать ссылки те, у кого не установлен IPFS? Не завязываться же на какой-нибудь сторонний гейт. Или просто подшаманить уровнем выше, прозрачно перенаправляя нужные запросы на скрытый где-то внутри гейт? Но и тогда не совсем понятно, в каком виде давать ссылки на те треды, которые уже откреплены при помощи ipfs pin rm. Или ввести концепцию каких-нибудь "полуприкреплённых" объектов, содержимое которых не хранится локально, но может быть отдано в случае запроса? А можно и действительно просто перенаправлять на один из других гейтов без такой настройки.

В общем, ещё есть над чем подумать. Но такая настройка всё равно может оказаться полезной, как мне кажется.

>>219423

> Тогда уж сразу кнопочку добавить "скачать себе весь архив".

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

> Нет ничего невозможного! Скорее, чересчур затруднительно для большинства смертных.

Но ведь уже совершенно иная ситуация, чем "кто угодно может создавать изменённые копии тредов и все они словно настоящие", правда?

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

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

>>219518
Кхм. В общем, эта задумка с p2p-децентрализацией в целом интересна, но на Ычане не реализуема. Децентрализация подразумевает отсутствие управлением центром. Гм, как сказать-то... Грубо говоря, модерирование станет невозможно. Вот удалили колобка, он остался у кого-то в кэше и в итоге можно получить именно версию страницы с колобком. Причём проверка через постоянное таскание запросов на центральный сервер — фейл, т.к. можно айпишник этого самого сервера отправить в локалхост через хостс и спокойно получать нужные версии страничек, как это делается с закрытыми торрент-раздачами. Плюс хостинг данных у пользователей резко ухудшает безопасность: во-первых, пользователи могут напрямую обмениваться ими, во-вторых, очень велик шанс потери данных из-за отсутствия раздающих, а в-третьих, будет проще делать грабилки. А в таком случае почему прямо сейчас не разрешить ими пользоваться? Как бы и Ычан, а как бы и сторонний хостинг. Хм... Сейчас трудно правильно сформулировать и объяснить, но скоро приеду домой и постараюсь более развёрнуто и обдуманно ответить.

>>219518

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

Совершенно так же, как сейчас они попадают в кэш браузера.

Возьмём для примера обсуждение http://iichan.hk/a/res/1121714.html (ещё даже не бамплимитнувшееся в настоящее время).

В нём есть HTML-тег A (гиперссылка) с атрибутом href, равным "/a/src/1441485507605.png", и внутри него есть HTML-тег IMG (картинка) с атрибутом src, равным "/a/thumb/1441485507605s.png". При просмотре обсуждения картинка "/a/thumb/1441485507605s.png" попадает в кэш браузера; если же читатель жмякнет по ней мышóю, то и картинку "/a/src/1441485507605.png" скачает и закэширует его браузер.

Теперь представим, что этот HTML-тег A (гиперссылка) имеет атрибут href, равный "https://ipfs.io/ipfs/Qma4jcXxb4kjhEJt6BsXcPS3aQetDYoGLM9MscMKXz4pDL", а внутри него HTML-тег IMG (картинка) имеет атрибут src, равный "https://ipfs.io/ipfs/QmZizyT5KC9Uror45pwUdCtUQVPEMRSGNg2NK9rFvLxv9s". При просмотре такого обсуждения картинка из IPFS с хэшем QmZizyT5KC9Uror45pwUdCtUQVPEMRSGNg2NK9rFvLxv9s попадала бы в кэш браузера (а также в кэш IPFS, если он установлен и настоен и запущен у читателя, а браузер перехватывает обращения к загейтованным через ipfs.io файлам IPFS, вместо этого направляя обращения в локальный кэш); если же читатель жмякнет по ней мышóю, то и картинку из IPFS с хэшем Qma4jcXxb4kjhEJt6BsXcPS3aQetDYoGLM9MscMKXz4pDL скачает и закэширует его браузер (и его IPFS, если всё сделано для этого).

Самó обсуждение может продолжать быть активным и отдаваться через обычный сервер, но картинки будут раздаваться по IPFS и попадать в кэш на гейте ipfs.io и в кэш у тех анонимных читателей, которые сподобились установить и настроить IPFS и изменить поведение браузера.

>>219518

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

Но моё предложение будет работать и без того, чтобы создавать на Иичане собственный иичанский гейт из IPFS в WWW.

Анонимам достаточно будет использовать либо существующий по адресу https://ipfs.io/ гейт, либо их собственные кэши IPFS на их собственных компах.

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

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

Программу IPFS править для этого не потребуется, например.

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

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

>>219522

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

Модерирование страниц обсуждения должно предшествовать отправке этих страниц в IPFS.

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

>>219566
Если Ычан будет выступать полноценным пиром сети, то возникает проблема не только с модерированием. Заосчиваем лоликон и прочее в IPFS, а потом обузим в РКН ссылочки на них с хостом на Ычане.

>>219567

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

Но узлом файлообмена в IPFS он может продолжить быть, причём в кэш этого узла даже не попадёт из IPFS никакого лоликона (если админ не будет лично его из IPFS запрашивать, потому что если гейта нет, то больше запрашивать некому).

>>219581
Если у каждого файла есть уникальный ID и если Ичан полноценный пир — то что помешает зловредителю послать заготовленный URL в РКН даже без откртия его, что приведёт к тому, что контент на Ычане появится только во время проверки жалобы, а до этого он даже не сможет этому никак воспрепятствовать.

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

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

Потому и вопрос про возможность запилить только раздающую ноду.

P2P технологии напоминают коммунизм. Вера в общую честность, «ты мне — я тебе». А в реальности получается «я тебе, а ты, в лучшем случае, ничего, но вероятнее всего мешок дерьма».

>>219590
Ычую. Поэтому p2p больше всех зависит от человеческого фактора.

>>219583

> Если у каждого файла есть уникальный ID и если Ичан полноценный пир — то что помешает зловредителю послать заготовленный URL в РКН даже без открытия его, что приведёт к тому, что контент на Ычане появится только во время проверки жалобы, а до этого он даже не сможет этому никак воспрепятствовать.

То, что Иичан не будет гейтом из IPFS в WWW и поэтому не будет существовать такого URLа, простое открытие которого приводило бы к появлению нового контента на Иичане.

Сколько на сервере дубликатов спасибонепонялы?

http://iichan.hk/an/src/1441546973842.jpg

>>219620

Какое это имеет отношение к делу?

>>219638

> У Мод-тян кончилось место на разделе с картинками?

>>219638>>219639
Праздный интерес. Вне дискуссии, мне непонятной.

Мне-то показалось, что это был риторический вопрос, в форме которого на самом деле было сформулировано предложение «а посмотрите, сколько на сервере дубликатов спасибонепонялы, а давайте запретим анонимам общаться дубликатами спасибонепонялы и вообще визуальными макросами — тогда и место на разделе с картинками не будет резво тратиться!».

(Причём тогда оно и впрямь не будет резво тратиться — но какою ценою?…)

Между тем сегодня я добавил в гипертекстовый Фидонет поддержку иллюстраций из IPFS, отображающихся при трансляции в RSS и оттуда в LiveJournal. Могу ссылку дать.

Даю ссылку:

http://fidonet-mithgol.livejournal.com/2438795.html

>>219657
Можно разрешить постить одинаковые картинки, если ты понимаешь, на какой способ экономии места на диске я намекаю. А ещё можно периодически запускать поиск похожих картинок. Только вот проверку на совпадение и соответствующее сообщение всё равно нужно выдавать. А там пользователь либо подтверждает, либо отменяет отправку поста. Вангую, что это не будет реализовано никогда.

> Список тредов

Спасибо, Мод-тян!

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

>>219714
Это ОЧЕНЬ долгий процесс. 41 доска. Индекса по md5 наверняка нет отдельного.
Разве отдельную таблицу только для этого строить, где md5 обязательно уникальный? И то есть вероятность, что картинки на самом деле разные.

>>219718
Так кот же говорит, что надо делать попиксельную проверку? У меня скрипт из /c/ Нульчана 2009-го года до сих пор стабильно пробивает любые проверки, даже в гифах, чего не умеет кукла. Просто в большинстве случаев постятся ранее оттуда же сохранённые изображения. По сути, можно даже сейчас просто вместо предупреждения о ранее запощенной пикчи вставлять ту самую пикчу в новый пост. Прямо сейчас, даже делать ничего не надо.

>>219720
Прямо сейчас проверка идёт лишь по одному разделу, по md5.
Проверять все разделы (+архив) - стрельба.

>>219721
Хоть что-то. Считай, минус ~100-300мб в месяц.
Алсо, представил, как какой-нибудь залётный постит колобка, а у него сразу «Нет уменьшенной копии».

>>219722

>~100-300мб

Завышенные ожидания.
Алсо, когда счёт идёт на десятки-сотни гигабайтов, если не терабайты, то это - капля в море.

>>219721
Хэши считается один раз, при отправке и хранятся в БД, с которыми и сравнивается новая пикча.

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

>>219724
That's what Eye'm sayin'. Просто если говорить о сохранении места, то тут очень малая выгода.
Юзеры должны страдать и привосить ОК, а не заниматься копипаста-гейством.

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

>>219562

> Анонимам достаточно будет использовать либо существующий по адресу https://ipfs.io/ гейт, либо их собственные кэши IPFS на их собственных компах.

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

>>219723
Эм, при мне такой хуйни не былооткуда столько трафика? Или имеется в виду уже хранящиеся файлы? Помню, год-два назад было обсуждение (ссылка сохранилась, но там уже ЧОЧ и нет ни в Гуглокеше, ни в веб-архиве) новой проверки копий изображений, там даже вбрасывали онлайн-сервис для тестов со сравнением с другими проверками, ну и сам убедился, что оно детектирует даже картинки с изменённым хешем (через изменение одного пикселя), помогало только добавление довольно широкой рамки разноцветной. Можно было бы прогнать через оное и поудалять лишнее.

>>219727
Очевидно, уже хранящееся.

>детектирует даже картинки с изменённым хешем (через изменение одного пикселя)
>помогало только добавление довольно широкой рамки разноцветной

Большой риск побить то, что битым быть не должно.

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