Попробуй сохранять не абсурдрез с бур, например.
Любая картинка с какого форчонга вполне перепосчивается. Для картинкодампов есть /хр/ и /аа/

http://tinypng.com/

http://compressjpeg.com/
http://compresspng.com/

>>232766

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

>>232771

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

>>232766

> Любая картинка с какого форчонга вполне перепосчивается.

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

>>232772
Не повысит.

>>232772

> с того самого форчонга, из которых я многие не смогу запостить здесь.

Так ты превью сохраняй, бака!

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

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

1) Преодолеть нынешний лимит размера файлов.

2) Не перенагружать хостинг хранением файлов, не перенагружать канал связи Иичана раздачею файлов.

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

Смысл таков: если это поле заполнено, то картинка показывается из P2P-распределённой файловой системы IPFS, не нагружая собою ни хостинг, ни канал связи Иичана.

Выглядит это так: если в поле мультихэша введено значение «QmYB7ABwHSZpYMMq3qqPqiwxEZ1YmZJuU7CXevAWAKvMG1», то показывается картинка, HTML-разметка у которой указывает не в подкаталоги /thumb/ и /src/ на имиджборде, а на IPFS-гейт по адресу https://ipfs.io/ipfs/QmYB7ABwHSZpYMMq3qqPqiwxEZ1YmZJuU7CXevAWAKvMG1

Те читатели Иичана, у которых не установлена поддержка IPFS, так и получают картинку с IPFS-гейта https://ipfs.io

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

1) Установленный и запущенный демон IPFS. (Его реализацию можно по адресу https://dist.ipfs.io/ скачать.)

2) Установленное в веб-браузере средство подмены адресов https://ipfs.io на адреса локального IPFS-гейта. Таким средством может послужить https://addons.mozilla.org/en-US/firefox/addon/ipfs-gateway-redirect/ в Файерфоксе или https://chrome.google.com/webstore/detail/gifgeigleclkondjnmijdajabbhmoepo во Хроме.

Следует коснуться и вопроса о том, откуда возьмутся IPFS-мультихэши картинок. Этот вопрос может иметь минимум два различных ответа:

1) Во-первых, можно закачать картинку в IPFS через любой веб-интерфейс, поддерживающий такую закачку. Примером таких интерфейсов могут сайты https://ipfs.pics/ и http://ipfs.stadja.net/upload/ послужить.

2) Во-вторых, если поддержка IPFS установлена, то можно подать команду ipfs add имяФайлаКартинки в командной строке операционной системы — и тем невозбранно достигнуть желаемого.

Что думаете?

В связи с предложением >>232834 хочу подчеркнуть четыре обстоятельства:

1) Пример https://ipfs.io/ipfs/QmYB7ABwHSZpYMMq3qqPqiwxEZ1YmZJuU7CXevAWAKvMG1 превосходит три мегабайта.

2) Авторы беседы http://iichan.hk/b/res/4128717.html и IPNS-сайта https://ipfs.io/ipns/QmRmkky7qQBjCAU2gFUqfy3NXD7BPq8YVLPM7GHXBz7b5P ужé распробовали IPFS в /b/ и увидели, что это хорошо.

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

4) Можно хранить в IPFS и показывать на Иичане, окромя иллюстраций, также и звукозаписи, и даже видеозаписи. Но эту возможность я также не считаю первоочередною: спервоначалу следует потренироваться на иллюстрациях, а далее смотреть, как пойдёт оно.

>>232834

>предлагаю допильщикам движка

Т.е. 0,01% посетителей. Подавляющая часть из которых так ни один свой допил до конца и не осилила.

>Те читатели Иичана, у которых не установлена поддержка IPFS

Т.е. 99,9% С учётом необходимых телодвижений - почти перманентно.

>Что думаете?

Выглядит немного утопично. Многие нюансы не понятны. Например, чем это лучше обычного аутсорса.

>>232838

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

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

Обычный аутсорс хуже тем, что он не P2P-распределён. В силу этого он обладает теми же недостатками, что и FTP по сравнению с торрентами: может уходить в оффлайн, может быть перегружен пиком запросов, может быть атакован правоторговцами (и притом целерезультативно — а значит, повадно), может закрыться (в том числе надолго или даже навсегда), может не иметь географически близких (малопинговых) и провайдерно близких (высокотраффиковых) источников файла.

Понятно, что достоинства P2P-распределения продолжаются недостатками. Полагаясь на читателей как на хранителей, файл способен исчезнуть из Сети по мере исчезновения сиюминутной потребности в нём — а значит, и исчезновения потребителей (источников), располагающих его копиями. Так исчезают с «Няторрентс» торренты по мере накопления нескольких лет возраста. Признаться, и гиперссылка https://ipfs.io/ipns/QmRmkky7qQBjCAU2gFUqfy3NXD7BPq8YVLPM7GHXBz7b5P из шапки беседы http://iichan.hk/b/res/4128717.html у меня сейчас не открывается: возможно, большей частью участники её (я имею в виду не всѣхъ участников беседы, а только немногих P2P-хранителей указанного IPNS-ресурса) не только спят поздней ночью, но также и своих демонов IPFS повыключали.

Предлагаю для расширения видимых перспектив по адресу https://torrentfreak.com/pirate-bay-founder-piracy-scene-needs-innovation-160726/ ознакомиться с мнением основателя популярного сайта «The Pirate Bay», который также высказался в пользу освоения IPFS любителями плодов нелицензионного копирования.

Гипертекстовый векторный фидонет.жпг

>>232839
Другими словами - всё те же недостатки, но по другим причинам. И решить это можно только хостя картинки как раньше, параллельно шаря их в P2P. В результате получаем только достоинства, но не решаем проблемы ради которой всё и пилилось.

>самоочевидным (наблюдаемым)

Но ведь оче-видный и есть "наблюдаемый глазами". Как оно может само?

Предлагаю для решения этой проблемы использовать технологию WebTorrent. WebTorrent может работать в браузерах с поддержкой WebRTC, а так же в Node.js. В отличии от ipfs клиенту ни чего самому устанавливать не надо. Возможности WebTorrent аналогичны BitTorrent.

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

>>232874
Тут и так гуглоаналитик, хулъ ещё скрывать-то?

>>232877
Не путай раскрытие данных Мод-тян и раскрытие данных какому-то мимокрокодилу. Это очень разные вещи.
Ты, например, не можешь получить доступ к гуглоаналитике, но в случае использования p2p-технологий ты можешь потенциально получить доступ к ip-адресам других пользователей и возможности анализировать их поведение на основе того, какие файлы они отдают.

>>232872

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

Нѣтъ.

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

>>232873

> Предлагаю для решения этой проблемы использовать технологию WebTorrent. WebTorrent может работать в браузерах с поддержкой WebRTC, а также в Node.js. В отличие от ipfs, клиенту ничего самому устанавливать не надо. Возможности WebTorrent аналогичны BitTorrent.

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

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

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

>>232874

Предположим, что любой читатель Иичана в любой момент может узнать всѣ IP-адреса людей, открывавших некоторую картинку через установленный у них IPFS, а не через https://ipfs.io/

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

Но на самом деле нѣтъ никакого «а значит», потому что последние десять реплик видны во всю доску: их невозбранно видят без какого-либо захода в конкретное обсуждение.

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

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

Внимание, три вопроса:

1) Чего может достигнуть программист, располагая этим знанием?

2) Рост популярности IPFS приведёт к тому, что многие картинки будут открываться совершенно посторонними лицами на других сайтах гораздо раньше, чем появляться на Иичане — и будут открываться совершенно посторонними лицами на других сайтах в то время, когда на Иичане попадут на часть обсуждения, не видимую всей доске. Что тогда? Ведь тогда, кроме читателей Иичана, в собранный список будут попадать посторонние лица?

3) Не слишком ли неполна статистика, из которой можно исчезнуть, если посещать доску чаще, чем один раз в десять реплик?

Ну что?

Никто с июля возражений не народил?

Нет иного пути: если великá стоимость и чрезмерны издержки централизованного хранения и раздачи крупных иллюстраций, то тогда только P2P-децентрализованное (распределённое по множеству читателей) хранение их может спасти Иичан, невозбранно принести долгожданное снятие нынешнего тягостного ограничения на объём их.

Сознаёте?

Почему бы вам не пойти в /s/ и не обсудить всякую распределённую лабуду там?

>IPFS

http://iichan.hk/b/res/4132921.html
там:
http://iichan.hk/b/res/4132921.html

>>232971

>Сознаёте?

Да.
Но даже если возражений нет, то остается пара вопросов:

1. Какова официальная позиция администрации Ычана на счет этого?
2. Кто будет заниматься допиливанием движка Ычана?

>>232972

> Почему бы вам не пойти в /s/ и не обсудить всякую распределённую лабуду там?

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

Упомянутая в реплике >>232839 врéменная неработоспособность распределённого (децентрализованного) сайта https://ipfs.io/ipns/QmRmkky7qQBjCAU2gFUqfy3NXD7BPq8YVLPM7GHXBz7b5P действительно оказалася не постоянною: сейчас он у меня открывается вполне невозбранно.

>>232987
Угу, то-то у меня в обычном браузере, скажем, https://ipfs.io/ipfs/QmeEJfugc8TWUroy8VuodnxBaN8cvxSbnRgRZVB7BjEuc5/iichan.hk-b-4112680.html не открывается ни разу.

Вообще, как раз именно эта попытка использовать ipfs в практических целях (в которую я оказался вовлечён) говорит о том, что для этих целей он, пока еще, весьма и весьма плохо приспособлен. И предлагать переводить на него ычан — как минимум, преждевременно. А вот предложение перенести этот диалог в /s/ — наоборот, кажется вполне уместным. Там, кстати, уже был про него тред.

>>233053
У меня в древнем открывается. Но там зачем то куклоскрипт.

>>233055
У меня такое ощущение, что этот самый ipfs.io при обращении к такого рода ресурсам на некоторых из них весьма капитально подвисает. Даже своё обычное cannot resolve не выдаёт, просто тупо не открывается. Эксперимента ради сейчас ломанулся туда wget'ом. Он настырный, сумел таки пробиться. Ушло у него на это минут 15…

>куклоскрипт

Угу. И от него, в перспективе, еще придется это дело чистить. Но к теме обсуждения, это, как ты понимаешь, отношения не имеет. А к теме доски и того менее. Но вот в /s/ я бы с интересом послушал, скажем, как, по мнению нашего главного идеолога ipfs, правильно организовать в нем зеркало довольно крупного сайта с (частично) динамическим контентом, при условии, что на сам сервер ставить эту ipfs крайне нежелательно, а уж выделять там на это дело дополнительное место, равное по размерам оному сайту — вообще ни в какие ворота…

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

>>233056

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

А теперь прошу ещё раз перечитать моё предложение, изложенное выше.

Предлагал ли я зеркалировать в IPFS целиком Иичан?

Нѣтъ, не предлагалъ.

Только картинки, и только для преодоления полуторамегабайтного (а кое-где и трёхмегабайтного) лимита. Не более.

А это статический контент, не динамический. Статичнее не бывает.

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

>>232881
Стоит заметить, что я в целом разделяю энтузиазм относительно IPFS... но и одновременно с этим считаю, что для повсеместного практического применения он действительно ещё до конца не готов. Однако, начинать пробовать его можно и нужно уже сейчас — чем я, собственно, и занимаюсь.

Кстати, благодарю за невольно сделанное (>>232839) напоминание — так совпало, что оно пришлось весьма кстати. Та страничка называть ЭТО «сайтом» будет, наверное, всё же некоторым преувеличением в тот момент не открывалась действительно именно по недосмотру основного «P2P-хранителя». А всё потому, что система IP**N**S выделяю на тот случай, если кто-нибудь при беглом прочтении не различит IPFS и IPNS на данный момент обладает одним заметным недостатком — для поддержания IPNS-ссылки в живом состоянии (а она, напомню для тех, кто пока этого не знает, позволяет публиковать изменяемые страницы, используя при этом в качестве адреса один и тот же неизменный хэш) требуется в общем случае держать постоянно запущенной ту конкретную ноду, с которой была опубликована данная ссылка. Нет, можно, конечно, увеличить значение параметра --lifetime при выполнении ipfs name publish (и это даже работает)... но не до бесконечности же! И через некоторое время после ухода этой ноды в оффлайн такая ссылка перестанет открываться, даже если останутся другие ноды, что продолжат хранить у себя содержимое, на которое она указывала. С одной стороны, было бы хорошо, чтобы по IPNS-ссылкам всегда можно было получить их последнее значение, но с другой стороны, их ведь тоже необходимо будет где-нибудь хранить. А где хранить? IPFS — не Freenet и не PD, и встроенного блокчейна у него тоже нет. Выходит, что эти значения сейчас могут храниться сетью только ограниченное время.
Впрочем, к поднятой в этом треде теме в узком смысле данный вопрос действительно прямого отношения не имеет.

>>233053

> Угу, то-то у меня в обычном браузере, скажем, https://ipfs.io/ipfs/QmeEJfugc8TWUroy8VuodnxBaN8cvxSbnRgRZVB7BjEuc5/iichan.hk-b-4112680.html не открывается ни разу.

К сожалению, на ipfs.io могут быть свои собственные неполадки, повлиять на которые мы не можем...

>>233055

> Но там зачем то куклоскрипт.

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

>>233061
...А что, наконец, имеет непосредственное отношение к теме треда, так это работа ipfs.io. При использовании подобной схемы проблемы с отображением картинок могут возникнуть у тех ычанек, у которых (пока ещё) не установлена нода IPFS — как мы можем видеть даже в этом треде, ipfs.io далеко не всегда работает так хорошо, как того хотелось бы. И даже бы если работал, перекладывать открытие некоторых картинок с Ычана на сторонний (и к тому же в общем-то экспериментальный) сервис, наверное, всё же будет не совсем правильно...

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

>>233062

>обладает одним заметным недостатком — для поддержания IPNS-ссылки в живом состоянии требуется в общем случае держать постоянно запущенной ту конкретную ноду, с которой была опубликована данная ссылка

…И вторым недостатком — такая ссылка может быть только одна на ноду.

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

>А где хранить?

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

>перекладывать открытие некоторых картинок с Ычана на сторонний (и к тому же в общем-то экспериментальный) сервис, наверное, всё же будет не совсем правильно...

Да. Фактически — это при таком раскладе становится похожим на использование для их хранения стороннего хостинга. И здесь мы видим еще одно слабое место ipfs: если что-то случится с https://ipfs.io/ — вся связь этой сети с внешнем миром накроется медным тазом.

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

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

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

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

Вопрос проверки достоверности файла решён: проверка основывается не на установлении доверия к узлу-источнику, а за счёт контроля хэша. (По такому же принципу работает и торрентовый файлообмен.) Так, например, содержимое файла https://ipfs.io/ipfs/QmYB7ABwHSZpYMMq3qqPqiwxEZ1YmZJuU7CXevAWAKvMG1 может быть математически проверено на соответствие мультихэшу QmYB7ABwHSZpYMMq3qqPqiwxEZ1YmZJuU7CXevAWAKvMG1 после получения файла, что исключает подмену (потому что задача создания подменённого файла по известному хэщу обладает очень большой вычислительной сложностью: необходимою для этого вычислительною мощностью человечество не располагает).

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

