Мысли вслух по поводу распределённой социальной системы

 
1 2 3
+
-
edit
 

Balancer

администратор
★★★★★
Забавно, что пару лет назад, когда меня интересовал промежуточный слой XML для хранения логики BB-code разметки перед конвертацией в HTML (linux.org.ru) никто не предложил DocBook XML. Похоже, это то, что нужно. И позволит унифицировано задействовать разметки в других форматах, хоть Markdown, хоть AsciiDoc. Надо будет попробовать задействовать на практике на форуме. Лишняя сущность, но упростит обработку и расширение.

А в свете сабжа — есть такая проблема. Хочется, чтобы ноды могли использовать документы в разной исходной разметке. Кому-то нравится Markdown, кому-то — Creole. Где-то, как у нас, всё делается на BBCode. Соответственно нужно было выбирать:
— либо все ноды должны поддерживать все стандартные форматы
— либо нестандартные для данной ноды документы показываются как есть, исходниками
— либо обмениваться готовым HTML, намертво прибиваясь к разметке

Теперь, вроде, есть неплохая альтернатива. К исходнику можно просто прикладывать DocBook XML.
 43.0.2357.12443.0.2357.124
+
-
edit
 

Balancer

администратор
★★★★★
Переход к практической части.

Так и не подобрал адекватной системы прямого обмена данными в каталогах. Вот старая версия BTSync была бы неплоха. Но её убили. Syncthing требует ручного связывания обменников. IPFS не расшаривает каталоги. И т.п.

Поскольку, по большому счёту, я изначально задумывал не привязываться к транспорту, лишь бы был обмен данными, решил пока базироваться на первоначальной идеи использовать Git. Только чтобы не мусорить аттачами на GitHub, поднял Gogs у себя на HBR. И засинкаю ещё на HTZ позже.

Благо, я отказался от идеи какой-то строгой структуры хранения документов, базируясь исключительно на UUID-логике.

Т.е. обмен данными будет работать по принципу:
1. Написали сообщение на форум
2. Система коммитит сообщение в репозиторий
3. Репозиторий дёргает за хуки всех, кто тянет с него данные (или это делается при периодических опросах, если самостоятельное подключение)
4. Дёрнутые ноды скачивают изменение и регистрируют изменённые документы у себя

...

Попробую теперь прикрутить экспорт данных (пункт 2) к практическому репозиторию. Простой коммит сделать совсем несложно. Сложнее делать это с учётом аттачей и редактирования.
 43.0.2357.13043.0.2357.130
+
-
edit
 

Balancer

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

cpliakas/git-wrapper

git-wrapper - A PHP wrapper around the Git command line utility. // github.com
 
 43.0.2357.13043.0.2357.130
+
-
edit
 

Balancer

администратор
★★★★★
Сделал ряд упрощений, благодаря которым уже начинаю отрабатывать взаимодействие узлов. Даже не столько упрощений, сколько отвязок от конкретных решений в одних местах и привязок в других. Для начала — отказался от идеи большого централизованного git-репозитория. Идеология разбивки на репозитории по объёму очень усложняла задачу.

Сейчас есть просто поток постингов (вообще — любых объектов, но отрабатываю на форумах) в YAML-Markdown формате, которые могут получать все желающие подписчики по любому доступному транспорту. Я, например, сейчас тупо раздаю их по BTSync. Думаю задействовать также MQTT. Но, вообще, протокол обмена может быть абсолютно любой — rsync, blockchain и т.п.

На одной ноде пишется пост на форуме, он передаётся нодам-приёмникам, тем парсят и заталкивают в свои форумы.

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

— Каждый пользователь, кроме ссылки на профиль ноды, подписывается по md5 от e-mail. Это скрывает e-mail от публичной раздачи, позволяет связывать пользователей, пишущих на разных нодах и выдавать общий аватар через Gravatar на прочих нодах.

