nedoPC.org

Децентрализованное ответвление от темы Виртбурга (который был виртуальным миром с центральным сервером):
http://www.nedopc.org/forum/viewtopic.php?f=81&t=9043
http://www.nedopc.org/forum/viewtopic.php?f=81&t=10939
P.S. Линки для ознакомления на тему Peer-2-Peer MMO:
https://en.wikipedia.org/wiki/Massively_multiplayer_online_game (под спойлером линк на русскую вики-страничку)
https://en.wikipedia.org/wiki/Vindictus
[17] https://www.theage.com.au/technology/yoicks-its-another-virtual-world-20070227-gdpk0o.html
[18] http://vast.sourceforge.net/relatedwork.php
Классификация из последнего линка:
AOI = area of interest
DHT = distributed hash table
https://en.wikipedia.org/wiki/Distributed_hash_table

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

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

Что-то мне это чем-то напомнило популярную ныне (как пишут) игрушку «Годвилль» -
«прямого потомка Progress Quest».
Там вроде как тоже у каждого игрока - свой индивидуальный мирок...
Сам я, конечно, не играл, но уж больно часто встречал упоминания в Интернете...

Ну свой индивидуальный мирок это не виртуальные миры - это просто локальная игра на одного - для виртуальных миров надо видеть друг друга и быть как бы одновременно в одном секторе...

Предположим, что главный сервер выдаёт идентификатор виртуальной реальности для каждого дня (скажем на три дня вперёд) и эти идентификаторы распространяются по узлам вместе со списком хешей файлов (возможно списки запрещённых хешей запрещённых или устаревших файлов тоже дожны распостраняться тем же путём). Когда юзер включает клиента, то клиент может поискать узлы в локальной сети, чтобы спросить у них сегодняшний идентификатор виртуальной реальности либо может пойти на главный сервер и качнуть манифест оттуда (возможно клиент будет помнить IP-адреса других узлов, с которыми он общался до этого, и может поспрашивать у них). Соответственно алгоритм включения такой:
1) поискать узлы в локальной сети делая широковещательный UDP запрос по известному порту, используя последний известный идентификатор виртуальной реальности;
2) если никто не ответил, то выбрать случайные адреса из списка IP-адресов, с которыми общался этот узел в предыдущие разы - набрать 3 ответивших и спросить у них обновления, используя известный идентификатор виртуальной реальности (устаревший);
3) если не удалось найти живых узлов за определённое количество попыток, то идём на главный сервер по HTTP (тоже самое делаем, если не удалось получить непротиворечивую информацию от ответивших узлов).
Ничего не мешает кому-то взять инициативу в свои руки, если главный сервер вдруг умрёт - надо просто убедить людей идти в альтернативную виртуальную реальность с другим идентификатором
P.S. "Официальный" сервер должен предоставлять списки "одобренных" файлов с их хэшами, чтобы исключить возможность такой ситуации, что какой-то узел вдруг подменит все текстуры на всякие непотребства
P.P.S. Можно задействовать новые быстрые алгоритмы цифровой подписи как http://ed25519.cr.yp.to/index.html (Public Domain) или даже "Post-Quantum Cryptography" (который нельзя взломать на квантовом компьютере, по крайней мере теоретически) https://falcon-sign.info/ (MIT License).

Ну да - если почитать тему с архивами переписки по Виртбургу, то можно увидеть, что Диптаун там вылезал достаточно часто

http://www.nedopc.org/forum/viewtopic.php?f=81&t=10939

убрал под спойлер

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

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

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

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

P.S. Когда добавится финансовая система, то там по аналогии с блокчейном можно хранить все транзакции (в распределённом хранилище).