Кажется также, что сайт https://ipfs.io не является единственным гейтом из IPFS в WWW; например, иллюстрацию https://ipfs.io/ipfs/QmVBJ5meMDhEUBqXygQdm56Gwq9ycTfiyznN2gc516pp3o также можно получить по адресу https://ipfs.pics/ipfs/QmVBJ5meMDhEUBqXygQdm56Gwq9ycTfiyznN2gc516pp3o

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

Возвращаясь к пункту 1 - вариант сделать так, чтобы не тормозило, это хранить превьюшки на ычане, а всю картинку на ипфс. Но тогда это делает необходимым пункт 2 - аплоад картинок в эту распределенную сеть через ычан, что мне кажется еще более утопичной идеей, чем заставить это делать самих пользователей. Или переходить на асинхронную загрузку картинок и радовать посетителей тредами без картинок. Но при этом большие картинки смогут загружать 0.01% пользователей - те у которых установлена эта приблуда. остальные как не могли загрузить 3М так и не смогут. А ради 0.01% тратить усилия нецелесообразно. Проще этих 0.01% забанить и дело с концом.

>>233323

Тезис «читатели Иичана не будут класть картинки в IPFS, потому что для этого надо ставить IPFS» несостоятелен. Во-первых, могут и поставить IPFS, ничего трудного нет в этом. Во-вторых, рекомендую ещё раз повнимательнее реплику >>232834 перечитать, я там не зря говорил (а тут могу вдругорядь повторить, раз уж с первого раза не до всех дошло), что кроме установки IPFS на свой компьютер (или мобильник) ещё также можно закачивать картинку в IPFS дистанционно через любой веб-интерфейс, поддерживающий такую закачку, и что примером таких интерфейсов могут сайты https://ipfs.pics/ и http://ipfs.stadja.net/upload/ послужить.

Тезис «чтобы не тормозило, надо хранить превью на Иичане, а картинку в IPFS, но это делает необходимым размещение картинки в этой распределённой файловой системе через Иичан» несостоятелен. Читатель Иичана может лично разместить иллюстрацию в IPFS, как это указано в предшествующем абзаце. После этого Иичан (если администрация Иичана действительно озаботится изготовлением превью) может по хэшу IPFS (указанному читателем в его реплике) получить (и сохранить у себя во временный файл) иллюстрацию из IPFS, по ней изготовить превью (после чего только превью и хранить, а ранее созданный временный файл стереть). Причём, вероятно, делать всё это можно и в фоне (чтобы не «тупить по 10 минут» в момент загрузки очередной реплики в обсуждение): пока в фоне идёт работа, можно показывать читателям файл из IPFS в его полном объёме (уменьшенный HTML-атрибутом width) на месте превью до тех пор, пока не окончено изготовление превью. Сразу скажу ещё, что Иичану не обязательно изготовлять превью. Если на месте превью сразу помещён файл из IPFS (уменьшенный HTML-атрибутом width), то он сам может послужить себе предпросмотром, если только автор файла озаботился сохранить его в одном из таких форматов, каков «прогрессивный JPEG» или «чересстрочный PNG»: читатель в уменьшенном виде увидит приблизительное представление о картинке довольно быстро, успев скачать себе едва лишь первую четверть этого файла или около того. Не скрою, что сперва почти неизбежен краткий период всеобщего недоумения, но затем достоинства этих форматов сделаются для читателей совершенно очевидными, и тотчас распространится на Иичане разумный обычай употребления именно этих форматов в большинстве иллюстраций, загружаемых в IPFS.

Тезис «картинки из IPFS грузятся долго» совершенно справедлив, но доведение его до крайности «даже среднее обсуждение проще будет закрыть вместе со всем остальным Иичаном» представляется чрезмерным. Напоминаю прежде всего, что ситуация «ДОЛГО скачивается из IPFS иллюстрация на 5 мегабайтов» всё же лучше (причём бесконечно, бесконечно лучше!) нынешней ситуации «вообще НИКОГДА не скачивается из Иичана иллюстрация на 5 мегабайтов, потому что Иичан не принял её на хранение». Ещё напоминаю, что всѣ современные браузеры скачивают картинки параллельно (а не последовательно), так что если в среднем обсуждении пара-тройка-другая иллюстраций поступает из IPFS (и оттого несколько медленнее всех остальных), то это всё же не помешает видеть остальные. Ну и вдругорядь повторю тезис из предшествующего абзаца: если автор файла озаботился сохранить его в одном из таких форматов, каков «прогрессивный JPEG» или «чересстрочный PNG», то читатель увидит приблизительное представление о картинке довольно быстро, успев скачать себе едва лишь первую четверть этого файла или около того, так что медленность скачивания не слишком будет огорчительною.

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

Рецепт >>232834 предложен 30 июля, но с тех пор никто не допилил движок Иичана.

Окей.