— Есть идея сделать UUID файла сообщения по формуле f2fs-хеша. Что позволит вытаскивать сообщения через f2fs с любой ноды, не обязательно привязанной прямо. Плюс автоматически избегаем дублирования сообщений при перекрёстных обменах.

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

— Файловый обмен (аттачи и т.п.) идёт (будет идти) по f2fs.

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

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

— Конкретные топики, форумы или авторы могут на приёмной ноде блокироваться.
 33
+
-
edit
 

Balancer

администратор
★★★★★
— Думаю для начала делать привязки для движков MyBB (как самый для меня полноценный) и FluxBB (интересен тем, что разработка базируется на composer-зависимостях).

— Вначале планирую открыть пару тестовых «альтернативных» форумов Авиабазы (со своими правилами), отработать двухстороннее взаимодействие с ними и односторонний приём информации с конференции АвиаПорт.Ru и попробовать добывать данные для одностороннего же постинга парсингом других форумов, например, linux.org.ru
 33
+
-
edit
 

Balancer

администратор
★★★★★
— В качестве контента передаваться будет исходный код, введённый пользователем, без разметки. Возможно (не уверен в правильности и нужности) также передаваться будет и HTML, транслированный сервером. Возможно, отдельным вполне автономным файлом в f2fs.
 33
+
-
edit
 

Balancer

администратор
★★★★★
Наверное, извлечение данных топиков и форумов можно реализовать тоже через асинхронный файловый обмен.

Сценарий примерно такой.

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

Аналогично может решаться вопрос с форумами и юзерами.

Также нода-источник может закидывать в поток инфо об обновлении топиков (создание, переименование и т.п.). Если при каждом ответе размещать также список постингов в топике, то вопрос привязки на приёмниках решается без дополнительных запросов, но возникает вопрос, требуется ли такая повышенная активность в p2p-файловом обмене.
 33
+
-
edit
 

Balancer

администратор
★★★★★
При доработках имеющихся движков в таблицы, отвечающие за хранение постингов, топиков, форумов, категорий и юзеров (а также блогов, комментариев, статей и т.п.) нужно добавить поле:
  • UUID объекта (формат не утверждён, сейчас — произвольная строка latin1 до 64 символов)

Нужно подумать также о хешах объектов в p2p-ФС. Пока в разработке участвует только ipfs, соответственно, поле с хешем можно добавить в те же таблицы. Но если для надёжности будет использоваться несколько ФС?
 33

+
-
edit
 

Balancer

администратор
★★★★★
FluxBB не понравился из-за нерасширяемости. Т.е. гнать тупо текст — можно и сейчас (что и делается на тестовом). А вот что-то серьёзнее, хотя бы разметку нормальную организовать и граватары включить — нужно жёстко патчить ручками. А окончательно меня от него оттолкнуло отсутствие аттачей. Как их трансляцию туда делать? :) В общем тот же PunBB...

...

С другой стороны — всё равно обмен аттачами думаю делать через ipfs, так что передачу их в fluxbb не вопрос организовать на этапе импорта им сообщений. Так что, наверное, допилю движок импорта. Сам, правда, пользоваться не буду :)

...

Вот для phpBB, при всей моей к нему ненависти (внутренняя структура данных ужасная), наверное, адаптер придётся писать. Один из присоединяемых к системе сторонних форумов — на этом движке.

Ещё нужны будут адаптеры под LiveStreet и Wordpress. Это для категорий статей.

Ну и попробую организовать R/O трансляторы с LOR и Opennet :)
 33
RU Полл #18.12.2015 12:41  @Balancer#18.12.2015 12:07
+
-
edit
 

Полл

литератор
★★★★☆

Balancer>

Тип данных Post


Balancer> Служит для передачи классических форумных сообщений при неопределённом подтипе (они могут быть «комментарий», «новость» и т.п.). Не знаем точный тип — шлём Post.
Если разбирать этот тип сообщений будут сами ноды, то это заложен концептуальный вечный бег эксплоитов и апдейтов систем.

