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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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