SQLite в качестве базы данных.

[username1565]

Исходя из поста #12 (comment)

Есть идея пришпандорить базу данных SQLite.
Почему SQLite? Даже не потому, что она реляционная, а потому что она - open-source.

Для работы с базой, в будущем, будет использоваться этот код:
https://github.com/username1565/System.Data.SQLite
а именно, скомпилированный из него многовесный файл библиотеки System.Data.SQLite.dll,
с Sqlite.Interop.dll внутри.

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

Для версии наноборды с SQLite создан отдельный бранч
https://github.com/username1565/nanoboard/tree/nanodb-sqlite

SQL-файл для создания базы данных - будет здесь: nanodb-sqlite/nanodb.exe-source/Database/nanodb.sqlite3.sql

[username1565]

Пока, база данных, имеет вот такую вот структуру:

Одна таблица и куча view'ов.

В планах - следующее...

1. Дописать рекурсивные/иерархические запросы на всё дерево, здесь, либо реализовать их циклом, на шарпе.
2. Добавить отдельную таблицу, и/или поля к таблице NanoPosts, в частности поле DateTime (чтобы сортировать посты по дате в g-теге, внутри Message, и не извлекать эти даты каждый раз), поле PostMessageShort (БезАттачей, только текст, чтобы проще было хэшировать, как тут), поля POW и SIGN (чтобы не извлекать их каждый раз, из PostMessage). Думаю это всё.
3. Возможно, имело бы смысл, создание дополнительной таблицы
   Attachments, где для каждого аттача просчитывался бы хэш, заносящийся в таблицу,
   хэш, по которому можно было бы получать аттачи.
   Вообще, можно было бы стеганографировать аттачи, как нанопосты,
   но тогда, следовало бы клеить POW и каптчу к аттачам тоже. Можно было бы продумать более детально всё это дело.

А пока, одна таблица, и куча view'ов к ней.

[username1565]

На данный момент, структура базы данных, вот такая:

SQL-скрипт для её создания - здесь: https://github.com/username1565/nanoboard/blob/dbd812396319db2e41477bb0937c02f012221e9c/nanodb.exe-source/Database/nanodb.sqlite3.sql

[username1565]

SQLite3 база-данных, создаётся из этого sql-файла.
К сожалению на линукс оно чё-то не компилируется, а на винде компилируется.

Тыкая и тестируя эту базу данных, и перечитав по диагонали README.md,
я понял следующее.

• В основе наноборды лежит хэш-таблица: {"PostHash": "ReplyToAndPostMessage"}
  Это и есть основа наноборды, которая может быть легко реализована на любых языках программирования.
  Именно распределённость, и диверсификация этой хэш-таблицы, делает наноборду неубиваемой и принципиально немочерируемой.

Коллизии хэша, для различных сообщений, могут быть исключены,
путём банальной перегенерации POW-значения, меняющего PostMessage, и как следствие - PostHash.
Таким образом, PostHash уникален в хэш-таблице,
и может быть первичным ключем в базе данных,
однозначно идентифицирующим NanoPost.

Дальшейшее преобразование данной хэш-таблицы в таблицу вида:
| PostHash | ReplyToHash | PostMessage |
позволяет исключить постояннное разрезание значения ReplyToAndPostMessage на ReplyToHash и PostMessage,
выполнив это однократно, для всех нанопостов, добавляемых в базу данных.
Поле таблицы ReplyToHash может быть внешним ключем,
ссылающимся на первичный ключ PostHash,
и уже вот такая таблица, она, может являть собой
неограниченно-ветвящееся дерево нанопостов, и тредов.

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

[username1565]

Распределённая хэш-таблица, это ничто иное как DHT в децентрализованных сетях : https://ru.wikipedia.org/wiki/Распределённая_хеш-таблица

[username1565]

Поскольку для достижения максимальной немочерируемости, хранение хэш-таблицы,
должно бы быть распределённым,
наилучшим вариантом диверсифицированного хранения хэш-таблицы,
было бы хранение её в децентрализованной сети, как в BitTorrent.
Тогда, надо бы сделать ноды, и PEX - Peer Exchange между ними, и синхронизацию DHT.

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

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

[username1565]

Я не знаю, как скомпилировать код из бранча nanodb-sqlite
(с этой вот DLL-кой: System.Data.SQLite.dll, а именно этой - она одна там, без SQLite.Interop.dll), и как сделать эту компиляцию с помощью mono, на linux.
Пытался запустить build.sh, но оно выдаёт какие-то ошибки.
На Windows XP, с .net framework 4.0 - компилируется нормально, вроде.

Также, я не знаю, как скомпилировать linux-версию из кода https://github.com/username1565/System.Data.SQLite с помощью mono, и как подключить всё это в CSHarp.

Я уже достаточно напердолился с этой нбордой, на голом энтузиазме.
Никто мне за это не платил, более того, крысинные wavesplatform, украли у меня последней крипты на сумму 500 килобаксов: https://github.com/username1565/Waves/blob/scam-theft-rats/README.md
Я уже заебался требовать косари свои ебучие, от этих усосавшихся крыс.
Мой ноут сдох вчера. Полетел винт. Пишу с телефона.
У нас началась ХУЙНА на Украхе. Пол инета не пашет, блядь.
Разработку бороды заканчиваю, если всю эту ебанину можно назвать разработкой конечно.
Хотя, если будет время, возможность, и желание, возможно буду продолжать попёрдывать коммитами в разные бранчи.

Вся эта канитель с sqlite задумывалась для того, чтобы впилить нормальную базу данных,
реляционную, с открытым исходным кодом.
Почему реляционную? Чтобы взаимосвязывать таблицы там, исключая дублирование данных.
Старая база данных, не позволяет связывать множество таблиц, в то время как sqlite - позволяет.
Это позволило бы развивать наноборду усложняя структуру базы данных, в будущем.

Сидел ломал голову над структурой постов, и когда думал над аттачами (этим вот длинным бейсом, снутри нанопостов),
то было решено сохранить их отдельно, и отдавать эти аттачи по AttachmentID,
который являет собой попросту sha256-хэш контента аттача.
Но в файле Captcha.cs производится замена длинного бейса аттачей на некий другой хэш ExceptXMGHash,
чтобы быстрее считалась Pow, PowHash и CaptchaIndex.
Поэтому, ExceptXMGHash был добавлен в базу данных, как ещё один возможный идентификатор,
по которому можно отдать аттач.
Для возврата аттачей по AttachmentID или ExceptXMGHash - были впилены два хендлера в DbApiHandler.cs.

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

Для чего отдавать аттачи по AttachmentID или ExceptXMGHash?
А если поднято много lite-серверов и в публичном доступе они,
то можно быстро выгрузить все необходимые аттачи - прямиком по их хэшам, из децентрализованной сети.
Аттачи, могли бы также быть многовесными.
Но тогда, в картинку их не засунуть, и стеганографировать их смысла нет.
Поэтому, можно было бы вынести их хранение в дата-центры, там поднять lite-server'ы,
например, и отдавать эти аттачи, по хэшам, как в торрентах, отдаются файлы по магнет-ссылкам.
Внутрь нанопостов же, просто засунуть превьюшки, или эти вот - хэши аттачей.
Также, могла бы быть впилена поддержка IPFS (там до гигабайта можно хранить, вроде).

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

Вообще, если так подумать, то для того чтобы слить базу, достаточно просто отдать 0.db3 и index-3.json, с lite-server'a.
Но так как эти файлы могут быть заняты, при поднятом сервере, и залочены, то для синхры серверов,
я запилил эти вот три хендлера "download-posts", "upload-posts", "upload-post"

nanoboard/nanodb.exe-source/Server/DbApiHandler.cs

Lines 40 to 42 in 8f0edd8

	_handlers["download-posts"] = Download_Posts; //download posts by url, from another nanodb server.
	_handlers["upload-posts"] = Upload_Posts; //upload posts to another nanodb server, like Bitmessage-retranslation.
	_handlers["upload-post"] = Upload_Post; //upload posts to another nanodb server, like Bitmessage-retranslation.

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

Также, потомкам, скажу, что в идеале, следовало бы запилить пиринговую сеть, в которой lite-server'ы могли бы синхронизироваться децентрализованно, и диверсифицированно хранить всю хэш-таблицу с нанопостами и аттачами.
И чтобы всё это работало в LAN - только так можно добиться принципиальной немочерируемости заебатой.

И ещё. Что я думал сделать, так это впилить некоего IRC-бота.
Потому что IRC-сервера можно поднимать в локалке, и если там будет IRC-бот, то он мог бы ретранслировать нанопосты на некий IRC-канал, и оттуда, с этих каналов, также мог бы идти коллект нанопостов.
Не помешало бы также впилить поддержку Socks4/5 чтобы прямо в tor коннектится, куда-нибудь на 127.0.0.0:9050
для пущей анонимизации, а то IRC хоть и может работать в локалках, но он не очень-то и анонимен.

[username1565]

Сбилдил здесь mattleibow/Mono.Data.Sqlite#4
Mono.Data.Sqlite.dll вместе с sqlite3.dll оно работает. sqlite3.dll - это переименованный System.Data.SQLite.dll, с SQLite.Interop.dll внутри.