>>1000685
На это первое апреля была музыка же.
>>/b/1006241

В первом приближении bulk deletion для Автобуса готово.

В принципе, можно сюда, но без правок не выйдет. Даже по схеме успели разойтись! В одном столбце, правда.

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

1. Объеденить post_* в одну таблицу, выпилив текстоборды.
2. Посолить KU_RANDOMSEED'ом ipmd5, ибо в текущем виде это от утечки БД не защита; look-up таблица в 4 * (2 ** 32) = 16 GiB в оперативке ноутбука уместится. Или, наоборот, выпилить и ipmd5, и ipenc, сделав простое и быстрое поле в 4 байта.
3. Придумать индексы для таблиц. Скажем, (board_id, parent_id, id) в качестве кластерного для posts, (board_id, ip, id) для быстрого поиска по ip, (board_id, parent_id, posted_at) для бампов, и так далее.
3.a) Есть ли смысл включать флаги в индексы? has_sage, в силу перманентности, наверное стоит, сделав (board_id, parent_id, posted_at) фильтрованным. MariaDB в такое, правда, не может, но повод перейти на Postgres как раз таки. А вот is_deleted, хоть по нему фильтрация почти везде, может включением в индекс существенно замедлить удаление из-за необходимости в ребалансировке. Или нет? Не знаю. Почему-то я помню, что InnoDB, даже если столбец-флаг в конец ключа поставить, всё равно при измении внутри ребалансировку делает: сначала удаляет leaf, потом добавляет на то же место. Но это не точно.
3.b) Есть ли смысл поменять parentid=0 для открывающих постов тредов на parentid=id? Чтобы без union'ов select'нуть весь тред по const ref. Но тогда нельзя будет select'нуть ОП'ы тредов по const ref. Хотя опять же, проблема решается созданием filtered index. Так что всё-таки следует. Любопытно, что в class="ref|parentid|id" у нас именно такой формат.
3.c) Добавить столбец, где кэшировать отрезок из последних 7 постов треда, и столбец, где кэшировать вывод для read.php.
3.d) Пользуется ли кто-то watchedthreads? Если да, то не переделать ли на более щадящую архитектуру, где пользователь запоминает в local storage, какие он смотрит треды, и спрашивает у сервера только их последние IDшники? Если нет, то не выпилить ли?
3.e) И так далее.

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

ПОЖЕЛАНИЕ!
Сделайте лучше нормальный тёмный стиль! И чтобы с сотового работало!
А то я даже не знаю как в мобильной версии переключить, чтобы хотябы на bluemoon. Который тоде недостаочно тёмен всё равно.
На пк у меня расширение со своим стилем, а на мобильном вроде тоже можно как-то настроить но жто разбьираться надо. И с работы когда или с ноутбука то тоже везде надо настроить ведь. А сейчас только на домашнем пк!

>>1000693
Android?

>>1000694
У мкеня и то и другое!

> И чтобы с сотового работало!
Тут тоже непонятно. Чтобы стиль работал, или вообще что-то другое работало. А то FBE всё адаптировали да адаптировали под эти мобилки, н ж уже респонсивный(tm) , а всё зря, постеры-то разбежались lol. Для будущих поколений работа прям..

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

>>1000693
Сейчас переключить можно, открыв desktop'ную версию сайта, и переключившись по выбору нужного стиля обратно на мобильную. Либо так, либо некими браузерными дополнениями, где можно задать пользовательские стили для сайта.

Проблема в том, что, если я верно помню, некоторые свойства для мобилок у стилей, кроме Умночана, не определены.

И надо подумать, куда ставить кнопку переключения в мобильной версии. Может, отдельную форму настроек, где стиль, вариант капчи, и подобное можно будет поменять; сделать значок-шестерёнку и вместо/слева от watchedthreads её поставить?

> Сделайте лучше нормальный тёмный стиль!
> На пк у меня расширение со своим стилем
Запостите же.

>>1000697
Sticky нет, не умеет. Умеет зависать (lingering) на какое-то количество секунд, если PHP неожиданно сделало echo, по истечению которых происходит перенаправление. Сделать кнопку, чтоб закреплялось? И сделать, чтобы перенаправляло сразу, но по перенаправлению восстанавливало показываемый status bar. Может, также дать возможность открепить движением мышки, как с формой быстрого ответа?

Другое дело, что в текущем виде у status bar'а стиль ярко-красным кричащий об ошибке, а для чего-то нейтрального, наверное, и цвета понейтральнее?

На сервере, если по-простому, добавить exitWithNotification($message, $redirect_to).

Альтернативно, endpoint, проверяющий наличие hash'а в базе, чтобы можно было по выбору файла в JSе посчитать его md5 и тут же отправить на сервер, не дожидаясь отправки поста вместе с файлом целиком. read.php ведь позволяем без капч и ограничений; если сделать индекс по хэшу, будет не затратнее. Но это если индекс. Так что я бы сначала в целом базу поправил.

>>1000696
Да, я про стиль. Так по работе особо ничего поломанного не замечалось.

>>1000700
>открыв desktop'ную версию сайта, и переключившись
Я так на андроиде делаю, но айфон игнорирует переключение на полную версиюб и не пееключает почему-то. Хотя другие сайты переключает.
>Запостите же.
Там просто покрашеный умночан по мотивам одной другой картинколоски. Есть пару мест которые недоделаны, но я и так живу.
У меня там с годами совсем каша была и кучас своих пометочек, так что попросила ИИ поправить, вроде ничего не сломалось.
https://pastes.io/cBPq0Tsf

>>1000701
> https://pastes.io/cBPq0Tsf
В целом, цветовая схема понятна. Mint назвать?
Если Якуй одобрит, займусь кнопкой, чтобы и на мобильной версии переключалось, после >>1000697, наверное.
> У меня там с годами совсем каша была и кучас своих пометочек, так что попросила ИИ поправить, вроде ничего не сломалось.
Но сам CSS, буде тот приведён в соответсвие с https://codeberg.org/yakui-lover/fbe-410/src/branch/kotocafe/css/umnochan.css, наверное, можно и сейчас добавить. Пока вижу, что стиль кнопки переключения стилей отличается, и что спойлер не сплошным цветом и что с задержкой по наведению курсора исчезает (наверное, серым в тон текста сделать).

> Заголовок слева у предпросмотра теперь показывает «Предпросмотр»
Хорошо.

Сломан постинг видеов, поскольку теперь imgWidth/Height строго int и вывод ffprobe нужно конвертировать. Патч в архиве.

>>1000708
Принято.

>>1000690
>Объеденить post_* в одну таблицу, выпилив текстоборды.
Это надо будет не просто переписать всю логику запросов, но и логику инкремента счётчика постов. В Постгре-то точно счётчики есть...
>Посолить KU_RANDOMSEED'ом ipmd5, ибо в текущем виде это от утечки БД не защита
Пусть будет одно решение для паролей и ип, пусть и разные соли. Зачем в оригинале два столбца не слишком понятно.
...хотя "посмотреть посты с подсети" теоретически хорошая вещь.
>(board_id, ip, id) для быстрого поиска по ip
id тут не требуется.
>Есть ли смысл включать флаги в индексы?
Наверное не в наших объёмах. После всей фильтрации, они будут отрабатывать на, сколько, 250 постах максимум за раз? Ну, больше чтобы сделать индекс если мы будем бесконечно резиновыми или если подлодка.
>Есть ли смысл поменять parentid=0 для открывающих постов тредов на parentid=id? Чтобы без union'ов select'нуть весь тред по const ref.
Я в своей лабуде решал это через отдельную таблицу для тредов. Туда уже пихается sticky/locked/счётчики видимых постов.
>последних 7 постов треда
Последних N постов треда, это настраиваемая опция. И раз она конфиг-зависимая, наверное нет.
>столбец, где кэшировать вывод для read.php
Там разве вывод хоть как-то отличается? Или в том плане, чтобы шаблонизатор не дёргать? Тогда лучше жсон отдавать, ибо головная боль будет при пересборке кешей ещё и всю БД переписывать.

>>1000700
>Но это если индекс
file_md5 уже индексируется.
>Альтернативно, endpoint, проверяющий наличие hash'а в базе, чтобы можно было по выбору файла в JSе посчитать его md5 и тут же отправить на сервер, не дожидаясь отправки поста вместе с файлом целиком.
Удобно, можно и так.
>read.php ведь позволяем без капч и ограничений
И постопревью, да.

>>1000706
>Если Якуй одобрит
Мне-то что, я не против даже что сейчас дали залить.

Алсо, я всё ещё не >>1000340

>>1000700
Словом "sticky" хотелось передать поведение
> по перенаправлению восстанавливало показываемый status bar
Который висит и ждет нажатия юзверем крестика, после чего пропадает, стирается, исчезает.

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