Предлагаю администрации выложить движок Иичана на GitHub.

>>233440
http://wakaba.c3.cx/releases/Wakaba/

>>233415
А зачем на Ычане большие файлы?

>>233442
Мицголу лень репостить нарезки анимы из Твиттора.

>>233415

>Во-первых, могут и поставить IPFS

Зачем плодить сущности? Это первое.
Второе. Зачем поддерживать всякие новые технологии, увеличивая размер сети, без которых всю жизнь нормально обходились?
Третье. Он жрёт трафик.

Я помню, как мне доброчаньки скидывали что-то при помощи этого буллшита. День не мог разобраться, почему не загружается.
Сказали поставить себе демона и работать через локальный гейт, потому что ipfs.io/ipfs не всегда работает. Уже засорять компьютер приходится. Ладно, один раз можно потерпеть, потом снесу и вычищу его конфиги, благо не винда.
Всё равно не открывается. Смотрел подключение, активные пиры, прочий шит.
В конце концов, выяснилось, что у меня нет IPv6. В то время как они все работали через него (кто-то имел нативный, кто-то покупал VPN - или как там это делается). Закончилось всё тем, что на меня посмотрели как на дурного из-за того, что я ещё не сделал себе туннель, в то время как все давно уже влились в IPv6.

Это всё вот к чему. Зачем плодить у себя на ПК и сетевом железе лишнее ПО, которое ни для чего, кроме как для ычана, не нужно?
Давайте уже вообще сделаем специальный протокол, на прикладном уровне для локального пользователя работающий как I2P - чтобы ставить спец. клиент и заходить в сеть через локальный прокси, открывая там ычан.
А ещё лучше - запилить специальное железо типа тех аппаратных средств шифрования трафика, через которое все будут заходить на ычан. А те, у кого такого железа нет, пусть будут терпеть или смотреть ычан через какие-то гейты в сети, не имея возможности постить здесь.

>>233415

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

Это довольно сложный и требующий тщательного тестирования и отладки код. Администрация вряд ли станет этим заниматься. Если делать это не в фоне — получим низкую производительность, иичан и без того медленно работает.

> пока в фоне идёт работа, можно показывать читателям файл из IPFS в его полном объёме (уменьшенный HTML-атрибутом width) на месте превью до тех пор, пока не окончено изготовление превью.

Зачем вообще превью? Давайте всегда полные картинки показывать. Нет, это очень плохое решение.

Да проще просто ссылку на картинку кидать в пост и всё, на этот твой ипфс.

>>233441
Модаба - не совсем вакаба. Вернее, совсем не вакаба.

Каптча sir.

>>233446
Сир всех уже утомил своей пастой без пруфов. Можно ещё мэм про антивайпалку вспомнить, которая раздаёт 95% всех банов.

>>233443
Но тогда почему все пользователи Ычана должны решать проблемы Мицгола?

>>233450
Потому что он думает, что все обязаны решать его проблемы и запиливать всё, что он предложит.

Что мешает написать пользовательский скриптили расширение который сам будет заливать файлы в ipfs перед отправкой поста и генерировать уменьшенную (если файл больше чем поддерживает Ычан или превью если это видео) копию (со ссылкой на оригинал в ipfs) и постить ее на Ычан. А также этот скрипт должен будет находить такие изображения при чтении Ычана и извлекать ссылку на оригинальные файлы из ipfs.

>>233453
https://github.com/ipfs/js-ipfs

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

>>233441

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

>>233454

Ну да, конечно. А ещё https://github.com/oliver-moran/jimp/ для создания миниатюр изображений. Правда, всё равно ещё понадобится джаваскрипт, изготовляющий предпросмотры видеозаписей. Ни у кого адресок не завалялся?

>>233455

> пока он не содержит никакой поддержки эмоджи

Поставь эту вакабу на sqlite — не будет проблем с эможы юникодом.
А еще ўэбмастер.

>>233456
Про готовое не знаю, но вообще читать вот это: http://html5doctor.com/video-canvas-magic/.
Остается только подпинать FileReader, чтобы он сделал createObjectURL, потом этот ObjectURL воткнуть в video, начать его играть и сделать toDataURL на canvas, чтобы вытянуть картинку.
Теоретически должно сработать, но на практике можно столкнуться со всякими CORS-граблями и прочими механизмами безопасности браузера, которые могут не позволить это все реализовать.

>>233458>>233456
http://techslides.com/demos/video/dragdrop-video-screenshot.html

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

>>233457

Ну да, конечно, установка на SQLite волшебным образом изменит логику работы подпрограммы forbidden_unicode в скрипте wakautils.pl. Под дурачка-то не коси.

>>233453
Кто нибудь уже начал это делать? Если нет, то сам начну разрабатывать.

>>233471

Начинай. Но только непременно, непременно на Гитхабе; а не то как же иначе видеть исходный код по мере его сочинения?

>>233472
Тогда будет одна проблема - код сможет увидеть каждый. А не только его автор и его доверенные лица.

>>233473
Это проблема?

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

>>233476
А что, ты этот скрипт потом собрался продавать? Кому, Иичану? Можешь тогда не начинать даже, это абсолютно бессмысленное занятие.

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