Balancer> UUID — уникальный идентификатор сообщения. Должен быть один во всей системе. Назначается нодой-первоисточником и сохраняется при всех дальнейших передачах. Может быть произвольного строкового формата с латинскими алфавитно-цифровыми и пунктуационными символами. Но в общем, рекомендуется включать в себя идентификатор первичной ноды. Скажем, сообщения с форумов Авиабазы идентифицируются в Java-стиле как ru.balancer.board.post.NNNNNN.
Как будет обеспечиваться уникальность данного идентификатора?
Как должна поступать система, если встречаются два разных сообщения с одним идентификатором - а в распределенной системе коллизии возможны всегда даже при отсутствии злого умысла?

Balancer> Node — уникальный идентификатор ноды-первоисточника. Аналогично UUID. На Авиабазе — ru.balancer.board
Не понял, какой смысл это поле несет.

Balancer> Author — имя автора. Поле будет пересматриваться в пользу массива с расширенными параметрами. Произвольная строка.
Balancer> AuthorEmailMD5 — MD5-хеш E-mail автора. Служит для идентификации авторов между нодами. Дополнительно может служить для извлечения граватара.
Кто помешает злоумышленнику подставить чужое имя?

Balancer> AuthorUUID — уникальный идентификатор автора сообщения на первичной ноде. ru.balancer.board.user.NNNNN
Опять же не понял смысл этого поля.

Balancer> Date — дата создания сообщения в формате rfc2822 или ином, понимаемом преобразованием strtotime.
Balancer> Modify — дата последнего изменения сообщения в том же формате.
По чьей версии времени?

Balancer> Что планируется:
ЭЦП для сообщений планируется?
 42.042.0
RU Balancer #18.12.2015 13:07  @Полл#18.12.2015 12:41
+
-
edit
 

Balancer

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

Уточни. Кто-то из нас друг друга недопонимает :)

Полл> Как будет обеспечиваться уникальность данного идентификатора?

Я вижу два основных подхода (могут использоваться одновременно):

— Использование связки «имя ноды» + «тип данных» + «уникальный идентификатор данных», которую использую сейчас. Тут имя ноды целиком на добросовестности ноды-источника, но подразумевается, что мы итак тянем данные не от кого попало, а от доверенной ноды. И система с использованием реверсной доменной структуры прекрасно и массово работает по всему миру в пространствах имён в Java-библиотеках (я, собственно, оттуда вид своих UUID и взял).

— Кому лениво заморачиваться или у кого нет выраженной ноды, могут использовать те же стандартные «настоящие» UUID: UUID — Википедия

Полл> Как должна поступать система, если встречаются два разных сообщения с одним идентификатором

То, которое будет получено первым, будет записано в базу. Второе с таким же ID будет игнорироваться, если система не учитывает дату модификации или будет перезаписано вторым, если его дата модификации будет свежее.

Полл> а в распределенной системе коллизии возможны всегда даже при отсутствии злого умысла?

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

Полл> Не понял, какой смысл это поле несет.

Чтобы понять, если UUID не содержит имя ноды, откуда пришло сообщение. Например, если потребуется запросить дополнительную информацию по объекту, чтобы знать, куда обращаться.

Полл> Кто помешает злоумышленнику подставить чужое имя?

Отсутствие злоумышленника в доверенной системе :)

Полл> Опять же не понял смысл этого поля.

Автор может писать с разных нод. В этом случае MD5(email) будет идентификатором автора, но не может служить идентификатором автора и ноды. Например, если нам потребуется запросить по автору с ноды дополнительную информацию.

Полл> По чьей версии времени?

Если речь о таймзоне, то она включена в формат даты. Если речь о расхождении часов — то по времени ноды первоисточника.

Полл> ЭЦП для сообщений планируется?

Да, есть такая мысль. Это заодно позволит в каких-то случаях работать и открыто, с недоверенными транзитными нодами. Но это дальняя перспектива.
 33
RU Полл #18.12.2015 17:40  @Balancer#18.12.2015 13:07
+
-
edit
 

Полл

литератор
★★★★☆

Balancer> Отсутствие злоумышленника в доверенной системе :)
Ты делаешь систему для себя и своего кота?
Или я уже многое пропустил, и лев уже возлежит с агнцем?

Balancer> Автор может писать с разных нод. В этом случае MD5(email) будет идентификатором автора, но не может служить идентификатором автора и ноды. Например, если нам потребуется запросить по автору с ноды дополнительную информацию.
У нас есть идентификатор ноды-источника, у нас есть глобальный идентификатор автора. Зачем нужен идентификатор автора на ноде-источнике?

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

Balancer> Да, есть такая мысль. Это заодно позволит в каких-то случаях работать и открыто, с недоверенными транзитными нодами. Но это дальняя перспектива.
Я бы сказал, что это граница начала практической применимости данной системы.
 42.042.0
RU Balancer #18.12.2015 19:22  @Полл#18.12.2015 17:40
+
-
edit
 

Balancer

администратор
★★★★★
Полл> Ты делаешь систему для себя и своего кота?

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

Полл> У нас есть идентификатор ноды-источника, у нас есть глобальный идентификатор автора. Зачем нужен идентификатор автора на ноде-источнике?

Потому что у ноды-источника в общем случае автор может быть не ассоциирован с глобальным MD5-ID. Или у одного глобального MD5-ID может быть несколько аккаунтов.

Полл> То есть злоумышленник может вставить в поддельное сообщение дату последнего редактирования из 40 000 г н.э. и быть спокойным, что никто его сообщение изменить не сможет?

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

Полл> Я бы сказал, что это граница начала практической применимости данной системы.

У нас с тобой, видимо, не только очень различное восприятие реалий, но и задачи разные :)
 33

RU Полл #19.12.2015 11:01  @Balancer#18.12.2015 19:22
+
-
edit
 

Полл

литератор
★★★★☆

Balancer> Нет, но очевидно, что в общем случае нельзя принимать импорт с совершенно недоверенных нод в принципе.
Побуду Йодой.
Дисгармонию здесь чую я - доверенные и проверяемые элементы системы это ноды, но авторы данных это люди. К нодам не привязанные - иначе бы не был нужен "глобальный идентификатор" пользователя. Но при этом ответственность за действия пользователей вешается на ноды.
А что ноды за это получат?
 42.042.0
RU Balancer #19.12.2015 11:52  @Полл#19.12.2015 11:01
+
-
edit
 

Balancer

администратор
★★★★★
Полл> Дисгармонию здесь чую я - доверенные и проверяемые элементы системы это ноды, но авторы данных это люди. К нодам не привязанные

А это ничем не отличается от обычной регистрации нового пользователя сейчас. Пользователь регистрируется «ничем не проверяемый». Мы знаем только e-mail и некие ничего не значащие параметры, типа ника и аватара. Точно также, как на нового обычного регистранта, каждая нода будет реагировать и на нового реплицированного юзера. Если его EmailMD5 уже есть в базе, то это уже известный нам юзер и мы знаем, как себя с ним вести. Например, не принимать сообщения, если он забанен или сваливать в какой-нибудь «Заповедник гоблинов». Если это новый пользователь — ведём себя с ним (в смысле с его сообщениями) как с новичком-регистрантом. Так что никаких новых проблем тут не возникает.

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

Использовать ли эту информацию и как — зависит уже от отношения конкретных нод между собой.
 33

Unix

опытный

Полл>> То есть злоумышленник может вставить в поддельное сообщение дату последнего редактирования из 40 000 г н.э. и быть спокойным, что никто его сообщение изменить не сможет?
Balancer> Вопрос доверия ноды. В случае дискредитации все сообщения ноды могут быть тупо удалены.
Полл>> Я бы сказал, что это граница начала практической применимости данной системы.
Balancer> У нас с тобой, видимо, не только очень различное восприятие реалий, но и задачи разные :)


Зря ты Balancer хочешь пройти по всем граблям SMTP, ой зря! Умный же на чужих ошибках учится или где? :(

Что мне не нравится? Чучело устроит MITM, а с твоей схемой - это весьма возможно, и чучело может завалить все ноды картинками с проном и предложениями удлинить ... метода вон сверху, описана Поллом.
Да, а потом вообще кЫно начнётся! Ты ведь выкинешь "плохие" ноды :) В общем - медный таз твоей сети! :(

Как по мне надо так: каждая нода публикует свой открытый ключ. А при постинге поста (и маслинге масла :) ) - подписывает его. Ну будет у тебя синк не через 2 секунды, а через 20, зато Ъ!!!

В общем - как то так... ©
 

Balancer

администратор
★★★★★
Unix> Зря ты Balancer хочешь пройти по всем граблям SMTP, ой зря! Умный же на чужих ошибках учится или где? :(

SMTP — это федеративная система. Вообще не то :)

Unix> Чучело устроит MITM, а с твоей схемой - это весьма возможно, и чучело может завалить все ноды картинками с проном

«Открытые» ноды — да. На «Закрытые» оно вообще не попадёт. На «умеренно модерирумых», типа наших форумов Авиабазы, появление такого чучела ничем не будет отличаться от его обычной регистрации. Таки, да, у нас никто проном форум не заваливает почему-то, с чего ты считаешь, что в случае такой системы будет иначе? Модераторы на что?

Unix> Как по мне надо так: каждая нода публикует свой открытый ключ. А при постинге поста (и маслинге масла :) ) - подписывает его. Ну будет у тебя синк не через 2 секунды, а через 20, зато Ъ!!!

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

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

Unix

опытный

Unix>> Зря ты Balancer хочешь пройти по всем граблям SMTP, ой зря!
Balancer> SMTP — это федеративная система. Вообще не то :)
То есть ты "зарытую" систему строишь? (в смысле интернет vs ФИДО) ... дай тогда подумаю.

Balancer> Нельзя подсунуть данные, прикинувшись чужой нодой.
Почему? Ну давай тупо, по детски, я отравил твой днс-кэш и ты вместо реального танзпол.ру придёшь ко мне ... я вывалю посты с ID дублирующими реальные, но со временем обновления свежее. Всё - твои юзеры видят пиписки вместо корабликов :) А ты ещё и зареплицируешь это на другие ноды...

Распиши механизм защиты, торможу я, не вижу как ты от этого защитишься, извиняюсь за тупизм заранее :)
 

Balancer

администратор
★★★★★
Unix> То есть ты "зарытую" систему строишь? (в смысле интернет vs ФИДО)

Да, на первом этапе примерно так.

Unix> Почему? Ну давай тупо, по детски, я отравил твой днс-кэш

Зачем тогда так сложно, когда можно просто взломать ноду? :) Тут и шифрование с подписями не спасут.
 33
RU спокойный тип #21.12.2015 10:19  @Balancer#21.12.2015 08:57
+
-
edit
 

спокойный тип
Спокойный_Тип

старожил
★☆
Unix>> То есть ты "зарытую" систему строишь? (в смысле интернет vs ФИДО)
Balancer> Да, на первом этапе примерно так.
Unix>> Почему? Ну давай тупо, по детски, я отравил твой днс-кэш
Balancer> Зачем тогда так сложно, когда можно просто взломать ноду? :) Тут и шифрование с подписями не спасут.

взломать ноду - да, против этого только двухфакторная аутентификация может помочь :D

