Привет, Хабр!
Это команда Eppie. Мы разрабатываем p2p почту, в которой пользователи владеют своими адресами и данными. Про данные мы уже говорили, сегодня остановимся на адресах.
Кому принадлежит адрес?
В современной электронной почте вы не владеете адресом, вы его, по сути, арендуете. Есть два варианта:
Адрес на домене почтового провайдера — например, username@gmail.com. Такой адрес фактически принадлежит провайдеру. Он может ограничить вам доступ, удалить ваш аккаунт или отдать адрес кому-то другому.
Адрес на «собственном» домене — например, you@yourdomain.com. Но и тут пользователь не является владельцем — он лишь арендует домен у регистратора. И если регистратор доменов сочтёт нужным, доступ к домену может быть приостановлен.
На практике, конечно, адрес как бы всегда в вашем распоряжении. Но есть тонкости. Вас могут заблокировать, например, за нарушение правил сервиса. Кто-то может выдать себя за вас, и сервис по ошибке авторизует чужого человека пользоваться вашей почтой от вашего имени. Адрес, или даже домен, могут перестать существовать. Словом, все ключевые решения остаются за сервисом. Потеря пользователем доступа к адресу всегда происходит по воле сервиса, и случается это в той или иной форме не так уж редко.
Вот например:
Google удаляет аккаунты, которые считает неактивными. Потеря адреса может произойти, если вы просто долго не заходили в почту.
X (Twitter) отбирал у пользователей красивые адреса для собственных нужд. Вот тред про аккаунт @music.
Skiff — приватная почта, собравшая $14 млн инвестиций и 2 млн пользователей, в 2024 году закрылась после покупки компанией Notion. Пользователям дали полгода на миграцию, а потом сервера просто выключили. Пользователи, использовавшие почту Skiff для регистрации в сторонних сервисах, оказались в глупом положении. Вот история пользователя OpenAI, который на тот момент не позволял менять почту в настройках учетной записи.
Электронная почта сегодня — это больше чем просто переписка. В почтовом ящике хранятся важные данные: лицензионные ключи, контракты, медицинские сведения и т. п. Через почту мы логинимся в сотнях других сервисов. Потеря почтового адреса может обернуться настоящим кошмаром.
Поэтому мы строим третью модель. В Eppie адрес не арендуется. Он создаётся пользователем и полностью ему принадлежит. Децентрализованная сеть полностью автономна, даже если мы вдруг закроемся, как Skiff, сеть будет продолжать работать, и ваши адреса останутся активными.
Сейчас расскажем, как это устроено.
Как в Eppie?
В Eppie адрес создаётся не на сервере, а прямо на вашем устройстве — как криптографический публичный ключ. Этот ключ уникален, вы его генерируете сами, и только у вас есть соответствующий приватный ключ, позволяющий читать почту и подписывать сообщения. Eppie обращается к децентрализованной сети, скачивает письма, полученные по вашему адресу, и расшифровывает их с помощью приватного ключа. Сам факт расшифровки — доказательство, что письмо принадлежит вам. Таких понятий как авторизация и аутентификация в Eppie нет.
Транспортный уровень будет реализован с помощью DHT и SBBS, а хранение — через IPFS. Подробнее о них расскажем в будущих статьях. А если любите разбираться самостоятельно, добро пожаловать на наш GitHub. Качайте сборки и участвуйте в развитии проекта.
Формат адреса
В основе адреса Eppie лежит публичный ключ secp256k1 в сжатом виде — 33 байта. Он служит уникальным идентификатором и используется как для шифрования (ECIES), так и для проверки подписей (ECDSA).
Для удобства передачи и использования адрес представляется в виде строки, закодированной в формате Base32 с алфавитом abcdefghijkmnpqrstuvwxyz23456789, исключены символы o, l, 0, 1 — чтобы избежать ошибок при визуальном восприятии и вводе.
Пример адреса:
ahejyckdjrciwq9dkdgqmemu26pr5qsmbwhfk4vf65w6sw9ivinig@eppie
Такой адрес вписывается в классический формат адрес@домен и даже «гибридный» вариант email+адрес@домен. Он может использоваться как в p2p-сети Eppie, так и в обычной почте.
Формат адрес@eppie — основной формат для общения внутри сети.
Формат адрес@домен — например, ahejy...nig@bridge.com. Если вы отправляете письмо на такой адрес из внешней почты, оно будет обработано сервисом-мостом, который узнает адрес Eppie и перенаправит письмо в децентрализованную сеть.
Формат email+адрес@домен — гибридный формат, например, alice+ahejy...nig@gmail.com . По такому адресу вам могут писать как пользователи Eppie, так и пользователи обычной почты.
Гибридные адреса и совместимость
Одно из сильных мест Eppie — гибкость адресной системы.
Гибридная модель email+адрес@домен дает возможность обмениваться сообщениями между классической почтой и децентрализованной сетью.
Помимо нативных eppie-адресов, поддерживаются и другие виды, например Bitcoin-адреса. Это значит, что вы можете зарегистрировать свой BTC-адрес как почтовый, например, bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq@eppie.
Такой адрес можно использовать для общения внутри Eppie, и даже получать письма от классических email-клиентов. Достаточно совершить любую транзакцию с этого адреса. Это позволяет использовать существующую инфраструктуру для подтверждения владения адресом.
В будущем появится возможность использовать адреса и других сетей (Ethereum, Nostr и др.):
bc1qar0...@bitcoin
0xd8dA6B...@ethereum
npub1v93...@nostr
Еще мы планируем поддерживать человекочитаемые имена с помощью сервисов имён ENS и DNS. Их задача — сопоставить симпатичное имя вроде alice.epp с криптографическим адресом. Такое имя можно будет запомнить на слух, как обычный почтовый адрес.
Для ENS адрес будет выглядеть так: alice.eth.
Для DNS - alice.com или alice.site.com, если домен второго уровня.
А для нашего сервиса децентрализованных имён, который мы тоже планируем запустить — alice.epp или alice@eppie.
Что это вам дает?
Адрес Eppie — это персональный, никому неподвластный, цифровой идентификатор.
Вы можете использовать адрес Eppie везде, где требуется стандартный email-формат.
Eppie выступает как мост между Web2 и Web3. Вы можете обмениваться сообщениями между p2p и обычной почтой.
Он может служить универсальным средством для Web2 и Web3 авторизации. Можно использовать уникальные адреса для каждого сервиса (в том числе это работает как анти-спам).
Он полностью универсален — адрес можно переносить между платформами и эпохами.
Если у вас и вашего адресата стоит клиент Eppie, вы можете общаться через адреса обычной почты, не теряя преимуществ шифрования.
Вы можете подписывать документы и переписки без PDF и DocuSign — просто с помощью адреса.
Недавно мы внедрили в Eppie ИИ, и теперь адреса можно использовать для коммуникации между автономными ИИ-агентами.
Адреса Eppie позволяют связать почту с DAO, NFT и on-chain identity, получать нотификации от блокчейн-контрактов, построить внутриигровую почту в метавселенных и DAO.
Адрес — это ваша точка входа в цифровую коммуникацию. Сегодня у пользователей нет над ним контроля: вы либо арендуете имя у почтового провайдера, либо арендуете домен у регистратора. В любом случае — адрес вам не принадлежит.
Система адресов в Eppie — это попытка перезапустить понятие цифровой идентичности: адрес создаётся прямо на вашем устройстве, не зависит от чьих-либо серверов и не может быть отозван. У вас может быть один адрес, несколько, или целая иерархия для разных целей. И никто не скажет вам, что можно, а что нельзя с ними делать.
Подписывайтесь на новостную рассылку, ставьте нам звезды на GitHub — этим вы очень помогаете развитию проекта. Спасибо!
Комментарии (49)
ildarz
02.07.2025 07:14Такой адрес вписывается в классический формат адрес@домен
И у вас даже TLD зарегистрирован с MX записями?
только у вас есть соответствующий приватный ключ
А что происходит при его компрометации? А что делать, если пользователю нужна почта на нескольких устройствах?
BaJlepa Автор
02.07.2025 07:14Формат адрес@eppie не подразумевает, что eppie это зарегистрированный TLD в системе DNS. Это условное обозначение для адресов в децентрализованной p2p-сети Eppie. В части адрес@домен 'домен' может быть любым DNS-доменом, включая ваш личный, если вы захотите настроить собственный сервис-мост для взаимодействия между обычной почтой и p2p-сетью. Например, вы можете использовать адрес@yourdomain.com, для пересылки всех обычных писем в p2p сеть.
При компрометации приватного ключа нужно создать новый адрес, так как адрес это публичный ключ.
Для использования на нескольких устройствах приватный ключ необходимо безопасно перенести на каждое устройство.
ildarz
02.07.2025 07:14это условное обозначение
В таком случае слова "такой адрес вписывается в формат @domain" ничего не значат. Если вы говорите об интероперабельности, нужны не условные обозначения, а конкретные механизмы. Как именно будет осуществляться отправка почты от xxx@eppie на xxx@domain.tld ? Как будет работать отправка в обратную сторону?
при компрометации приватного ключа нужно создать новый адрес
И вы не видите, в чем тут проблема (или даже минимум две)?
приватный ключ необходимо безопасно перенести
И здесь тоже не видите сразу две (минимум) проблемы?
BaJlepa Автор
02.07.2025 07:14Прошу подробно изложить ваши мысли по проблемам о которых вы говорите, для дальнейшего обсуждения.
nin-jin
02.07.2025 07:14Сообщения без SPF/DKIM/DMARC (а они основаны на доменных именах) будут отклонены большинством почтовых провайдеров, пока они не прикрутят аутентификацию через ваши публичные ключи, на что особо рассчитывать не стоит.
BaJlepa Автор
02.07.2025 07:14Направление p2p -> обычная почта пока нет намерения поддерживать.
nin-jin
02.07.2025 07:14А кому нужна read-only почта, где нельзя ответить на сообщение?
BaJlepa Автор
02.07.2025 07:14Большая часть писем обычной почты не требуют ответов.
Если нужна переписка, то оба адресата должны использовать p2p почту.
Yukr
02.07.2025 07:14Вообще наоборот. Это же не пейджер
BaJlepa Автор
02.07.2025 07:14Мы делаем почту для обмена сообщениями в p2p сети. Внутри сети нет никаких ограничений. При этом мы понимаем, что существует традиционная почта, и четыре миллиарда пользователей за один день с нее не слезут. Поэтому мы реализуем частичную совместимость. Это важная, но не основная часть работы. Более того, отправляя письмо на сервер централизованной почты, пользователь автоматически теряет преимущества шифрования и децентрализации. Для такой переписки Eppie функционирует как обычный почтовый клиент. Ну, а когда участники переписки захотят перейти в приватный режим (на что мы очень рассчитываем), они оба заведут себе децентрализованные адреса.
olku
02.07.2025 07:14А зря, такое ограничение оставит вас с гиками и даркнетчиками. Мост в обе стороны можно сделать на сервисе брокера сообщений. Для себя вот такое опенсорсное собрал - https://habr.com/ru/articles/661379/ Пользуюсь несколько лет, бесплатного плана хватает.
BaJlepa Автор
02.07.2025 07:14Проект полностью открытый, каждый кому нужен мост может запустить сам.
olku
02.07.2025 07:14Именно поэтому и написал коммент. Пользователи любят тех кто их любит, а вы их "посылаете" матчасть учить. Кроме гейта еще можно и сокращатель адресов делать. А при достижении популярности за красивый даже платить будут... Похоже, чутка маркетинга вам не хватает, на одном энтузиазме продукт развить до глобального масштаба трудно.
ildarz
02.07.2025 07:14Так ведь я вас спрашиваю, чтобы ваши мысли увидеть. Вы предлагаете некий сервис, мне интересно, как вы видите его работу при возникновении некоторых легко предсказуемых проблем на стороне пользователя.
По поводу компрометации (или утери) ключа вы же сами пишете - "Потеря почтового адреса может обернуться настоящим кошмаром.", аргументируя этим необходимость новой системы, и вы то же время предлагаете просто "создать новый адрес". Это не очень стыкуется друг с другом.
По работе с несколькими девайсам - ну просто промоделируйте саму ситуацию. Вот Василий завел ваш почтовый ящик на телефоне. Теперь он хочет пользоваться им еще и с ПК, планшета и умных часов. Как вы себе видите этот процесс?
nin-jin
02.07.2025 07:14Как вы себе видите этот процесс?
Тут как раз всё просто: приватный ключ шифруется паролем, передаётся на другой девайс, и там расшифровывается тем же паролем. Можете сами это попробовать в деле, например, тут.
ildarz
02.07.2025 07:14Это просто только для очень специфической аудитории, и никак не снимает вторую часть вопроса - доступ к собственно переписке. В целом еще и без универсального обмена с внешним миром выглядит просто как очередной мессенджер-игрушка для гиков.
BaJlepa Автор
02.07.2025 07:14По поводу компрометации (или утери) ключа вы же сами пишете - "Потеря почтового адреса может обернуться настоящим кошмаром.", аргументируя этим необходимость новой системы, и вы то же время предлагаете просто "создать новый адрес". Это не очень стыкуется друг с другом.
Тут разные потери, в одном случае ваш адрес почты совсем не принадлежит вам, а во втором просто нужно безопасно хранить свои ключи.
По работе с несколькими девайсам - ну просто промоделируйте саму ситуацию. Вот Василий завел ваш почтовый ящик на телефоне. Теперь он хочет пользоваться им еще и с ПК, планшета и умных часов. Как вы себе видите этот процесс?
Он должен перенести ключи любым безопасным, в его модели угроз, способом.
ildarz
02.07.2025 07:14Тут разные потери
Потеря - это потеря, пользователь либо может использовать адрес, либо нет. Если исходить не из сакральных соображений типа "я просто хочу быть собственником своего адреса, потому что хочу", то пользователю важно два вопроса - насколько сложно адрес потерять и как можно потом его восстановить. В вашем случае компрометация клиентского устройства ведет к потере адреса без возможности восстановления, и это еще умолчим о возможности злоумышленника выдавать себя за вас после этого.
Он должен перенести ключи любым безопасным, в его модели угроз, способом.
Слова, увы, ничего не значат. Просто промоделируйте ситуацию в реальности, и не для айтишника, а для рядового пользователя. Сделайте хотя бы на уровне POC демонстрацию, как это должно работать.
BaJlepa Автор
02.07.2025 07:14Да, при компрометации ключа восстановление невозможно. Зато потерять доступ к адресу значительно сложнее: никто не может заблокировать вас, удалить ящик или отобрать домен. Сейчас мы фокусируемся на конкретной задаче: полном контроле пользователя над адресом. Как будет реализована синхронизация между устройствами, расскажем в следующих статьях. Следите за обновениями!
nuclight
02.07.2025 07:14а во втором просто нужно безопасно хранить свои ключи.
ПРОСТО? Хорошая шутка! Для большинства населения это будет проще как раз в случае централизованных сервисов - которые, случ чего, просто восстановят человеку доступ по паспорту, например. И это именно та причина, по которой типичные крипто-гик решения "ключ это адрес" взлететь не могут.
BaJlepa Автор
02.07.2025 07:14Менеджмент ключей пользователем - это действительно сложная проблема. Мы делаем все от нас зависящее, чтобы сделать этот процесс понятным и удобным. На этом этапе мы как раз на крипто-гиков и ориентируемся, а широкую аудиторию будем привлекать позже.
cliver
02.07.2025 07:14Из описанного не очень понял - сам факт пересылки сообщения (или знания кол-ва сообщений) на какой-то адрес eppie по соответствующему ему публичному ключу может сторонний наблюдатель установить или нет? Может ли сторонний по публичному ключу шифротекст этих сообщений получить? Или сам адрес только на отпечатке (fingerprint) публичного ключа основан?
nin-jin
02.07.2025 07:14Web3? Пхх, да это уже прошлый век! Мы тут уже Web4 делаем. У нас тоже будет своя почта, но уже примерно вида
jin2mNt4_æA9ce2eX@mail.hyoo.ru, гдеjin2mNt4_æA9ce2eX- это хеш от публичного ключа, аmail.hyoo.ru- мост к Web2.BaJlepa Автор
02.07.2025 07:14Делайте! Я всячески за :)
UPD
Ну и более подробную статью про адреса, с удовольствием почитаю.
cliver
02.07.2025 07:14Читаю отсюда https://crus.hyoo.ru/#!=assk91_hpiehw
Unbreakable: High availability, Partition Tolerance ...
То есть consistency лесом идет из-за CAP-теоремы? Это такая "фича" Web4?
nuclight
02.07.2025 07:14Зачем этот сайт пытается мне что-то в persistent storage браузера сохранить, когда я еще даж читать не начал?..
nin-jin
02.07.2025 07:14Чтобы когда вы в следующий раз его откроете, он мгновенно поднялся из кеша, например, а не показал вам фигу после минуты ожидания на нестабильном интернете.
nuclight
02.07.2025 07:14Тут весь Веб похоронить бы, а они 4-й собрались...
Модный сейчас Web3 решает эти проблемы лишь частично — сказывается его происхождение от криптовалют, с их концепцией глобального консенсуса вокруг бесконечно растущей базы данных. Для решения всех проблем новый Веб должен быть основан не на цепочках блоков, а на подходе Local-First.
Тут, конечно, орнул. Блокчейны изначально и предполагались local-first, как и любой p2p, это ортогональные концепции.
А вообще, коим боком те CRDT (опять же разбивающаяся о реальный мир штука, например проблемы масштабирования и модерации) и прочее именно к вебу относятся там, непонятно. К очередной социалочке/мессенджеру - может быть. Но вебу?..
Ну или на этом сайте плохая навигация, что оно не нашлось.nin-jin
02.07.2025 07:14Вы, вместо того, чтобы орать, лучше бы разобрались в предмете. Блокчейны используют глобальный консенсус для формирования единой истории во избежание двойной траты. Как следствие, они ломаются при разделении сети. local-first, наоборот, работает даже в оффлайне, благодаря тому, что у каждого пира своя история изменений, но цена этому - невозможность защититься от двойной траты, что делает этот подход непригодным для криптовалют. Это фундаментальная несовместимость.
CvRDT прекрасно масштабируется. Какое отношение модерация имеет к теме обсуждения так и не понял, но особых проблем с нею нет. А вот децентрализация к архитектуре веба имеет очень даже прямое отношение.
nuclight
02.07.2025 07:14Я достаточно разбираюсь в предмете, и посоветовал бы разобраться в истории (кстати, Веб изначально был вполне себе децентрализован, и формально эта возможность еще не отобрана). Например, Биткоин предполагал хранить полную копию блокчейна на каждом узле. И в local-first ключевое слово именно first, так как потом оно всё равно уйдет в сеть; более того, основным направлением local-first являются вовсе не финансы, так что проблема двойной траты здесь - как минимум, вырожденный частный случай, как максимум, таки надумана путаницей с определениями.
Насчет масштабируемости и непонимания проблем модерации еще раз хохотнул. Простите, а нафига тогда вообще CRDT, то есть где разные узлы вносят правки в практически реалтаймы, если это не социалочка какая, скорее всего мессенджер? Для обычных "сайтов" прекрасно годится аналог git - IPFS или тому подобное, такие проекты существуют, и без всяких CRDT (буду въедливым и затребую еще, фигли именно CvRDT, а не в общем CRDT). Заявка-то на Web была...
А если мы делаем социалочку, а конкретнее вовсе даже чатик типа телеги, то сразу во весь рост встают проблемы и масштабируемости по числу участников чата, и, разумеется, баны, мьюты и так далее. Потому что в реальной жизни всё это есть.
Я процитирую из одного чатика по CRDT, когда речь зашла про аналоги систем контроля версий и мессенджеры на CRDT/P2P:
-В P2P можно делать ACL, с чего вы взяли, что нельзя. право на чтение = ключ дешифрования, право на запись = ключ подписи. Т..е ACL это буквально списки ключей. Право на редактирование прав = право записи объекта, который содержит ACL. [...]
-Я начал было писать про "конторское хранилище 1 Тб, 10 миллионов файлов, 100 тысяч сотрудников" и тем, что в классической схеме достаточно дать на каталог условный +read:sales@example.com и всё, в противовес нашифровыванию стопицот ключей для каждой комбинации файл/сотрудник индивидуально...
Но интерес же в мессенджере, поэтому возьмем наш любимый Telegram и совершенно типовую в ней историю. Вот есть канал https://t.me/uxfromhell и там можно комментировать, т.е. у него есть прикрепленный чат комментов (оставим за скобками костыльность этой архитектуры, нам цель важна). То есть туда может написать любой из миллиарда пользователей Telegram, не вступая в чат. А вот один из них, допустим я, посрался с владельцем, и меня там забанили* на некоторое время. В классических ACL (не говорю даже "централизованных") задача решается элементарно. А как на этих ваших ключах предполагается такое решать? Шифруем право записи на весь миллиард и потом одному отзываем?))*задача со звёздочкой - бан всего лишь на неделю, причем не на все типы сообщений, а текст можно, картинки-видео нельзя (или наоборот, можно только картинки). В классическом подходе ACL это уточнение ничего фундаментально не поменяет (ну структурка чуть развесистее), а вот с CRDT и/или P2P/ключами это может оказаться существенным изменением... (и нет, я не высасываю из пальца, это реальный случай)
nin-jin
02.07.2025 07:14Веб всегда был завязан на DNS - вполне себе централизованной системе имён.
Локальная копия блокчейна - это кеш, а не local-first. Попытка без глобального консенсуса изменить этот кеш приведёт лишь исключению узла из общей сети.
Если под "обычными сайтами" вы понимаете "контентные сайты без UGC", то таких уже не осталось, ибо даже контент-менеджеры работают через админки, а это уже UGC. И даже те юзеры, что только читают, хотят и комментировать любую страницу, и предлагать правки, и смотреть на диффы, и иметь доступ оффлайн, и получать нотификации, рекомендации, быть уверенными в авторстве контента, его приватности и тд.
IPFS хранит слепки документов. Их обновление - долгий процесс, захламляющий хранилище. Рекомендую глянуть это выступление, чтобы понять разницу между разными моделями хранения данных: https://youtu.be/UBzNxxu7s74?t=807
А про виды CRDT и почему именно CvRDT можете почитать тут: https://page.hyoo.ru/#!=rc0q3f_t7v40n
Реализуете Zero-Trust авторизацию и у вас нет никаких проблем с банами и мьютами в децентрализованной системе. Если не знаете как это сделать - обращайтесь, расскажу, если не будете апломбом своим размахивать.
Ключ подписи даёт аутентификацию, а не авторизацию.
Давать 100к сотрудникам доступ к 10м документов - плохая идея в любом случае. Но через групповые политики вопросы массовой выдачи прав легко решаются.
Право записи не шифруется, а подписывается. Для объекта можно задать права по умолчанию для всех.
Ограничение прав, даже временное, даже частичное, реализуется тривиально. Тоже мне задача со звёздочкой.
nuclight
02.07.2025 07:14DNS - вполне себе централизованной системе имён.
Да нет в ней никакой централизации в "плохом" смысле. Наоборот, это был триумф в свое время - сделать такую децентрализованную и при том быстро работающую систему. Никакой администратор из .ru не сможет отнять у вас домен в .tk, регистраторов толпы, и т.д.
Локальная копия блокчейна - это кеш, а не local-first. Попытка без глобального консенсуса изменить этот кеш приведёт лишь исключению узла из общей сети.
Хоть горшком назови, этот local всего лишь first как оптимизация, но без сети - бесполезен. Он тоже есть кэш части глобального состояния сети, если угодно - просто в некоторые моменты из будущего.
Если под "обычными сайтами" вы понимаете "контентные сайты без UGC", то таких уже не осталось, ибо даже контент-менеджеры работают через админки, а это уже UGC.
Абсолютно без разницы, на самом деле. С точки зрения рядового пользователя сайты UGC больше жрут / тормознее грузятся, только и всего. А именно с точки зрения пользовательского интерфейса и надо начинать проектировать такие большие системы, а не с мастурбации на технологии типа CRDT.
И даже те юзеры, что только читают, хотят и комментировать любую страницу, и предлагать правки, и смотреть на диффы, и иметь доступ оффлайн, и получать нотификации, рекомендации, быть уверенными в авторстве контента, его приватности и тд.
Чем дальше по списку, тем с каждым пунктом количество пользователей снижается на порядок. Даже я, активный в телеге, заходя на какую-нибудь lenta.ru, совсем не горю желанием её комментировать. Или даже читать комментарии под произвольным роликом на ютубе. Тем более уж с остальным.
IPFS хранит слепки документов. Их обновление - долгий процесс, захламляющий хранилище. Рекомендую глянуть это выступление, чтобы понять разницу между разными моделями хранения данных: https://youtu.be/UBzNxxu7s74?t=807
Нет, ссылки на видео я открывать не буду, это формат, недостойный Homo Sapiens Sapiens. Или потрудитесь передать словами (или дать статью), или осознайте, что IPFS приводился в качестве лишь примера - проектов децентрализованного веба по типа "а-ля торренты" более одного, мне лень их все выискивать и приводить, когда идея "типа git" и так понятна и достаточна в контексте.
А про виды CRDT и почему именно CvRDT можете почитать тут: https://page.hyoo.ru/#!=rc0q3f_t7v40n
Там сразу же вот прямо с определений начинается фигня, которую подробно жевали в комментах под соседним постом (про ООП и акторы). Ну какой в жопу порядок сообщений при том "параллелизме", если он достижим только сериализацией локов, ну. В остальном - какой-то краткий пересказ своими словами, как теории преподу - на экзамене норм, для серьезной статьи нет; CSP не упомянут вообще. При этом самая суть - почему CvRDT, а не CmRDT - осталась не раскрыта. Просто постулируется "бесконтрольно" - а что, будто кто-то на CmRDT обрезать лог снизу мешает, можно подумать...
Реализуете Zero-Trust авторизацию и у вас нет никаких проблем с банами и мьютами в децентрализованной системе. Если не знаете как это сделать - обращайтесь, расскажу, если не будете апломбом своим размахивать.
Ключ подписи даёт аутентификацию, а не авторизацию.
Давать 100к сотрудникам доступ к 10м документов - плохая идея в любом случае. Но через групповые политики вопросы массовой выдачи прав легко решаются.
Право записи не шифруется, а подписывается. Для объекта можно задать права по умолчанию для всех.
Ограничение прав, даже временное, даже частичное, реализуется тривиально. Тоже мне задача со звёздочкой.Вот как раз в этих цитатах и виден апломб с общими словами, вместо решения реальных проблем. Совершенно ж очевидно, что речь идёт об end-2-end шифровании групповых чатов. Потому что иначе, например, право на чтение реально не отобрать. Еще раз процитирую того оратора, которому я возражал:
право на чтение = ключ дешифрования, право на запись = ключ подписи. Т..е ACL это буквально списки ключей. Право на редактирование прав = право записи объекта, который содержит ACL. [...] Энфорсинг этих прав в реальном времени требует наличие подобия консенсуса, если в реальном времени не требуется то можно без него (просто на CRDT). [...] Модель может быть похожа на FIDO - мы разделяем ноду (пира) и писателей/читателей. Нода обязана обновлять ACL, если этого не делает - показывает византийское поведение — то мы её баним. [...] Право на чтение - это групповой ключ, т.е секретный ключ зашифрованный множеством приватных публичных. Право на чтение - факт присутствия ключа дешифрования в групповом ключе. Отзыв ключа чтения — удаление ключа из группового ключа. [...] Обновление ACL CRDT это не совсем CRDT т.к. требует некоего "полуконсенсуса" (нам нужно голосование в относитеьлно реальном времени, но нам не нужно защищаться от атак типа "двойная трата" —- поэтому нам не надо делать всю цепочку prevote-vote-precommit-commit, а достаточно буквально подождать кворум голосов и выяснить актуальную/популярную текущую версию головы). Даже если делать полноценный консенсус (prevote/voter/precommit/commit) - то это несложно — нам достаточно им согласовывать ACL, а сами каналы могут быть CRDT. но да, управление ACL тогда требует пиров онлайн, но по факту пиры и так всё время онлайн, что бы делать PEX (пиры появляются - отваливаются - переезжают между сетями - надо их пинговать и держать таблицу).
Так вот, это не масштабируется дальше "Васян и его друзья". Да, 100к сотрудникам доступ к 10м документов - это не плохая идея, это НОРМА. И её аналог в мессенджере - телега приводилась в пример - будет с еще куда бОльшими цифрами.
И да, должно быть не просто с этаким одолжением "расскажу", а продемонстрируйте работоспособность своего подхода на реальной практике. Вот хотя бы на тех цифрах, что выше (я не сомневаюсь, что на считанных сотнях подобные предложения работают, таких проектов было уже порядком - покажите на масштабах реального мира, с которыми централизованные системы отлично справляются, а децентрализованные только сотрясают воздух пока). А потом уже послушаем про решение задачи со звездочкой на примере добавления одного из миллиарда юзеров телеги во (временный) бан - в лобовом решении end-2-end шифрования групповых чатов это вам потребуется по миллиарду ключей на каждый чат - просто чтоб было что отозвать-то.
YMA
02.07.2025 07:14А как с недобросовестным использованием? Что предполагается делать...
Если я начну гигабайты данных отправлять? Или спам слать по всем найденным адресам? Или ссылки на закладки с веществами?
BaJlepa Автор
02.07.2025 07:14В децентрализованной сети Eppie нет центрального модератора, но мы разрабатываем защиту от флуда и злоупотреблений на уровне узлов сети. На стороне клиента будут чёрные и белые списки для управления письмами, плюс возможность создавать сколько угодно адресов, чтобы минимизировать спам. Подробности о механизмах расскажу в следующих статьях. Следите за новостями!
svanichkin
02.07.2025 07:14что бы получать и отправлять обычные письма потребуется какой то мост скорее всего?
BaJlepa Автор
02.07.2025 07:14Да, мосты нужны чтобы пересылать обычные письма в p2p сеть. Если пользователь, например, из веб-интерфейса своего Gmail, хочет отправить вам письмо в сеть Eppie, он использует адрес ahejy...nig@bridge.com.
Но есть и другие уровни совместимости с обычной почтой:
Гибридный адрес позволяет получать на один адрес обычные и p2p письма. То есть, пользователь может письмо на адрес alice+ahejy...nig@gmail.com как из обычного почтового клиента / веб-интерфейса, так и из клиента Eppie. В первом случае письмо придет на alice@gmail.com, во втором - в децентрализованную сеть Eppie на адрес ahejy...nig.
Третий вариант - подключить к Eppie обычный почтовый аккаунт и пользоваться Eppie как обычным почтовым клиентом.
YMA
02.07.2025 07:14И еще логичный вопрос - за счёт чего будет финансироваться работа шлюзов? Ладно, сама децентрализованная система будет за счёт участников функционировать, а ваши сервера?
BaJlepa Автор
02.07.2025 07:14Тут мы рассчитываем на активное сообщество. Любой, кому нужен такой шлюз, сможет сам его запустить и поддерживать.
blind_oracle
02.07.2025 07:14По-моему вы не туда воюете.
Если основная проблема обычной почты, по-вашему, это доменная система - то её и надо улучшать. Для этого уже всякие блокчейны (Namecoin или как там) и прочее придумано.
А SMTP, как по мне, достаточно федеративен и так.
GhostPepper
Для доступа к почтовому аккаунту, как правило, требуется двухфакторная авторизация. В случае eppie будет только один фактор - приватный ключ? Выглядит не очень безопасно.
BaJlepa Автор
Приватный ключ можно защитить паролем или хранить на аппаратном токене (например YubiKey), что делает его не менее безопасным, чем классическая 2FA. Это сочетание "чего-то, что у вас есть" (ключ) и "чего-то, что вы знаете" (пароль) или физического подтверждения. Вобщем годятся любые существующие методы защиты приватных ключей. Всё зависит от вашей модели угроз.