>>233478
Я не думаю, что кто-то в здравом уме будет ставить себе некий скрипт с закрытым кодом, лол. Даже куклоскрипт с открытым очень многие не ставят из-за паранойи (я в том числе, например), куда уж тут.

Нѣкоторые субъекты ещё не вполнѣ отошли отъ извѣстия о томъ, что всѣ (или хотя бы очень многія) операціонныя системы и даже нѣкоторыя микропрограммы микропроцессоровъ всецѣло подчиняются развѣдкѣ Сѣверо-Американскихъ Соединённыхъ Штатовъ, такъ что въ уму можетъ явиться предательская мысль «А чё ужъ, всё равно пропадать вѣдь!…» — и съ тѣмъ поставитъ человѣкъ закрытый кодъ скрипта самъ себѣ…

>>233447
Пруфы были и все, кто хотел, с ними уже ознакомились. Поднимать эту тему для тех, кто слишком сырно, чтобы застать это обсуждение, я не вижу.

>>233515
Поздравляю с очередным сливом, что уж.

Начал разработку скрипта и дошел до реализации сохранения файлов в ipfs и тут возникли проблемы: api разработано на node.js и у меня не получается заставить его работать в браузере. Тут есть кто нибудь, кто разбираться в node.js?

>>233522
/dev/

>>233516
Сливом чего кем? Базы блета сокром?

>>233522

Вместо https://github.com/ipfs/js-ipfs-api используй https://github.com/ipfs/js-ipfs и тем невозбранно достигнешь желаемого.

>>233522

Хотя стоп.

Если речь идёт о клиент-серверной архитектуре, в которой браузер читателя Иичана общается с его же локальным IPFS-сервером, тогда https://github.com/ipfs/js-ipfs-api правильный выбор.

Используй script src="https://npmcdn.com/ipfs-api/dist/index.js" согласно https://github.com/ipfs/js-ipfs-api#in-the-browser-through-script-tag и не позабудь прочесть в README дальнейшие пометки про CORS.

>>233526

>с его же локальным IPFS-сервером

Вот тут тоже постойте.
Скажите лучше, как это сделать без локального IPFS-сервера (то есть, чтобы отсутствовала необходимость ставить себе какое либо дополнительное ПО).

>>233529