а от всего остального - если ноды имеют валидные SSL сертификаты (не самоподписанные) - то это уже защита...скомпромитированные DNS (да и любого другого мэн-инда-миддл) мы увидим
 43.043.0
RU Balancer #21.12.2015 12:42  @спокойный тип#21.12.2015 10:19
+
-
edit
 

Balancer

администратор
★★★★★
с.т.> скомпромитированные DNS (да и любого другого мэн-инда-миддл) мы увидим

В нынешнем варианте обмена данными DNS вообще не используется ни в каком виде :)
 33
+
-
edit
 

Balancer

администратор
★★★★★
Обширная информация к размышлению:

Интернет на магнитах 1 — Магнит

Итак, приходит время когда p2p сети завоёвывают всё большее интернет-пространство, но окончательная победа придет только тогда, когда они станут невидимы для... // habrahabr.ru
 

Интернет на магнитах 2 — Гипертекст

Пора дать волю гипертексту и расширить возможности его распространения не только классическим клиент-серверным способом, но и в одноранговых сетях. Для того,... // habrahabr.ru
 

Интернет на магнитах 3 — P2P Сайт и Форум

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

Идеи «векторного гипертекстового фидонета» прямо таки витают в воздухе :)
 33
+
-
edit
 

Balancer

администратор
★★★★★
Интересный побочный эффект от такой системы.

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

Теперь можно будет пробовать тупо прилепить адаптер импорта данных распределённой системы и получить «живую» систему. Сразу будет видно, насколько она удобна, насколько качественная архитектура. И можно в таком автоматически пополняемом виде оставить, периодически щупая на тему удобства использования с практическими данными (которые будут экспортироваться обратно в распределённую систему).

Наверное, для старта попробую Anahita:

Anahita - Open source social networking framework and platform

an open source social networking framework and platform for building knowledge sharing apps and services // www.getanahita.com
 

Anahita - Open source social networking platform and framework

a remarkable open source platform for building knowledge sharing apps and services // anahita.works.home.balancer.ru
 

Пока поднял без импорта распределённых данных, позже попробую написать адаптер.

Также нужно будет рассмотреть:
 33
+
-
edit
 

Balancer

администратор
★★★★★
Вот с чем пока концептуальные проблемы обмена — это с CMS/Wiki. Как правило, там активно используется большое число внутренних ссылок, часто привязанных к архитектуре приложения. Надо решать вопросы с их конверсией.

...

Кстати, другая проблема — внешние ссылки вообще. Если ведётся разработка «неуничтожимой» (с долго, по крайней мере, хранящимися данными), важно сохранять и страницы, на которые мы публикуем ссылки. Иначе через 5 лет от них в доступе остаётся половина, через 10 лет — единицы. Надо утягивать и сохранять страницы целиком. И тут — проблема. Прижившихся однофайловых форматов, которые можно загружать куда-то в p2p-хранилища и потом открывать в браузере — нет. Хранить архивы можно, но мало смысла — их нельзя открыть в браузере. Разбирать страницы и выкладывать контент в p2p-хранилище по частям с заменой вызовов на p2p? — работоспособное решение, но только отчасти (например, в ipfs нельзя выложить CSS и показать его как работоспособный CSS). И громоздкое очень.
 33
+
-
edit
 

Balancer

администратор
★★★★★
В копилку, надо будет оценить:

oneall/social-login-vanilla-forum

social-login-vanilla-forum - Social Login for Vanilla Forum allows your users to login and register with 25+ social networks. It increases your Vanilla user registration rate by simplifying the reg... // github.com
 

Можно будет гостей отправлять на гейт с этим движком. Хотя не так удобно, как если бы сразу при ответе аутентифицироваться, но лучше, чем ничего. И список сетей солидный.
 
1 2 3

в начало страницы | новое
 
Поиск
Поддержка
Поддержи форум!
ЯндексЯндекс. ДеньгиХочу такую же кнопку
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru