Концепция именованых адресов следующая: система может разрешать имена в публичные ключи и наоборот. На первом этапе с помощью интеграции существующих сервисов имён, таких как ENS, BANS и других. Возможно даже DNS. Затем добавим собственный сервис имён.
Белые списки реализуются на уровне клиентского кода, а не на уровне протокола. Т. к. проект с открытыми исходниками, то и белые и чёрные и серые списки будут реализованы, хотим мы того или нет.
Из документации, сейчас работаем над White Paper, как только будет готов черновик опубликую на GitHub. Подписывайтесь, чтобы почитать и покритиковать одним из первых :)
На стороне пользователя Eppie выглядит как почтовый клиент и специального обслуживания не требует. Что касается бэкапа, у нас есть три способа:
Если пользователь подключает несколько устройств, они соединяются в приватный кластер, и синхронизируются автоматически.
Можно выделить пространство на своем жестком диске для нужд сети, и тогда данные бэкапятся бесплатно и автоматически в децентрализованной сети.
Можно купить дополнительное место в децентрализованном хранилище.
Какой бы вариант вы ни выбрали, никаких других действий для создания резервной копии с вашей стороны не нужно.
Вы правы, есть много способов взломать пользователя. Например, от физического отъема сид-фразы, мы, увы, спасти не можем. Но надо понимать, что у нас нет паролей, а сид-фраза не пароль, она по-другому работает. Из сид-фразы генерится пара ключей. Публичный можно показать кому угодно. Приватный хранится у вас локально. Если очень коротко, вы шифруете письмо с помощью публичного ключа вашего адресата, а расшифровать его можно только с помощью парного приватного, который есть только у него. Сила этой схемы в том что критическая информация никогда не покидает устройство пользователя. Тот же пароль вы передаете серверу в момент регистрации, сервер его сохраняет в виде хеша и использует, чтобы сравнить с хешем, который вы будете передавать в момент аутентификации. Поэтому пароль можно перехватить в процессе или утащить с сервера и потом спокойно подобрать, если он слабый. С сид-фразой это все невозможно. Не бывает простых сид-фраз, и ее неоткуда украсть.
Двухфакторная аутентификация в нашем случае не нужна. 2FA — это же способ для сервера перепроверить, что пользователь, с которым он имеет дело, именно тот, за кого он себя выдает. В Eppie процесс аутентификации в некотором смысле отсутсвует. То есть нет никакого посредника, который взял бы на себя право допустить или не допустить пользователя до сети или конкретных данных. Это решение принимается локально, на машине пользователя. Можешь расшифровать данные — они твои.
И поэтому, когда мы говорим о «почте без провайдера», мы именно это хотим сказать: третьей стороны не существует.
Вот здесь мы писали подробно о том, как работает асимметричная криптография. Почитайте, когда будет настроение. А здесь очень наглядная аналогия.
Что касается Google, мы же не заставляем от него отказываться. Пользуйтесь на здоровье, наш клиент позволяет подключать аккаунт Google и Microsoft и получать лучшее из двух миров.
Создание аккаунта в Eppie — это локальная генерация пары ключей, она не нагружает сеть. А чтобы лить 100 гигабит, нужно подключать свои зловредные ноды. Но каждая нода в сети должна работать согласно протоколу иначе будет выброшена из сети. А если она будет работать согласно протоколу, то будет усиливать сеть.
Также Eppie использует в качестве инфраструктуры для доставки сообщений другие децентрализованные сети: IPFS, SBBS, DHT — то есть нужно зафлудить их все.
Поскольку каждый клиент является узлом сети, с ростом количества пользователей сеть будет становиться мощнее, и зафлудить ее со временем будет все сложнее.
И у нас предусмотрен переход на proof of work и proof of space при отправке писем в моменты сильной нагрузки сети.
Против спама у пользователя будут черные списки, белые списки, и специальные адреса на которые могут писать только доверенные адресаты.
Аренда домена и собственный почтовый сервер почти решают заявленную проблему
Сервисы Google бесплатны (можно было бы поспорить, что мы платим данными, но в общепринятом понимании действительно бесплатны)
Платить больше за лучший сервис — логично и правильно
Каждый имеет право выбора
Но, кажется, разговор идет в разных плоскостях одновременно. Давайте разделим.
Практическая плоскость — где лучше хранить секреты.
Мы утверждаем, что децентрализованная сеть с асимметричным шифрованием защищена лучше, потому что в ней исключен фактор доверия. Нет сервера — нет свободной воли провайдера, который может по разным причинам обмануть доверие. Примеров тому масса, в том числе и в этой статье. А также нет центрального хранилища — значит, нет цели для атаки, поэтому массовый слив значительно менее вероятен, если не сказать исключен.
Это не значит, что взломать сервер Google легко, и не значит, что пользователь децентрализованной сети полностью защищен. Но он защищен лучше. В том числе в бесплатной версии.
Дальше все упирается в вопрос об удобстве. Чтобы создать аккаунт в Eppie надо скопировать сид-фразу, например, в менеджер паролей и всё. Это проще, чем аренда домена и запуск собственного почтового сервера.
«Лирическая», как вы говорите, плоскость — кому что принадлежит.
Арендованный домен вам не принадлежит — он арендован. Публичный ключ в деценрализованной сети принадлежит тому, кто владеет приватным. Адрес в Eppie — это публичный ключ. Никто не может принимать никаких решений относительно этого адреса и связанных с ним данных, кроме вас. Мы даже удалить адрес не можем.
Считать ли это преимуществом — вопрос ценностный. О ценностях, наверное, не нужно спорить. Мы делаем такой продукт, потому что разделяем цености децентрализации, независимости и открытого программного обеспечения. Мы делаем ставку на то, что децентрализованные сети и ценность цифровой независимости будут становится популярнее.
Чтобы быть в курсе развития проекта. Участвовать в опросах чтобы повлиять на развитие. Но разработчикам, конечно, лучше подписываться на GitHub проекта.
Дело не только в данных. Почтовый адрес — ключ к сотням других сервисов, то что называется Digital Identity. В статье есть актуальные примеры, как сервис может его у пользователя отобрать. Или хотя бы элементарный взлом аккаунта. Ваше имя вам не принадлежит, вот и все. Наверное, не все сталкиваются на практике с катастрофическими последствиями. Но приемлемо ли крепостное право, если барин хорошо кормит и не каждый день проигрывает твоих детей в карты? Кто-то сегодня может без такого сервиса обойтись. А кто-то уже и не может. Мы верим что таких людей достаточно много, чтобы проект был полезен.
Вся сатья как раз про делегирование защиты :)
В большинстве случаев да. Но возможен вариант, когда клиент на последнем этапе доставки решает получать письмо или нет.
Концепция именованых адресов следующая: система может разрешать имена в публичные ключи и наоборот. На первом этапе с помощью интеграции существующих сервисов имён, таких как ENS, BANS и других. Возможно даже DNS. Затем добавим собственный сервис имён.
Давайте с другой стороны зайдём.
Белые списки реализуются на уровне клиентского кода, а не на уровне протокола. Т. к. проект с открытыми исходниками, то и белые и чёрные и серые списки будут реализованы, хотим мы того или нет.
Не уверен что это недостаток, тем более фатальный :)
Всё верно, полной спецификации нет.
Часть в коде: https://github.com/Eppie-io
Часть просто идеи.
Из документации, сейчас работаем над White Paper, как только будет готов черновик опубликую на GitHub. Подписывайтесь, чтобы почитать и покритиковать одним из первых :)
Да, чёрные списки для именованых адресов.
Зло или не зло, пусть каждый сам решает.
Уверен что наезды РКН начнутся не с зловредных нод :)
Релиз же только после долгого публичного бетатестирования будет.
И к релизу уже будт обкатаны и базовые меры противодействия и написаны новые.
Пока планируется принятие решения на двух уровнях:
каждая нода решает
кластер нод решает (вырабатывает консенсус)
Полностью согласен, написать можно любой зловредный код. И когда он будет написан будем писать защиту дополнительную.
Имеется ввиду конкретные реализации DHT которые работают в разных проектах.
IPFS используется и для пересылки сообщений тоже.
На стороне пользователя Eppie выглядит как почтовый клиент и специального обслуживания не требует. Что касается бэкапа, у нас есть три способа:
Если пользователь подключает несколько устройств, они соединяются в приватный кластер, и синхронизируются автоматически.
Можно выделить пространство на своем жестком диске для нужд сети, и тогда данные бэкапятся бесплатно и автоматически в децентрализованной сети.
Можно купить дополнительное место в децентрализованном хранилище.
Какой бы вариант вы ни выбрали, никаких других действий для создания резервной копии с вашей стороны не нужно.
Вы правы, есть много способов взломать пользователя. Например, от физического отъема сид-фразы, мы, увы, спасти не можем. Но надо понимать, что у нас нет паролей, а сид-фраза не пароль, она по-другому работает. Из сид-фразы генерится пара ключей. Публичный можно показать кому угодно. Приватный хранится у вас локально. Если очень коротко, вы шифруете письмо с помощью публичного ключа вашего адресата, а расшифровать его можно только с помощью парного приватного, который есть только у него. Сила этой схемы в том что критическая информация никогда не покидает устройство пользователя. Тот же пароль вы передаете серверу в момент регистрации, сервер его сохраняет в виде хеша и использует, чтобы сравнить с хешем, который вы будете передавать в момент аутентификации. Поэтому пароль можно перехватить в процессе или утащить с сервера и потом спокойно подобрать, если он слабый. С сид-фразой это все невозможно. Не бывает простых сид-фраз, и ее неоткуда украсть.
Двухфакторная аутентификация в нашем случае не нужна. 2FA — это же способ для сервера перепроверить, что пользователь, с которым он имеет дело, именно тот, за кого он себя выдает. В Eppie процесс аутентификации в некотором смысле отсутсвует. То есть нет никакого посредника, который взял бы на себя право допустить или не допустить пользователя до сети или конкретных данных. Это решение принимается локально, на машине пользователя. Можешь расшифровать данные — они твои.
И поэтому, когда мы говорим о «почте без провайдера», мы именно это хотим сказать: третьей стороны не существует.
Вот здесь мы писали подробно о том, как работает асимметричная криптография. Почитайте, когда будет настроение. А здесь очень наглядная аналогия.
Что касается Google, мы же не заставляем от него отказываться. Пользуйтесь на здоровье, наш клиент позволяет подключать аккаунт Google и Microsoft и получать лучшее из двух миров.
Да, это важные вопросы. Ответил ниже.
Создание аккаунта в Eppie — это локальная генерация пары ключей, она не нагружает сеть. А чтобы лить 100 гигабит, нужно подключать свои зловредные ноды. Но каждая нода в сети должна работать согласно протоколу иначе будет выброшена из сети. А если она будет работать согласно протоколу, то будет усиливать сеть.
Также Eppie использует в качестве инфраструктуры для доставки сообщений другие децентрализованные сети: IPFS, SBBS, DHT — то есть нужно зафлудить их все.
Поскольку каждый клиент является узлом сети, с ростом количества пользователей сеть будет становиться мощнее, и зафлудить ее со временем будет все сложнее.
И у нас предусмотрен переход на proof of work и proof of space при отправке писем в моменты сильной нагрузки сети.
Против спама у пользователя будут черные списки, белые списки, и специальные адреса на которые могут писать только доверенные адресаты.
Кажется, мы по основным пунктам с вами согласны:
Имя в домене gmail.com принадлежит Google
Аренда домена и собственный почтовый сервер почти решают заявленную проблему
Сервисы Google бесплатны (можно было бы поспорить, что мы платим данными, но в общепринятом понимании действительно бесплатны)
Платить больше за лучший сервис — логично и правильно
Каждый имеет право выбора
Но, кажется, разговор идет в разных плоскостях одновременно. Давайте разделим.
Практическая плоскость — где лучше хранить секреты.
Мы утверждаем, что децентрализованная сеть с асимметричным шифрованием защищена лучше, потому что в ней исключен фактор доверия. Нет сервера — нет свободной воли провайдера, который может по разным причинам обмануть доверие. Примеров тому масса, в том числе и в этой статье. А также нет центрального хранилища — значит, нет цели для атаки, поэтому массовый слив значительно менее вероятен, если не сказать исключен.
Это не значит, что взломать сервер Google легко, и не значит, что пользователь децентрализованной сети полностью защищен. Но он защищен лучше. В том числе в бесплатной версии.
Дальше все упирается в вопрос об удобстве. Чтобы создать аккаунт в Eppie надо скопировать сид-фразу, например, в менеджер паролей и всё. Это проще, чем аренда домена и запуск собственного почтового сервера.
«Лирическая», как вы говорите, плоскость — кому что принадлежит.
Арендованный домен вам не принадлежит — он арендован. Публичный ключ в деценрализованной сети принадлежит тому, кто владеет приватным. Адрес в Eppie — это публичный ключ. Никто не может принимать никаких решений относительно этого адреса и связанных с ним данных, кроме вас. Мы даже удалить адрес не можем.
Считать ли это преимуществом — вопрос ценностный. О ценностях, наверное, не нужно спорить. Мы делаем такой продукт, потому что разделяем цености децентрализации, независимости и открытого программного обеспечения. Мы делаем ставку на то, что децентрализованные сети и ценность цифровой независимости будут становится популярнее.
Подписывайтесь, чтобы узнать когда в проекте появятся библиотеки написанные на С++ :)
Ладно, многие не стараются :)
Чтобы быть в курсе развития проекта. Участвовать в опросах чтобы повлиять на развитие. Но разработчикам, конечно, лучше подписываться на GitHub проекта.
Дело не только в данных. Почтовый адрес — ключ к сотням других сервисов, то что называется Digital Identity. В статье есть актуальные примеры, как сервис может его у пользователя отобрать. Или хотя бы элементарный взлом аккаунта. Ваше имя вам не принадлежит, вот и все. Наверное, не все сталкиваются на практике с катастрофическими последствиями. Но приемлемо ли крепостное право, если барин хорошо кормит и не каждый день проигрывает твоих детей в карты? Кто-то сегодня может без такого сервиса обойтись. А кто-то уже и не может. Мы верим что таких людей достаточно много, чтобы проект был полезен.
Исходники тут: Eppie (github.com) но проект ещё далеко от релиза.