Оказывается уже есть децентрализованный виртуальный мир на блокчейне - Decentraland (запущен в сентябре 2019):
https://decentraland.org/
https://market.decentraland.org/
https://twitter.com/decentraland
и местами напоминает Виртбург (просто пройдитесь по видеороликам в ихнем твиттере)!
Правда там всё-таки многое делается на главном сайте (типа выбор аватара, покупки-продажи ассетов и постройки зданий), плюс своя криптовалюта замешана...
P.S. Некоторым этот момент сильно не понравился:
https://ryanschultz.com/2020/02/20/a-step-by-step-guide-on-how-to-get-started-in-decentraland-and-some-caveats-for-new-users/
P.P.S. Этот же блог утверждает, что таких проектов 4 (и практически все построены на основе Ethereum):
https://somniumspace.com/
http://www.cryptovoxels.com/
https://www.sandbox.game/en/
Интересно что все 4 представляют примерно тот же самый набор активностей - marketplace, builder и т.д.
(похоже зря я Виртбург прибил в 2010 - теперь придётся догонять паровоз)
P.P.P.S. Полный список виртуальных миров (не только блокчейновых) от тогоже блоггера:
https://ryanschultz.com/list-of-social-vr-virtual-worlds/
И ещё некоторые определения и понятия от него же:
https://ryanschultz.com/definitions-of-terms-used-in-this-blog/

(c) Всё уже украдено до нас...

Читал про разные алгоритмы распределённых хешей - много думал...

Наверное надо заводить свои собственные определения в рамках этой концепции, итак:

Realm - отдельная вселенная, куда помещается игрок (например "Virtburg Realm") - все файлы разрешённые в этой вселенной подписываются секретным ключом от Realm-а (и каждый узел Realm-а получает открытый ключ для проверки подписей);
Reality - виртуальная реальность в пределах Realm-a (причём реальностей может быть много и разные реальности могут переиспользовать одни и теже файлы);
Signature - цифровая подпись, подтверждающая принадлежность файла к тому или иному Realm-у (либо подтверждающая авторство сообщения), может также служить для идентификации (файла или сообщения);
Asset - файл имеющий цифровую подпись (Signature), по которой его можно найти в распределённой среде;
User - игрок, помещённый в тот или иной Realm и подключенный к той или иной реальности (Reality) - каждый User имеет свой секретный ключ, которым подписывает свои сообщения (также User передаёт свой открытый ключ всем, с кем хочет общаться);
Node - узел сети, которым может владеть User, идентифицируется его открытым ключом (узел может быть частью одного или нескольких Realm-ов);
Supernode - специализированный узел сети, которым владеет администрация Realm-a (этот узел знает закрытый ключ Realm-a и может подписывать файлы, а также умеет авторизовывать игроков);
Message - сообщения, посылаемые игроками и системой (сообщения имеют время жизни в секундах и если оно 0, то сообщение считается "вечным" и остаётся в истории);
Subject - тема, на которую может подписаться User для получения и отправки сообщений (например при заходе в сектор надо подписаться на получение сообщений из этого сектора).

P.S. Может эту концепцию так и назвать - "Realm"?

