Авиабаза распределённая

мысли вслух по поводу архитектуры и решений (много букв)
 
1 2 3
+
-
edit
 

Balancer

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

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

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

— Простой в использовании — значит, не требующий от пользователей особых знаний. Да, в том же FreeNet или хотя бы за i2p сейчас можно построить прекрасно защищённую систему, заблокировать которую на уровне нынешних законов будет сложно (хотя при сильном закручивании гаек в будущем — легко, конечно). То есть, желательно иметь возможность заходить простому пользователю через один только браузер.

— Про прибыль — понятно. Хочется иметь хоть какую-то отдачу от затрат на такой проект кроме моральной :) Тем более, что моральной отдачи всё равно с каждым годом в Интернете всё меньше, одна ложка дёгтя недовольных сводит на нет весь позитив от молчаливой бочки мёда удовлетворённых.

Какие особенности и компоненты должны быть в системе.

— Единая база пользователей. Полная анонимность и безнаказанность губительна по целому ряду причин. Начиная от простого г***ометания, кончая спамерами. Даже во FreeNet пришлось вводить систему WebOfTrust, реализующую пусть и анонимную, но систему оценок/рейтингов. Иначе — никак.

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

— Вообще, нужно очень много внимания уделять data-mining'у, автоматизации поиска актуальных материалов.

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

Компоненты могут быть разных классов:

— Сайты. Пока фактически у нас реализована только сама Авиабаза. Из которой потенциально могут отпочковаться несколько разделов, в первую очередь — флотский. Со статической частью проблем нет. Уже вполне работает (хотя окончательно не допилен) вариант построения сайта через DVCS и Zim-Wiki: Новый формат разработки сайтов. И airbase.ru в частности. Тут вообще всё просто. И писать материалы можно спокойно на локальной машине и репозитории могут быть сколь угодно распределёнными, даже в случае отказа/блокировки центрального сайта, и формат данных универсальный, поддерживаться сможет кем угодно даже без меня. Это пока самая «решённая» часть задачи.

— Форумы. Тут, с одной стороны всё понятно со логической структурой, с другой — масса концептуальных проблем с технической стороны. Понятно, что нынешний вариант с централизованной БД подходит для распределённой системы очень плохо. Можно, конечно, заниматься репликацией данных, но это сложно, капризно, уязвимо. Была у меня мысль делать форумы на DVCS. Даже на старом сервере начал эксперименты. То есть логика такая — основные данные (топики, сообщения) лежат в DVCS, откуда кешируются в базу данных, которая уже и отдаёт странички. Вопрос распределённости решается легко.

Увы, типичные объёмы наших форумов (условно — 6 млн. файлов, 10Гб данных) показали совершенную непригодность имеющихся DVCS и железа для эффективной работы (коммиты новых сообщений, отслеживания изменений).

Нарезка на мелкие категории по одной на репозиторий во-первых, спасает мало. Во-вторых — практически ставит крест на перемещении материалов (топиков) в другие категории («вынос политики с ракетомодельного»).

Теперь появилась мысль заводить по репозиторию на определённые временны́е интервалы, скажем — репозиторий на год. Или при росте объёмов — хоть на месяц. Это уже лучше, хотя и тут проблем потенциально может быть немало. Надо думать.

— Блоги. Это то, что делать надо обязательно. По сложности будет где-то между сайтами и форумами. Но вопрос совсем ещё не продуманный.

Ещё моменты. Приватность сообщений. От неё придётся отказываться полностью. Нынешние закрытые материалы придётся подвергнуть сортировке. Часть вывести снова в открытый доступ (эротика всякая, мусор/спам и т.п.), только скрыв от гостей на сайте (потому и скрывалось). Часть, реально приватное, оставить на старом движке без переноса в распределённую систему.

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

Ну, ладно, пока хватит. Буду сюда понемногу пописывать по мере кристаллизации мыслей.
 34.0.1847.11634.0.1847.116
+
-
edit
 

Balancer

администратор
★★★★☆
Более детальные мысли по распределённым форумам.

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

Нарезать, видимо, надо именно по сообщениям. Если резать по темам, то затруднится перенос сообщений между темами.

Формат хранения, думаю, нужен дублированный. JSON для обработки и что-то человекочитаемое для чтения в ручном режиме. Скажем, в формате e-mail. Аттачи можно хранить рядом с сообщениями. Хотя есть и проблема — например, хотелось бы иметь в таком же человекочитаемом виде возможность просмотра сообщений по выбранным топикам. В случае Linux можно обойтись симлинками. Но непонятно, как на такие репозитории будет реагировать Windows. Надо будет проверить... Проверил, в Git всё плохо — симлинк превращается в файл с именем, на кого указывает :-/