Тогда рецепт >>233525 годится (IPFS-сервер https://github.com/ipfs/js-ipfs может работать изнутри скрипта, потому что и сам он написан на языке JavaScript).

Сразу скажу, что это решение может обладать теми же недостатками, о которых в реплике >>232880 я сказал насчёт WebTorrent:

• Весьма вероятно, что файлы будут раздаваться только в то время, когда открыт сайт (в нашем случае — Иичан) и работает соответствующий скрипт.

• Почти столь же вероятно, что авторы не озаботились обращением ко внутрибраузерному хранилищу, так что файлы и храниться будут только в то время, когда открыт сайт (в нашем случае — Иичан) и работает соответствующий скрипт; иными словами: страницу закрыл — файлы потерял (при переоткрытии скачивай заново, даже если переоткрытие вызвано кнопкою «🔙 Назад»).

Употребление постоянно действующего IPFS-сервера лишено этих недостатков (ну да, зато его сперва поставить надо, это понятно).

>>233523

Пока мы предлагаем свои идеи для улучшения Иичана, из темы /d/ мы не выходим.

(Даже если развитие идей этих дошло ужé до стадии технических подробностей, выражающихся на языке HTML и JavaScript.)

Соответственно, ответ на вопрос «Как заставить работать во браузере» из реплики >>233522 выглядит для https://github.com/ipfs/js-ipfs следующим образом: в README сказано, что в npm попадает готовый итог транспилирования, так что достаточно подать команду npm install ipfs для того, чтобы согласно https://github.com/ipfs/js-ipfs#use-in-a-browser-using-a-script-tag появилась возможность подулючить скрипт assets/bundled.js во браузере HTML-тегом script. (Надо думать, что assets/bundled.js будет в подкаталоге node_modules/ipfs после того, как npm установит IPFS.)

Априорное мнение >>233549 я должен сейчас опровергнуть на основании собственного опыта: только что подав команду npm install ipfs и пристально вглядываясь в результаты работы её, я должен непременно умозаключить, что там вовсе нет никакой папки assets.

Подозреваю, что теперь это не assets/bundled.js, а скорее dist/index.min.js является итогом работы транспилятора. (А какого транспилятора? А вот какого: по комментариям в файле index.js явствует, что там https://webpack.github.io/ применяли.)

>>233522
Можно использовать апи (https://ipfs.io/docs/api/) напрямую без всяких библиотек, так как там все достаточно просто. Например, добавить файл можно выполнив POST запрос при помощи curl curl -F "path=@/home/file" http://127.0.0.1:5001/api/v0/add , аналогично это можно сделать и из браузера отправкой формы или используя XMLHttpRequest

>>233556
Это всё хорошо, а теперь расскажите про уязвимости.

Уязвимости те же самые, что и у любого хостинга, включая Иичан.

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

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

>>233562
Я имел ввиду, прикрепление расширений к картинкам и всём таком.

>>233554
А можешь выложить готовый пример работающего браузерного клиента? (хотябы в тот же ipfs)

>>233564

Предлагаю к пути https://ipfs.io/ipfs/QmXYzbr2nboKdSBnj6Ux5megJUczWnqSiYMGTA2BJmFSwc/SERVAMP.jpg попробовать поприставлять расширения и убедиться в том, к чему это приводит, а к чему не приводит.

Основной проблемой безопасности считаю вот какую: если с точки зрения веб-браузера разные IPFS-сайте находятся на одном и том же https://ipfs.io/ (или на одном и том же локальном гейте), то тогда XSS сильно упрощается, да и CORS также. То есть автору сайта самому надо затруднять XSS, не полагаясь на то, что браузер отвергнет посторонний скрипт на основании инохостности.

На Ычане есть доска для тестирования?

>>233584

Нѣтъ времени.

>>233615
Никто никуда не спешит. Сделай как будет время.

Найденное в реплике >>233554 несоответствие между README и реальностью — это явный баг, и по адресу https://github.com/ipfs/js-ipfs/commit/2c1340b6eeca5fb17d0c7812a1f23c5024de0584 я этот баг исправил. На это время нашлось.

А вот сочинять пример употребления IPFS во браузере у меня совсем нет времени, так что тут речь идёт скорее не про «когда будет время», а про «если будет время».

Скоро выложу скрипт.

>>233714

Надеюсь, на GitHub?

>>233758
GitHub — проприетарный сервис для соционяшечек с ужасным пользовательским соглашением, управляемый активистами SJW. Зачем в здравом уме это кому-то вообще советовать?

>>233760
Столлман, это ты? Дашь захоститься на gnu savannah?

>>233758
Да.

>>233760

>управляемый активистами SJW

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

>>233453

>также этот скрипт должен будет находить такие изображения при чтении Ычана и извлекать ссылку на оригинальные файлы из ipfs

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

>>233777

Напоминаю, что в JPEG-картинку можно втыкать https://en.wikipedia.org/wiki/Exif без потери качества её.

Напоминаю, что https://en.wikipedia.org/wiki/Extensible_Metadata_Platform можно втыкать в целый ряд форматов файлов https://en.wikipedia.org/wiki/Extensible_Metadata_Platform#Location_in_file_types без потери качества их.

>>233784
Я не спрашивал возможно ли это в принципе, я спрашивал не пошёл ли путём внесения информации через дефекты наш разработчик.

>>233790
Уже сделал это через exif. Примеры изображений можно посмотреть тут http://iichan.hk/b/res/4157230.html

>>233791
Мне нравится это.

>>233791
Надо чтобы ссылка вставлялась в пост даже у тех, у кого скрипта нет.

И попросить потом в куклоскрипт интегрировать.

>>233810
Так в последнем посте есть. Другое дело что более человекочитаемая форма не помешала бы.

>>233791

Офигенно, офигенно! На этих примерах видно, что Exif-информация из иллюстраций сохраняется Иичаном и в предпросмотровых миниатюрах! Весьма одобряю.

>>233544

> Пока мы предлагаем свои идеи для улучшения Иичана, из темы /d/ мы не выходим.

Так точно господин начальник!

>>233811
No way.

>>233828
?

>>233829
Потому что гладиолус.

При попытке загрузки файла с девиантарта выдало

>Software error:
>Possible IE XSS exploit in file
>For help, please send mail to the webmaster (cirno@iichan.hk), giving this error message and the time and date of the error.

Помощь мне не нужна, так что ничего на почту не слал.

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

Я не могу в ui и в текущей версии при отправке поста файлы больше чем разрешено на доске заменяются на превью с встроенным хэшем, а оригинал загружается в ipfs, при просмотре треда скрипт анализирует все превью и при наличии хэша в файле заменяет ссылку на оригинал. То есть пользоваться будет не очень удобно.
Хотелось бы сделать скрипт в виде расширения к Куклоскрипту, но мне пока не известно как это сделать.

>>233917
Это все равно намного лучше чем ничего.

>>233918
Тогда завтра заливаю на гитхаб. Только за качество кода сильно не пинайте.

>>233917
А просто ссылку в начале поста добавлять для тех у кого скрипта нет он не будет?

>>233932

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

>>233934
Ссылку на полную не пережатую версию картинки же!

Если автор скрипта выложит его на GitHub, как собирался, то тогда можно будет этот скрипт форкать, править, отсылать запросы на слияние — и тем невозбранно достигать желаемых улучшений.

Скрипт https://github.com/Kalaver/ii2ipfs

Форкнул, правил, отправил запрос на слияние.

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

>>233969
У меня вопрос — в достаточной ли мере мы доверяем rawgit.com, чтобы вызывать исполняемый код оттуда из user.js?
Предлагаю скачать код, сохранить его в ipfs и вызывать уже оттуда, через https://127.0.0.1:8080/ipfs/что-то. Разумеется при установке скрипта нужно будет сделать ipfs pin add.
В этом плане гарантия, которую даёт ipfs для неизменности контента, будет вполне в кассу.
А еще можно просто скачать этот piexif.js и положить рядом, благо он не слишком большой и лицензия позволяет. Но в любом случае, с ходу запускать у себя дома неизвестно что с левого сайта — не дело.

>>234085
https://wiki.greasespot.net/Metadata_Block#.40require
Или покурить маны.

>>234087
Никакого @require я там не вижу. Вижу https://github.com/Kalaver/ii2ipfs/blob/master/src/ii2ipfs.user.js#L416

>>234088
Потому что автор скрипта явно не знал о нём.

>>234089
Потому что это мой первый userscript.

>>234091
Ну, собственно, я до сего момента тоже про него не знал. В этом криминала нет. Но вот прямой вызов исполняемого кода с чужого сайта — как правило, плохая идея независимо от этого знания.

>>234092
Как же тогда сделать? Через @require напрямую с гитхаба? А будет ли это работать ведь гитхаб отдает text/plain?

А гитхаб типа не чужой сайт?

>>234093
Ну… как ты мог заметить, я с задачей "подключить чужой код к скрипту для Greasemonkey" до сих пор не сталкивался (иначе бы, скорее всего, знал про @require). Так что мы в этом вопросе в равном положении. Ищи, что я могу сказать. Наверняка не ты первый.
Возможно, оно проглотит text/plain. Возможно, можно заставить гитхаб отдавать что-то еще. Наконец, что в первую очередь приходит в голову (но не факт, что это правильное решение!) — таки сделать зеркало всего этого дела в ipfs/ipns и устанавливать уже с него.

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

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

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

Но это не потому, что я не доверяю этому сайту: я вполне доверяю ему.

Просто я заметил, что по адресу http://rawgit.com/ есть предупреждение о том, что чрезмерный траффик по адресу rawgit.com/user/repo/branch/file будет забанен, а надо cdn.rawgit.com/user/repo/tag/file использовать вместо того.

Как бы не вышло, что скрипт прекратит работу по мере поступательного роста популярности его среди читателей Иичана.

>>234102

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

Что пока не было замечено.

Кто там просил выложеный в ipfs скрипт?

QmUJvzmiGLKjrSsiUWKB6gPySJjiD76gtugmjWEHnzRDjw

и QmewSsjpN7HRDjzqh3PAyuJpJpVmyTeydtf66G2cmT2XhZ с piexif.js не забудте прибить

>>234106

А запрос на слияние кода (pull request) за тебя кто будет сочинять? Мицгол?

>>234142
Некоторым хватает ума не регистрироваться на этом вашем гитхабе. Проявите понимание, ну всё таки.

>>234142
Он ничем не отличается от оигинального кроме собственно ссылок. Не вижу смысла.

> Максимальный размер файлов для /b/ (бред) и /vg/ (видеоигры) повышен до 3 мегабайт.

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

>>234220
Огромное спасибо Мод-тян! Теперь и гифки можно грузить!

>>234220
Ждём текстовый /9/ в конце сентября. Спасибо, Мод-тян!

>>234220

Мод-тян!

Хотелось бы видеть эту новость не только во Твиттере, но также и в /n/

Я-то во Твиттере прочёл, а вот некоторые другие читатели Иичана, ко Твиттеру никакого отношения не имеющие, могут не прочесть — и оттого останутся они неосведомлёнными. Не очень хорошо.

>>234239
Про размеры файлов, бамплимиты и прочую мелочь в /n/ традиционно не пишут.
Точнее, про бамплимиты была ровно один раз за компанию с открытием досок, когда по всему сайту массово подняли с 50 до 100.

>>234244
Оно всё для осознанных подписчиков делается, очевидно.

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

>>234246

>>234245

>>234247
>>234245
На данный момент да, но как-то странно: у подписчиков явно уже есть сформировавшиеся предпочтения среди досок/тредов и логичнее в рекламируемые тематические треды зазывать новых пользователей.

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

>>234249
Включу внутреннего маркетолога:

«Пятёрка лучших и худших фильмов. Тред-опрос в /tv/:
http://iichan.hk/tv/res/33291.html
#Кино #Фильмы #TV»

«Если кто-то потерял тред эроге-допила, то он теперь в /dev/:
http://410chan.org/dev/res/14488.html
#Эроге #БесконечноеЛето #EverlastingSummer»

«Держим руку на пульсе индустрии: новый тред о подсчётах продаж дисковых релизов аниме:
http://iichan.hk/a/res/1242740.html
#Аниме #Статистика #Продажи»

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

>>234239
Об этом пишется под формой постинга. Не надо плодить сущности.

>>234255
Кто вообще в нее смотрит-то? На главную хотя бы надо новость вывести.

Скрипт теперь больше не нужен?

>>234309
Скрипт видео постить позволяет например

>>234255
У меня мобильная приложенька, и формы постинга я не вижу. Оттого о новости узнал вообще из этого треда.

>>234326
И чья это проблема?

>>234329

Это проблема Мод-тян.

>>233055
А у меня открывается. Новый Хром

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

Предлагаю забанить >>234369 за распространение заведомой хѣрни в /d/.