Официально оно оказывается называется EdDSA (см. https://en.wikipedia.org/wiki/EdDSA и https://ru.wikipedia.org/wiki/EdDSA) - Ed25519 является его частным случаем с хеш-алгоритмом SHA-512 и кривой Curve25519. Поигрался с reference implementation взятой вместе с sha512 из supercop-20200906.tar.xz (замерялка скорости работы кучи разных крипто-алгоритмов) сделав самодельные утилиты командной строки - поправленные исходники с примером использования можно найти в приаттаченном архиве:


Если развернуть архив в линухе и запустить скриптик ed25519_mk, то он соберёт 3 бинаря - ed25519keys для случайной генерации ключей (64-байтовый секретный ключ и 32-байтовый публичный) и ed25519 для подписи (генерирует 64-байтовую подпись по содержимому файла используя секретный ключ) и проверки подлинности файла (по содержимому файла используя подпись и публичный ключ - печатает Valid/Invalid), а также тестовый ed25519test для прогона 1024 заранее известных ключей, блоков данных и подписей из sign.input (взято из питоновского варианта алгоритма) для проверки корректности сборки (там ещё хеш sha512 тоже можно как утилиту собрать, если сильно хочется - опять же для проверки, что оно работает также как обычный линуксовый sha512sum).

Рандомно генерим ключи:

./ed25519keys

Ed25519 secret key:
023246c8b5b948894ae9b285f5b15a2bc5250302c96770c0ee977ad964531350342a6369075aca00c4c3674a408a65380ab75daa2b8da912b3edd3da14056c92

Ed25519 public key:
342a6369075aca00c4c3674a408a65380ab75daa2b8da912b3edd3da14056c92

Подписываем файл ed25519.h используя секретный ключ (ed25519 filename skey):

./ed25519 ed25519.h 023246c8b5b948894ae9b285f5b15a2bc5250302c96770c0ee977ad964531350342a6369075aca00c4c3674a408a65380ab75daa2b8da912b3edd3da14056c92

Ed25519 signature for ed25519.h:
7cac183bc2cb71e69a65dbd03af3a58db281cbae4edaf6427cbde264a23790809d59b44dfe35e1998c31374e564e2936c1e8ca969100970015eeb3ca1300dc03

Проверяем подлинность файла с помощью только что сгенерённой подписи и публичного ключа (ed25519 filename sign pkey):

./ed25519 ed25519.h 7cac183bc2cb71e69a65dbd03af3a58db281cbae4edaf6427cbde264a23790809d59b44dfe35e1998c31374e564e2936c1e8ca969100970015eeb3ca1300dc03 342a6369075aca00c4c3674a408a65380ab75daa2b8da912b3edd3da14056c92
Valid

Можно попробовать испортить подпись и убедиться, что ответ будет невалидным:

./ed25519 ed25519.h 8cac183bc2cb71e69a65dbd03af3a58db281cbae4edaf6427cbde264a23790809d59b44dfe35e1998c31374e564e2936c1e8ca969100970015eeb3ca1300dc03 342a6369075aca00c4c3674a408a65380ab75daa2b8da912b3edd3da14056c92
Invalid

Если подменить проверяемый файл, то также будет ошибка:

./ed25519 ed25519_mk 7cac183bc2cb71e69a65dbd03af3a58db281cbae4edaf6427cbde264a23790809d59b44dfe35e1998c31374e564e2936c1e8ca969100970015eeb3ca1300dc03 342a6369075aca00c4c3674a408a65380ab75daa2b8da912b3edd3da14056c92
Invalid

P.S. Могу виндоуз версию попробовать собрать если кому интересно (ну или досовскую)

P.P.S. Ed25519 уже оказывается много где используется: https://ianix.com/pub/ed25519-deployment.html

P.P.P.S. А вообще автор этого алгоритма (и многих других) Daniel J. Bernstein жутко умный чел 1971 года рождения (я почему-то думал, что он сильно старше), который в 15-летнем возрасте (1987) закончил школу (т.е. вундеркинд) на Лонг-Айленде (где я жил 13 лет), далее в 20-летнем возрасте (1991) закончил универ NYU (где я тоже учился), потом в 24-летнем возрасте (1995) получил PhD по математике от университета Беркли в Калифорнии (где я теперь живу) и с тех пор работает профессором в университете штата Иллинойс в Чикаго (а также в каком-то голландском универе) - сильно выступает против софтверных патентов и ограничений шифрования (несколько раз в 90х успешно засудил федеральное правительство США в результате чего федералы отменили ограничение на распостранение длинных ключей шифрования за пределами США), все свои программы выкладывает в Public Domain (т.е. берите и пользуйте все кому не лень в любых целях в том числе коммерческих и даже под собственным именем)
https://en.wikipedia.org/wiki/Daniel_J._Bernstein
http://cr.yp.to/djb.html
Вот интересная история про то как он в Питер слетал на конференцию летом 2000 года
http://cr.yp.to/conferences/russia.html

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

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

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

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

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