> а для чего-то нейтрального, наверное, и цвета понейтральнее?
Да.

> endpoint, проверяющий наличие hash'а в базе
Тут подумалось, что можно сообщение "было запощено тут и тут" выводить в качестве ("ложного") "post preview", переиспользуя эту фичу.

>>1000710
> 2024
Так и вся жизнь пройдёт w.

На основном fbe зачем-то убрали каноничную сажирующую стрелочку вниз в "теме" у постов, которая была с нами годами! Заменив какой-то непонятной фигней, которую я рассматривал через экранную лупу, пытаясь понять, что это. Расстроили.

>>1000709
> но и логику инкремента счётчика постов
Добавить в boards столбец new_post_id, и insert'ить в posts как-то так.
WITH new_id_source AS (
  UPDATE boards
  SET new_post_id = new_post_id + 1
  WHERE board_id = :board_id
  RETURNING old.new_post_id AS post_id_to_insert
)
INSERT INTO posts
SELECT :board_id, post_id_to_insert, :parent_id, ...
FROM new_id_source

> Зачем в оригинале два столбца не слишком понятно.
Дело в том, что Kusaba'вый md5_encrypt шифрует с nonce'ом (N_once) — случайно генерируемым значением, из-за которого шифротекст всегда разный — даже если IPшники одинаковые.

Поэтому, если бы не ipmd5 столбец, пришлось бы ходить foreach'ем по SELECT `id`, `ip` FROM `posts_*` WHERE NOT IS_DELETED, чтобы найти все посты по нужному IP. Хотя, now that I think of it, md5_decrypt можно написать и на SQL, чтобы не дёргать лишнего с базы, но это всё равно ходить по всем постам, пусть и не в PHP.

Поэтому, если хочется этого избежать, то столбца нужно два. Либо два столбца; либо сменить алгоритм шифрования с md5_encrypt на что-то более удобное для поиска, что по-хорошему и стоит сделать.

https://www.cryptologie.net/posts/key-wrapping-and-nonce-misuse-resistance/
Насколько я понимаю, в самом PHP нету детерминистичных алгоритмов шифрования, не уязвимых к keywrap/keystream reuse attack, когда nonce константа.

Надо будет добавить extension=openssl в php.ini и взять AES-128-SIV оттуда; впрочем, ничего сложного.

> Пусть будет одно решение для паролей и ип, пусть и разные соли
Если делать 1 столбец для IP, то решение для паролей будет другое. Думается взять в качестве хэша либо bcrypt(sha512(password)), либо openssl_pbkdf2() с SHA-256.

Для файлов тоже SHA-256? Apparently, MD5 нету в браузерном Web Crypto API. А если какие-то дополнительные lib'ы тянуть, то появляется смысл перейти на blake2 (b2sum), который без коллизий и быстрее. Или даже на blake3, но тут lib'а уже и для PHP понадобится.

> id тут не требуется
Даже чтобы id-шники по IP шли в порядке возрастания, как оно, наверное, сейчас?

InnoDB по-тихому добавляет незадействованные столбцы кластерного индекса в конец других индексов. Что, если делать (board_id, parent_id, post_id) кластерным индексом, думаю, привело бы к тому, что IDшники в индексе по IP шли бы в порядке тредов, а не в порядке возрастания, как оно, предполагаю, сейчас.

Маны PostgreSQL говорят, что у них heap и нету кластерных индексов, так что будут отображаться в порядке добавления в таблицу? Наверное, и правда не надо. Хотя если вдруг захочется 'ORDER BY id DESC', могло бы быть полезно.

> Я в своей лабуде решал это через отдельную таблицу для тредов. Туда уже пихается sticky/locked/счётчики видимых постов.
С Postgres я всё-таки склоняюсь к тому, чтобы не нормализовать posts. Меньше join'ов писать и базе меньше join'ов делать. Postgres пропускает помеченные, как NULL, значения в записи строки, так что меньше места на диске база от выноса специфики про файлы и треды в отдельные талбицы занимать не станет.

> Последних N постов треда, это настраиваемая опция. И раз она конфиг-зависимая, наверное нет.
Добавить в таблицу posts столбец cache_timestamp, который заполнять и сравнивать с timestamp'ом конфига и timestamp'ом настроек доски для тредов, охватываемых генерацией их страниц и страниц досок.

> Там разве вывод хоть как-то отличается? Или в том плане, чтобы шаблонизатор не дёргать?
Отличается вывод или нет, точно не знаю, но да, чтобы отдать готовый HTML.

Насколько я понимаю, этот HTML поста иммутабельный и меняется разве что если посту файл удалить или настройки для доски/глобальные поменяются. Как правило, не меняются последние N постов тредов на страницах досок. Как правило, не меняются и сами эти страницы. Не всегда меняются +50 и -100 при удалении постов или их прикреплённых файлов. Пока не меняются настройки доски, форма постинга на её страницах иммутабельна за исключением "Ныне N уникальных клиентов".

Вообще говоря, при добавлении/удалении постов, из страниц всегда меняется только страница каталога.

Так что тут простор для кэширования довольно большой. Мне не кажется, что это очень уж сложно, хотя и требует переписать FBE значительных переделок.

Так что я бы пока добавил в boards и posts необходимые для кэшей столбцы, пусть будут DEFAULT NULL, чтобы не мешало тому, как оно сейчас есть.

И как-нибудь потом потихоньку, не трогая Кусабу, завёл в inc отдельную директорию services, где держал бы новые DeletePostService, CreatePostService, UpdatePostCacheService, GenerateThreadPageService и так далее, потихоньку привязывая endpoint'ы к ним.

Некоторое свободное время/желание пока есть.

>>1000712
> либо openssl_pbkdf2() с SHA-256
On the other hand, всё-таки несколько медленноватое оно даже при не столь высоком количестве итераций. Если постер потрудится запомнить ещё 3—4 лишних символа или ещё одно слово, то hash_hmac('sha256', $pwd, KU_RANDOMSEED) будет с тем же эффектом, но без нагрузки на сервер. Явно указать где-нибудь в FAQ алгоритм хэширования и минимальную длину пароля, если хочется, чтобы и ASICом на 2**50 H/sec не проняло.

>>1000712
>Насколько я понимаю, в самом PHP нету детерминистичных алгоритмов шифрования, не уязвимых к keywrap/keystream reuse attack, когда nonce константа.
У атакующего нет возможности сделать произвольный айпишник.
>Даже чтобы id-шники по IP шли в порядке возрастания, как оно, наверное, сейчас?
Eh, оверкилл в общем случае наверное. Но стоит.
>Apparently, MD5 нету в браузерном Web Crypto API.
Там вообще хеширования нет, лол.
>то появляется смысл
Смысл есть использовать то, что используют все, чтобы поискав картинку на данбуре не приходилось пересчитывать хеш для поиска тут.
>Если делать 1 столбец для IP, то решение для паролей будет другое.
Айпишник тот же пароль, только короче. Хотя можно ipv6 форсировать.
>Не всегда меняются +50 и -100 при удалении постов или их прикреплённых файлов.
-100 меняется всегда кроме удаления верхних файлов.
>Вообще говоря, при добавлении/удалении постов, из страниц всегда меняется только страница каталога.
И страница треда.
>Так что тут простор для кэширования довольно большой.
Люди для этого обычно кеширующий сервер ставят...

>>1000714
Если я хочу использовать :) в качестве пароля, никот не должен мне это запрещать, особенно когда под этим паролем ничего кроме возможности удалить пост нет. ИМО.

>>1000715
> У атакующего нет возможности сделать произвольный айпишник
https://hacker101.linuxsec.org/vulnerabilities/stream_reuse
А произвольный и не обязательно. Если nonce константа, то в зависимости от алгоритма, насколько я понимаю, достаточно одного поста в утёкшей базе, для которого атакующему IPшник уже известен, чтобы получать IPшники к остальным.

AES не streaming chipher, но там вроде какие-то свои проблемы, раз сделали AES-SIV специально для. Так что стоит использовать AES-SIV.

> Там вообще хеширования нет, лол.
Но оно там есть? Pic related.

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

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

> Айпишник тот же пароль, только короче.
Если мы для IPшников храним только хэш, то разве не теряем возможность забанить оставившего пост по подсети? И разве IP постеров в модерке (например, на странице жалоб) отображаются не в голом виде? (Хотя, можно отображать и хэш.)
А для паролей достаточно хранить только хэш.
В этом разница.

> Люди для этого обычно кеширующий сервер ставят...
Redis? Хм. Могу и так, но с БД-only в первом приближении несколько проще сделать, мне кажется.

> Если я хочу использовать :) в качестве пароля, никот не должен мне это запрещать, особенно когда под этим паролем ничего кроме возможности удалить пост нет. ИМО.
А запрещать и не предлагается. Предлагается поставить совет в FAQ. Или, что точнее, заметку.

>>1000716
>Хотя какой-нибудь весельчак когда-нибудь начнёт пытаться постить файлы с одинаковыми или прикольными хэшами for lulz.
В очередной раз, не тот масштаб... Плюс у нас нет запрета на репост если только не в том же треде. В архиве у меня параноя-мод и при коллизии сравниваются разрешение, размеры и затем побитово.
>Стоит ли ..?
Если интересно, то пусть делается, единственные две преграды что я вижу: 1. Это не работает 2. Это недоделано.
>картинки бывает пережимаются
Или кто-то в них раржпег кидает, ага.
>Если мы для IPшников храним только хэш, то разве не теряем возможность забанить оставившего пост по подсети
А, точно. И в голом, чтобы можно было подсеть определить в случае однотипных банов. Может для джениторов только хешем правда. Тогда вопроса нет. И я даже не уверен, влезет ли сейчас сюда ipv6.
В постгре под них даже свой тип, но без встроенного шифрования... но удобно было бы смотреть посты с подсети наверное.

Кстати о встроенном, есть https://dev.mysql.com/doc/refman/8.4/en/encryption-functions.html или https://www.postgresql.org/docs/current/pgcrypto.html. Хоть я и не люблю выносить код из кода в БД, и для постгри это отдельный модуль ставить, но может можно использовать так.
>с БД-only в первом приближении несколько проще сделать, мне кажется.
Мне просто кажется что проще просто выкинуть шаблоны и всё во фронте рисовать чем заниматься кешем ручками.

Попробовал посмотреть, насколько применим fingerprint картинок, который phash, к Булочным картинкам.

Картинки брал с 15544700221 по 176095181827 без гифок, всего 16112 картинок.

Находится 113 групп по одинаковому phash, состоящих из двух или более картинок: только в одной из этих групп картинок 3, а в остальных по паре дубликатов.

Из них 6 false positive.
(>>/b/5852, >>/b/10732), (>>/b/3154, >>/b/3161), (>>/b/2512, >>/b/8466), (>>/b/7767, >>/b/19060), (>>/b/11092, >>/b/11456)
False positive в том плане, что это легитимные вариации той же картинки или творчество по мотивам другой, а нам скорее найти, было ли ровно то же самое уже запощено в оригинальном или переужатом виде или с другой шириной/высотой.

41 из тех 113 — целиком посты, у которых MD5 пикселей совпадают, то бишь lossless переужатие/оптимизация или какое-нибудь echo 'new_hash' >> file.jpg.

Остальные 113 - 41 - 6 = 66 — ужатые с потерями или с изменением разрешения дубликаты, которые попиксельным сравнением не найти. Например, (>>/b/12578, >>/b/12935), (>>/b/16642, >>/b/18597), (>>/b/3372, >>/b/4413).

Однако, увы, находит оно их ужатые с потерями не все.

Попробовал увеличить размер phash с 64 бит до 256, и, внезапно, нашло ранее не обнаруженый (>>/b/5816, >>/b/7377). Хотя казалось бы, большая специфичность, и я 16x16 окно чтобы false positives убрать тестировал. False positive там действительно получилось на 4 меньше, но появляется false negative и значимо чаще; всего найдено было 99 групп, когда phash 256 битов, против 113, когда phash 64.

Если повышать чувствительность, группируя phash'и, не чтобы равны были, а чтобы на растоянии не более чем в N отличающихся битах, false positives становятся куда менее опрятными, хотя настоящих дубликатов и находится больше.

Для 64-битного phash, когда N равно 4, посчитало равными >>/b/11948 и >>/b/16305, что уж совсем грубая ошибка. Впрочем, настолько грубая она там была единственная. Чаще (>>/b/22454, >>/b/22462), (>>/b/8097, >>/b/15811), (>>/b/8481, >>/b/8513, >>/b/8614). Что в определённых случаях даже и хорошо, когда интересно поискать похожие, а не только одинаковые картинки или удостовериться, что ничего одинакового почти наверняка нет. Но, хм. Скажем, видит человек >>/b/23618, решает >>/b/23620 edit сделать и запостить, а ему раздражающее уведомление про только что переделанный якобы дубликат, которое надо специально закрывать.

Так что если делать автоподгрузку ссылок на посты, где картинки скорее всего одинаковые, пусть, наверное, будет либо только по равенству MD5 пикселей или только по равенству phash'ей (?), но не по расстоянию меж. Как и куда вынести возможность поиска по расстоянию, если делать, надо будет думать. Особенно так, чтобы и без скриптов работало.

>>1000718
> Чаще (>>/b/22454, >>/b/22462)
Не >>/b/22454, а >>/b/22452, то бишь.

Это, и Булочные, то бишь, bulochka.org.

Если запиливать IPv6, какой длины префикс брать для faptcha attempts?

> https://dreamserver.ro/en/lir-services/ipv6-lease/
5 евро в год за /48 и 100 евро в год за /32
> https://www.ipxo.com/free-ipv6/
Эти вот дают /36 на месяц даром.

Наверное, тут по-хорошему нужен какой-то сложный rate limiter.

Маловероятно одновременное несовпадение фапчи у многих пользователей с той же /32 подсети. Так что пока пойду таким путём.

Для /64 пусть ограничение будет, как есть: до двух провальных попыток.

Смотрим на /64, но до этого смотрим на /n in range(32, 64, 4), где ставим threshold на количество провальных попыток, как 2 * (log(64 - n)**3), получая пределы 83, 73, 64, 53, 42, 30, 17, 5 на подсети с /32 по /64 соответственно.

Конечно, текущая капча в целом скорее декоративный забор, чем серьёзное препятствие человеку с намереньями. Но если делать на чёрный день более сложные её варианты, делать rate limit на прокрутку или на что-то ещё, будет задел.

Я думала, капча на сессию куки ставится, а не на айпи.

А, речь про неправильные попытки отгадывания, я бака. Наверно, имеет смысл взять принцип схожий с принципом, используемым с IPv4. То есть, если для каждого адреса IPv4 вводится ограничение (/32), то и для IPv6 адресов имеет смысл ограничить ровно такое же количесто энтропии (/32 подсеть для адреса). Но это так, рассуждения с дивана. Интуиция подсказывает, что это может быть слишком ограничительная мера, нужна реальная статистика использования v6 адресов на самом сайте и в Интернете вообще.

В RSS у ОПов тредов страница 0.html.

>014.cdn.ganbaranai.moe
Однако.

>>1000728
> то и для IPv6 адресов имеет смысл ограничить ровно такое же количесто энтропии (/32 подсеть для адреса)
https://networkingtoolbox.net/reference/ipv6-prefix-lengths
/32 подсеть в IPv6 — это целый провайдер. Но может быть и атакующий, арендовавший за $10 подсеть на месяц. В том проблема.

Как пишут, конечным пользователям обычно дают /64. Но могут давать и больше или меньше.

>>1000731
Блокировать /32 если в его пределах уже есть несколько (сколько?) заблокированных /64?

>>1000732
> сколько
Пока ничего умнее, чем
> Смотрим на /64, но до этого смотрим на /n in range(32, 64, 4), где ставим threshold на количество провальных попыток, как 2 * (log(64 - n)**3), получая пределы 83, 73, 64, 53, 42, 30, 17, 5 на подсети с /32 по /64 соответственно.
Не придумал.

Разве что добавлять некий scaling factor на основании hash(subnet, salt) и/или hash(time, salt), чтобы было сложнее понять, есть ли кто-то ещё в той же подсети или нет, перегрузив систему.

По схожему принципу ограничивать количество фапчесессий и частоту отправки тредов/постов, наверное.

Небольшое замечание:
https://014chan.org/favicon.png > 404
https://014chan.org/favicon.ico > favicon.ico который СОВСЕМ не ico - [0x89 0x50 0x4E 0x47] вместо [0x00 0x00 0x01 0x00]

Забавно.

Хотелось бы выяснить - где-то есть актуальная версия автобусодвижка в том виде, в каком он используется тут?
https://codeberg.org/yakui-lover/fbe-410 явно не соответствует ситуации на данный момент - даже сравнивая справку по разметке с тем что тут в коде. Это намеренно так?

>>1000743
https://codeberg.org/yakui-lover/fbe-410/src/branch/kotocafe

>>1000744
Вот же бака...
Благодарю.

>>1000745
Там всё ещё может быть лаг в пару незначительных правок.
Но всё же, ссылка снизу страницы ведёт именно туда.