Тут в другой моей теме затронули другую интересную

Здравствуйте, velkin, Вы писали:

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

я там вижу проблемы скорее политическое, чем технические

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

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

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

3. Вы раскрываете не тока бд, а и всю логику бэкэнда, сам целиком он как показывает практика никому не интересен в плане украсть, но какие-то алгоритмы могут оказаться ценным ноу-хау.

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

Поэтому я пока не вижу как сделать чистый р2р бэкэнд
Зато можно сделать по другому — открытый облачный протокол
Это когда вам предоставляется не облако с одним владельцем, а облачные провайдеры выступают как пиры небольшой р2р сети, а может и не такой большой. Пиром может быть как датацентр так и 1 сервер, просто датацентр потянет 10 тыщ клиентов, а домашний сервер только 10.

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

(я кста для своего проекта между делом написал простейший движок распределенной (как блокчейн) но реляционной БД заточенной на свободную р2р репликацию налету, но у меня там нет задачи чтото скрывать. Причем нашлось простое и элегантное решение как их клонировать и синхронизировать налету не используя историю транзакций.

Тут в другой моей теме затронули другую интересную

Здравствуйте, velkin, Вы писали:

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

я там вижу проблемы скорее политическое, чем технические

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

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

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

3. Вы раскрываете не тока бд, а и всю логику бэкэнда, сам целиком он как показывает практика никому не интересен в плане украсть, но какие-то алгоритмы могут оказаться ценным ноу-хау.

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

Поэтому я пока не вижу как сделать чистый р2р бэкэнд
Зато можно сделать по другому — открытый облачный протокол
Это когда вам предоставляется не облако с одним владельцем, а облачные провайдеры выступают как пиры небольшой р2р сети, а может и не такой большой. Пиром может быть как датацентр так и 1 сервер, просто датацентр потянет 10 тыщ клиентов, а домашний сервер только 10.

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

(я кста для своего проекта между делом написал простейший движок распределенной (как блокчейн) но реляционной БД с мерами обеспечения криптогарфической целостности, заточенной на свободную р2р репликацию налету, но у меня там нет задачи чтото скрывать, задача была сделать "блокчейн без блокчейна". Причем нашлось простое и элегантное решение как их клонировать и синхронизировать налету не используя историю транзакций.