Хотя, с другой стороны... Может, и вправду, распределять по темам? Перемещение будет всё равно в рамках одного репозитория, просто из каталога в каталог файл скопируется. А в человекочитаемом виде можно будет оставить один файл — файл темы. Например, в формате mailbox...

В общем, решаемо, хотя надо думать.

Два вопроса пока не могу решить:

1. Вопрос идентификаторов. Теоретически сообщения могут писаться с разных ресурсов одновременно и нужно избежать конфликтов. uuid тут явно неудобен. Создавать номер из времени сообщения и ID автора? Но от ID автора в текстовом виде хочется уйти. Например, в сторону e-mail автора.

2. Вопросы ограничений для пользователей. Например, те же временные R/O. Как вариант, конечно, отказаться от блокировок вообще и вводить только возможность игнора. Но тогда вылезет проблема спама.
 34.0.1847.11634.0.1847.116
RU Balancer #23.04.2014 01:36  @Balancer#23.04.2014 01:31
+
-
edit
 

Balancer

администратор
★★★★☆
Balancer> А в человекочитаемом виде можно будет оставить один файл — файл темы. Например, в формате mailbox...

А, собственно, какой там mailbox? Данные-то всё равно хранятся в JSON. Можно тупо каждый раз генерировать markdown для чтения текстом + сразу html для офлайнового чтения в браузере. Это будет совсем здорово для тех, кому понадобится работать с архивами, можно читать вообще не привязываясь к внешним ресурсам.
 34.0.1847.11634.0.1847.116
+
-
edit
 

Balancer

администратор
★★★★☆
Экспорт текстов сообщений за 2013 год выдал 1.3Гб данных. Более 300 тыс. файлов. Это без аттачей. git на таких объёмах тормозит сильно. Видимо, нужно резать по месяца. Один репозиторий = 1 месяц.

Проблема с авторством. Единственный универсальный способ иднтифицировать пользователя — его e-mail. Но проблема в том, что все данные репозитория будут публичными. А e-mail'ы многие светить не хотят. Наверное, всё же, придётся делать авторизацию с привязкой по хостам(проектам). Типа Balancer@Airbase.
 34.0.1847.11634.0.1847.116
RU spam_test #23.04.2014 09:22  @Balancer#23.04.2014 03:25
+
-
edit
 

spam_test

аксакал

Balancer> Проблема с авторством. Единственный универсальный способ иднтифицировать пользователя — его e-mail.
А если УЦ нарисуешь свой, и вход по ЭЦП?
 22
RU Balancer #23.04.2014 13:50  @spam_test#23.04.2014 09:22
+
-
edit
 

Balancer

администратор
★★★★☆
spam_test> А если УЦ нарисуешь свой, и вход по ЭЦП?

Система должна быть простой :) Плюс это будет такая же централизация, как и с обычной нынешней системой авторизации пользователей.
 3434
+
-
edit
 

Balancer

администратор
★★★★☆
И всё же хочется делать разбивки не только по датам, но и по проектам. Типа, зачем тащить всю политику тем, кто захочет работать только с судомодельным архивом.

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

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

...

Пока делаю экспортёр в такую файловую структуру:
+---Проект [категория первого уровня]
  |
  +---Категория [Военспец, Танцпол, Авиабаза]
    |
    +---Форум [без вложенности в случае подфорумов, всё на одном уровне]
      |
      +---Топик
        |
        +---posts [каталог с файлами сообщений]
        +---attaches [аттачи]
        +---index.html [файл для просмотра темы одним файлом]
        +---index.md [то же самое, но в виде текста]

Получается достаточно удобно для работы с ним в офлайне. Только, как писал раньше, резать придётся не по годам, а по месяцам, иначе слишком большие объёмы.

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

Balancer

администратор
★★★★☆
Обсуждение также на

Продолжение мыслей и экспериментов по распределённым форумам

Поскольку идея с распределёнными сайтами более-менее работает (Zim Wiki в DVCS и гейт-сайт для отображения, кеширования с целью поиска и т.п.), перешёл ко второй стадии, распределённым форумам. Задача намного сложнее, но и востребованнее. Если туп... // www.linux.org.ru
 
 3434
+
-
edit
 

Balancer

администратор
★★★★☆
Перенос файлов в git из репозитория в репозиторий:

Moving Files from one Git Repository to Another, Preserving History | Greg Bayer

If you use multiple git repositories, it’s only a matter of time until you’ll want to refactor some files from one project to another.  Today at Pulse we reached the point where it was time to split up a very large repository that was starting to be used for too many different sub-projects. After reading some suggested approaches, I spent more time than I would have liked fighting with Git to actually make it happen. In the hopes of helping someone else avoid the same trouble, here’s the solution that ended up working best. // Дальше — gbayer.com
 

Работа с ЭЦП в PHP:

php и электронно цифровая подпись (ЭЦП)

и с момента формирования ЭЦП и проверить принадлежность подписи владельцу сертификата ключа. X.509 – стандарт, определяющий форматы данных и процедуры распределения открытых ключей с помощью сертификатов с цифровыми подписями, которые предоставляются сертификационными органами (CA). PKCS#12 - стандарт семейства Public-Key Cryptography Standards(PKCS), определяет формат файла. .p12 - файл-контейнер стандарта PKCS#12, защита файла осуществляется симметричным ключем, основанном на пароле RSA - популярный криптографический алгоритм с открытым ключем используется для шифрования и ЭЦП (используется в PGP, SSL\TLS и т.д.) SHA-1 - алгоритм криптографического хеширования. Генерирует дайджест, 160-ти битное хеш значение. MD5 - алгоритм хеширования. Генерирует дайджест 128 бит. ГОСТ Р 34.11-94 - Российский криптографический стандарт вычисления хеш функции, размер хеша - 256 бит. ГОСТ Р 34.10-2001. "Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи" - стандарт, принятый в Российской Федерации. Разработан взамен ГОСТ Р 34.10-94. Используется для tls/ssl, в сертификатах открытых ключей и т.д. ГОСТ 34.310-2004.- тоже что и ГОСТ P 34.10-2001, только в РК При использовании ЭЦП подписывание производится закрытым ключем, а проверка - открым ключем. Сертификат открытого ключа - сертификат ключа проверки электронной подписи, позволяет проверить информацию подписанную закрытым ключем, идентифицировать владельца. Содержит информацию о владельце, а также об УЦ и области применения ключа. УЦ - удостоверяющий центр, открытый ключ которого известен всем участникам и его честность неоспорима. Основная задача - подтверждать подлинность ключей шифрования с помощью сертификатов ЭЦП. Грубо говоря УЦ подписывает ключи участников своим закрытым ключем. Отозванный сертификат - если участник рассекретил свой закрытый ключ, то УЦ отзывает его сертификат и другие участники узнают что этому ключу доверять нельзя. Самозаверенный сертификат - подписывается самим издателем, а не УЦ. Поэтому отозвать его невозможно. Не решает доверия к открытым ключам.   На Linux проще всего воспользоваться openssl, ставим: apt-get install openssl   <?php $link = fopen('rsa.p12', 'r'); $data = fread($file, filesize($link)); fclose($file); openssl_pkcs12_read($data, $container, '***'); //получаю X.509 сертификат из контейнера p12 $cert=$container['cert']; print_r($cert); file_put_contents('cert.pem', $cert); //получаю закрытый ключ $privatekey = openssl_get_privatekey($container['pkey']); print_r($privatekey); file_put_contents('priv.key', $privatekey); //получаю открытый ключ $pubkey = openssl_pkey_get_public($container['cert']); $keydata = openssl_pkey_get_details($pubkey); print_r($keydata); ... ?>   Формирование ЭЦП:   <?php ... $str='test'; //подписываю текст openssl_sign($str, $signature, $privkey); print_r($signature); //освобождаем память от закрытого ключа openssl_free_key($privkey); ... ?> Проверка ЭЦП: <?php .. //проверяю ЭЦП $ok = openssl_verify($str, $signature, $pubkey); if ($ok == 1) { echo "ЭЦП корректна :)"; } else { echo "ЭЦП не корректна!"; } //освобождаю память от открытого ключа openssl_free_key($pubkey); .. ?> // newblog.kz
 

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

Пока остаётся открытой проблема спама.
 3434
+
-
edit
 

Balancer

администратор
★★★★☆
Изменения в репутации и оценки пока тоже не ясно, как хранить. С одной стороны, они обычно привязаны к конкретным сообщениям, с другой — привязаны к пользователям. При чём в случае оценок они ещё и анонимные.
 34.0.1847.11634.0.1847.116
+
-
edit
 

Balancer

администратор
★★★★☆
Изначально планировал использовать формат «один постинг = один файл JSON».

Сейчас думаю, не надо ли переходить на формат «один топик = один файл JSON». Иначе больно много мелких файлов выходит. Для FS лишняя нагрузка.

С другой стороны, парсинг мелочёвки проще с точки зрения блокировок при модификации.

Интересно, а в природе нет чего-нибудь embedded, типа sqlite, но на plain-text? :)
 34.0.1847.11634.0.1847.116
+
+2
-
edit
 

Dmb_2007

опытный

Так вот ты какой, гипертекстовый фидонет :-)
 34.0.1847.11634.0.1847.116
RU Balancer #23.04.2014 23:11  @Dmb_2007#23.04.2014 23:09
+
-
edit
 

Balancer

администратор
★★★★☆
Dmb_2007> Так вот ты какой, гипертекстовый фидонет :-)

Да, что-то общее отчасти просматривается в идее :) Кстати, если припрёт, в рамках этой системы можно будет обмениваться обновлениями при отсутствии онлайна, на «флешконете» :)
 34.0.1847.11634.0.1847.116
+
-
edit
 

Balancer

администратор
★★★★☆
Поиграл с git и mercurial на месячном срезе форумов. В принципе, почти идентично. Так что, хоть мне нравится mercurial, буду делать ставку на git — он более распространён, проще будет и с хостингами, и с поддержкой.
 34.0.1847.11634.0.1847.116
+
-
edit
 

Balancer

администратор
★★★★☆
Решил сохранять в JSON постингов и приватную информацию проекта, например — IP постера (чтобы можно было спокойно восстановить полную структуру БД из одного только репозитория). Ясно, что надо её шифровать. Пробую шифровать открытым ключом с последующей, если потребуется, расшифровкой закрытым. При длинном ключе получается длинная же итоговая строка. Большую часть записи занимает приватные данные, хотя там записано только несколько байт IP. Значит, надо ключ брать покороче, тем более, что данные там хранятся не настолько приватные, чтобы ломать голову — это скорее моральных соображений вопрос.

Минимальная длина ключа для sha256 — 384 бита. Получается минимальная строка в 64 символа. Достаточно ли этого для поверхностной защиты?
 34.0.1847.11634.0.1847.116
+
-
edit
 

Balancer

администратор
★★★★☆
Добавил в репозиторий аттачи. Вышло сразу по 3+Гб за месяц (декабрь 2013 на тесте). При чём 2.2Гб из них — Морской :) Ещё 580Мб — Ракетомодельный. Дальше уже по мелочи (84Мб Политика, 72Мб Наука и техника и т.д.)

Январь 2014:
Всего — 2.8Гб, Флот — 1.9Гб, Ракетомодельный — 594Мб, Политика — 160Мб.

Ракетомоделисты-то у нас активные, оказывается, по объёму вторыми за моряками идут :)
 34.0.1847.11634.0.1847.116
+
-
edit
 

zaitcev

опытный

Balancer> Сейчас думаю, не надо ли переходить на формат «один топик = один файл JSON». Иначе больно много мелких файлов выходит. Для FS лишняя нагрузка.
Можно и любую другую структуру контейнера, хоть PKZIP, хоть Tokyo Cabinet. С JSON-ом что бы будешь делать когда топик перестанет лезть в память (ну понятно не сам по себе). В общем не вижу смысла отказываться от случайного или последовательного доступа к сообщениям в топике.
 18.0.1025.13318.0.1025.133
LT Bredonosec #24.04.2014 02:35  @Balancer#24.04.2014 00:47
+
-
edit
 

Bredonosec

аксакал
★★★☆

Balancer> Минимальная длина ключа для sha256 — 384 бита. Получается минимальная строка в 64 символа. Достаточно ли этого для поверхностной защиты?
а можно-ли обойтись без свечения персональных данных? Напр, если охота давать репозитори й всем публично, то почему б юзера не отметить неким айди, соответствующим ему, а привязка айди к мылу и прочей персональной инфе - в отдельной базе, которая не-публична?
Насчет ипов - мож тоже просто подменить их на некий номер, никак не связанный с самим значением ИП-а, а, напр, с очередностью появления в данном репозитории (а соответствующее ему значение ИП-а пусть опять же остается в не-публичной базе).
Или это метод менее защищен, нежели банально шифрование самих цифр? Что оно будет короче в записи - так точно... Единственно, что при машинном анализе станет видно, какие юзера писали с тех же ИП. Но эта инфа и так публична вроде..
 26.026.0
+
-
edit
 

Balancer

администратор
★★★★☆
zaitcev> Можно и любую другую структуру контейнера, хоть PKZIP, хоть Tokyo Cabinet.

Нет, основные данные в plain text — это обязательное условие. А то бы я тупо в sqlite базу всё запихнул :) Нужно эффективно версионность отслеживать и уметь вручную отследить что нужно.

zaitcev> С JSON-ом что бы будешь делать когда топик перестанет лезть в память (ну понятно не сам по себе)

Потому пока и остановился, всё же, на варианте «одно сообщение = один JSON-файл»

zaitcev> В общем не вижу смысла отказываться от случайного или последовательного доступа к сообщениям в топике.

Напомню ещё, что Web-гейт, показывающий страницу топика, не будет лезть напрямую в репозиторий. Он по-прежнему будет брать данные из БД. Репозиторий — это средство основного хранения, версионности и синхронизации/репликации. БД будет выступать фактически в роли кеша.
 34.0.1847.11634.0.1847.116
RU Balancer #24.04.2014 02:44  @Bredonosec#24.04.2014 02:35
+
-
edit
 

Balancer

администратор
★★★★☆
Bredonosec> а можно-ли обойтись без свечения персональных данных?

Так я потому этот вопрос и поднял :)

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

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

E-mail будет публиковаться только у тех, кто сознательно укажет его для прямой обратной связи. В противном случае связь будет осуществляться через сайт, на котором зарегистрирован пользователь.

То есть пользовательская информация будет храниться в основном на сайте.

Тут же речь об информации, привязанной не к пользователю, а к сообщению. Её бы и полезно было хранить с ним, чтобы не размножать сущности. Соответственно, приватную информацию предполагается хранить в зашифрованном виде. Ключ на расшифровку будет только на гейте — источнике сообщения.

Bredonosec> Насчет ипов - мож тоже просто подменить их на некий номер, никак не связанный с самим значением ИП-а

Это ничем не лучше варианта с шифрацией :) Конечно, будет чуть короче, но потребует лишней сущности — карты соответствий IP и номеров.

Bredonosec> Единственно, что при машинном анализе станет видно, какие юзера писали с тех же ИП. Но эта инфа и так публична вроде..

Да, это итак публичная информация.
 34.0.1847.11634.0.1847.116
+
-
edit
 

Balancer

администратор
★★★★☆
В копилку.

Аутентификация на базе ЭЦП

Уже в нескольких топиках рассматривались проблемы построения безопасного механизма аутентификации при небезопасном соединении. Ниже предлагается к обсуждению... // habrahabr.ru
 

PHP: gnupg_encrypt - Manual

(PECL gnupg >= 0.1) gnupg_encrypt — Encrypts a given text Encrypts the given plaintext with the keys, which were set with gnupg_addencryptkey before and returns the encrypted text. Идентификатор gnupg, полученный из gnupg_init() или gnupg. The text being encrypted. On success, this function returns the encrypted text. On failure, this function returns FALSE. Пример #1 Procedural gnupg_encrypt() example Пример #2 OO gnupg_encrypt() example // www.php.net
 
 3434
LT Bredonosec #24.04.2014 18:41  @Balancer#24.04.2014 02:44
+
-
edit
 

Bredonosec

аксакал
★★★☆

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

да, кстати, где-то ты упоминал, что закрытый исчезнет - почему? Разве плохая идея?
и еще один вопрос - а почему обсуждение открытое, здесь, а не там, если мотив состоит в критичности безопасности?
 26.026.0
RU Balancer #25.04.2014 12:38  @Bredonosec#24.04.2014 18:41
+
+1
-
edit
 

Balancer

администратор
★★★★☆
Bredonosec> да, кстати, где-то ты упоминал, что закрытый исчезнет - почему? Разве плохая идея?

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

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

Bredonosec> и еще один вопрос - а почему обсуждение открытое, здесь, а не там, если мотив состоит в критичности безопасности?

Потому что безопасность открытой системы тоже должна обсуждаться открыто :) Иначе гораздо больше шансов что-то зевнуть.
 3434
RU Алдан-3 #26.04.2014 04:20  @Balancer#25.04.2014 12:38
+
-
edit
 

Алдан-3

аксакал
★★
Balancer> Потому что безопасность открытой системы тоже должна обсуждаться открыто

Публичное и открытое обсуждение ковбоями Дикого Запада Интернета борьбы с наступлением государственной машины на привычный образ жизни. Оживлённая дискуссия о правильной фортификации, обустройстве огневых позиций и маскировке ДОТов под мирные ковбойские хаты. Ещё голосования (тоже публичного) не хватает, где устроить склад боеприпасов :facepalm:
Особенно его раздражало то, что его постоянно спрашивали, чем он так раздражен.  28.028.0
RU Balancer #26.04.2014 11:37  @Алдан-3#26.04.2014 04:20
+
-
edit
 

Balancer

администратор
★★★★☆
«Митьки никого не хотят победить» ©
 3434
1 2 3

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru