Comments 74
Turtle is a compact way of representing RDF data, using URLs to represent subject, predicate and object.
Чуть чуть недоперевели.
Обрабатывать такие данные будет невозможно. Всё равно копию приложение будет хранить для себя. В итоге в под просто будет выгружаться что-то типа бэкапа. Бэкапы и свободный формат выгрузки данных, это хорошо, но на революцию и "новый интернет" не похоже.
В моем понимании, единственный реалистичный вариант — после открытия доступа к перс. данным приложению должен закрываться доступ в интернет.
Люди просто не будут писать приложения с использованием такой "технологии", как вы описали. Под будет не просто защищен, но и никому не нужен.
Да, много вопросов и это ещё одна важная проблема при децентрализации (чуть ниже о другой). Имеется прозрачная аутентификация при перемещении по сети, каковая, к примеру, реализована в Hubzilla?
Насколько мне известно это на сегодня вообще вне поля зрения Solid. Печально.
не избавляемся из-за DNS
DNS это меньшее из зол. Вообще, вы знаете хоть один (!) децентрализованный протокол, где бы удалось реализовать отвязку от DNS или, что хуже, собственных сервисов каталогов на этапе discovery? Я пока ни одного не видел.
В ZeroNet вместо централизованной DNS для коротких имён используется блокчейн Namecoin, в котором зарегистрированы пары "sitename.bit" — <hash-адрес>.
Ага, а discovery происходит обращением к централизованному каталогу (торрент-треккеру). Спасибо, но вариант с DNS выглядит куда как более надёжным.
Ну, нет. Давно уже сделали PEX. Привязку к трекерам можно отключить, руками добавить одного пира и пошло-поехало. Да, могут быть проблемы со скачиванием новых сайтов, но они решаются.
Ну это всё о том же. "Тот пир" всё равно должен как-то находить адресатов с доселе неизвестной или изменившейся локацией. То есть в рамках самой системы проблема не решена (скорее даже не решаема).
Вопрос не в том, как кого-то найти, когда узел в сети, тут решений вагон, а в первичном discovery. Да и не только. При распределённой базе возможен вариант, что хранимый локально кусок будет полностью содержать устаревшие данные и ни один из пиров будет недоступен. И вот, опять, вопрос как найти контакт.
Можно хранить всю карту сети. Но решение так себе при мало-мальски серьёзных размерах сети по ряду причин.
Во-первых, если сервис не скрывается (как телеграм), он может держать веб-сайт, раздающий по HTTP списки пиров (и когда пир обращается за списком, он сам попадает в него). Сервис можно сделать открытым (всего лишь 1 php-файл) и энтузиасты, у которых есть сайт, могут хостить его сами и давать адреса bootstrap-сервиса где угодно (а в клиенте можно вести список bootstrap-сервисов, пополняемый юзером).
Во-вторых, клиент перед закрытием может сохранять на диск сотню адресов известных пиров. Высока веорятность, что даже через месяц-два из этой сотни кто-нибудь, да выживет.
В-третьих, ручной ввод ip-адреса пира. Адреса можно публиковать децентрализованно где угодно, хоть в комментариях на Хабре, но благодаря первым двум пунктам к этому вряд ли придётся прибегнуть.
Во-первых, если сервис не скрывается (как телеграм), он может держать веб-сайт, раздающий по HTTP
И далее по пунктам, как раз, вот такая "децентрализация" нам и не нужна. Именно об этом я и пишу.
Спасибо, но лучше DNS based тогда. Именно потому что он децентрализован, распределён и многократно продублирован.
И далее по пунктам, как раз, вот такая «децентрализация» нам и не нужнаЭто хорошая децентрализация, потому что любой может стать координатором (поднять сервис discovery и пиарить его через любые доступные каналы).
Спасибо, но лучше DNS based тогда.Чтобы его РосКомНадзор выпилил, или домен через суд отняли?
Любой может поднять свой домен и пиарить его через любые доступные каналы.
А выпилить вас и так ничего не помешает. Путём блокировки вашего IP, блокировки линка или отключения сервера, например. Транспорт тот же, так что никакой разницы.
Или вообще по порту выпилить ваш ZeroNet чего с DNS сделать никому в здравом сознании в голову не придёт.
Да, если вы пропустили, от перехвата DNS трафика есть DNS-over-TLS и иные более велосипедные варианты, а для валидации данных DNSSEC.
Любой может поднять свой домен и пиарить его через любые доступные каналы.Но этот любой не владеет доменом, даже в США домен могут отнять через суд.
А выпилить вас и так ничего не помешает. Путём блокировки вашего IP, блокировки линка или отключения сервера, например. Транспорт тот же, так что никакой разницыIP или сервер можно сменить.
Или вообще по порту выпилить ваш ZeroNet чего с DNS сделать никому в здравом сознании в голову не придёт.Используется TCP-соединение с рандомным портом. Удачи выпиливать )))
Да, если вы пропустили, от перехвата DNS трафика есть DNS-over-TLS и иные более велосипедные варианты, а для валидации данных DNSSEC.А толку, если домен разделегируют.
Но этот любой не владеет доменом, даже в США домен могут отнять через суд.
В любой стране через суд могут отнять ваш компьютер, право пользоваться сетью и даже свободу. Много вариантов.
IP или сервер можно сменить.
Или домен.
Короче, ни о чём.
1. Нужно регулярно платить деньги
2. Нет анонимной регистрации
Мне вот просто лень заводить домены, потому что в ру-центр нужно будет слать сканы документов.
Так вы жадный или ленивый?
В первом случае вам сюда
http://freedns.afraid.org/domain/registry/
а во втором, без DNS геморроя поболее.
Можно хранить всю карту сети. Но решение так себе при мало-мальски серьёзных размерах сети по ряду причин.Теоретически, этот вопрос решает DHT. Это хорошо масштабируемый и отказоустойчивый механизм для сохранения большого кол-ва пар ключ/значение (например, список пиров у раздачи с определённым хешем). Когда юзер входит в сеть, он отправляет свой адрес в DHT, или когда обновляет данные, тоже отправляет их в DHT, и актуальные данные быстро реплицируются.
Да, попадался такой вариант в одном из проектов. Типа сканируется QR друг у друга и тогда есть контакт.
Я к тому, что в сравнении с остальными discovery посредством DNS выглядит лучшим из возможных вариантов.
Вообще, возвращаясь к Solid очень много вопросов даже по важным деталям самой концепции, не говоря уже о технических подробностях.
Да, но я не вижу как её решает Solid. То есть он решает её не в большей степени, чем, к примеру, нынешние HTML/HTTP. Попало в сеть, получил доступ, закэшировал и адьос амигос. Теперь ты свои данные не контролируешь.
С другой стороны, если речь идёт о моём семейном порно, DRM перестаёт казаться такой уж плохой идеей. Впрочем, с чего бы вдруг моему семейному порно вообще оказываться в сети? Разве что личка, ну так для таких особо особых кейсов есть всякие Tux, которые мало того что всегда end-to-end шифрованные, так ещё и неуловимые Джо до кучи. Хотя дефакто все пользуются телегой, причём даже без сикрет чатов, считая, что это уже достаточно секьюрно, и так, по-видимому, будет до первых серьёзных компроментаций :)
Уже давно пора надо было это сделать. Свои данные держи при себе и храни как хочешь. Я думаю взлетит. Ток не понял как будут проверять валидность подов? Провайдеры будут какой ключ давать?
Спасибо за перевод, замечательная статья, есть над чем подумать. Только вот я не совсем понял концепцию
Таким образом, приложения оказались тесно связаны с данными пользователей. Создание какого-либо приложения для сети предполагает глобальное управление персональными данными.
В профессиональном плане я разрабатываю системы управления воздушным движением. Сегодня они сетевые и зачастую глобальные (учитывают погоду по всему шарику, данные по линии IATA/ICAO). Плюс терабайты данных с радаров и специализированных подсистем типа менеджеров взлета, посадки, управления терминалами и взлетно-посадочным полем. Пользовательских данных — 0. То есть это по факту не сетевое приложение?
Или вот недавно я для себя написал Андроид-приложение управления сетевым музыкальным плеером по сети. Никаких пользовательских данных, только протокол команда/ответ. Это тоже не сетевое приложение?
Для музыки я пользуюсь стриминговыми сервисами (на данный момент Deezer). Да, они сохранили мой логин. Но суммарный объем именно пользовательских данных много-много-много меньше, чем базовый контент (музыка). То есть по факту это тоже не сетевое приложение?
Или прямые покупки в интернет-магазинах. Помимо логина, у них есть еще и платежные данные и адрес. Но и этот объем много-много-много меньше, чем базовый контент (данные о товарах). Это тоже не сетевое приложение?
На первый взгляд, эта технология нужна только для того, чтобы переписать фейсбук/твиттер/VK так, чтобы не было самого фейсбук/твиттер/VK, то есть для децентрализованной социальной сети. Но ведь жизнь не ограничивается только социальными сетями?
В любом случае, еще раз спасибо за перевод, попробую по приведенным ссылкам разобраться с этими своими вопросами.
1. введённые пользователем данные должны принадлежать этому пользователюЧто касается вводимых логина/пароля/профайла — если они принадлежат только пользователю, то он имеет право порождать эти сущности в любом количестве — как тогда защититься форуму от мультиаккаутинга? Если же потребовать некоего уникального идентификатора для всех профилей создаваемых пользователем, то как тогда обеспечивать его анонимность в сети?
2. Он должен иметь право перемещать их между провайдерами, давать и забирать у приложений доступ к ним.Предположим пользователь пишет платные посты на некий форум — эти посты принадлежат форуму или ему? Если форуму, то как это соотносится с вашим 1-м утверждением и может ли пользователь тогда делать все перечисленное в вашем 2-м утверждении?
3. никакой модератор в сети не должен иметь право удалять плоды творчества любого пользователя — только отлинковать их от модерируемого им местаЕсли модератор форума забанит/отлинкует пользователя от форума, то пользователь естественно вправе забрать у этого форума доступ ко всем своим постам (отлинковать их в отместку например). Что тогда будет со структурой этого форума, если профиль этого пользователя и его посты упоминались-цитировались в постах других пользователей?
Как вообще быть со всей этой концепцией, если по ней — любой мой бесплатный пост на некоем форуме принадлежит только мне и я могу с ним делать все что захочу — изменять до тех пор пока мне не надоест или и вовсе удалить — причем неважно, что на это пост кто-то мог уже ответить или процитировать?
Или же все-таки эта концепция не работает и данные, вводимые пользователем таки могут принадлежать не только ему и подчиняться некоему регламенту — если это так, то чем тогда это все отличается от нынешней ситуации?
Не мешайте романтикам мечтать своим грубым прагматизмом. :)
если они принадлежат только пользователю, то он имеет право порождать эти сущности в любом количестве
Он и так и так может порождать сущности в любом количестве, если его не идентифицировать.
Если же потребовать некоего уникального идентификатора для всех профилей создаваемых пользователем, то как тогда обеспечивать его анонимность в сети?
Никак. Либо одно либо другое. Сервис волен не пускать анонимов. Вы вольны не посещать такой сервис.
Предположим пользователь пишет платные посты на некий форум — эти посты принадлежат форуму или ему?
Зависит от того какие именно неимущественные права на своё произведение продал пользователь. В любом случае я бы сделал неотчуждаемым право иметь свою копию поста. А право публикации отчуждаемым лишь до тех пор пока издатель его реализует. Перестал обеспечивать доступность н времени — право возвращается автору. Если пойти ещё дальше, то я бы и продавать неимущественные права запретил и ограничивать распространение легально опубликованных материалов.
Если модератор форума забанит/отлинкует пользователя от форума, то пользователь естественно вправе забрать у этого форума доступ ко всем своим постам (отлинковать их в отместку например).
Имеет. И форум перестанет получать уведомления об их редактировании. Форум же точно так же имеет право использовать свою копию опубликованных в свободный доступ данных на какой-то момент времени. А не опубликованных — не имеет.
я могу с ним делать все что захочу — изменять до тех пор пока мне не надоест или и вовсе удалить — причем неважно, что на это пост кто-то мог уже ответить или процитировать?
Вы и так на многих форумах можете редактировать ваши посты как угодно.
вводимые пользователем таки могут принадлежать не только ему
Разумеется не только. А я где-то утверждал, что его права не отчуждаемы?
чем тогда это все отличается от нынешней ситуации?
Эти отличия я перечислил в том сообщении, на которое вы отвечали. Или вы из тех, кто дальше первого предложения не читает и спешит написать разгромный комментарий?
Если пойти ещё дальше, то я бы и продавать неимущественные права запретил и ограничивать распространение легально опубликованных материалов.Это убьет профессиональную журналистику.
Издатель (журнал, газета, сайт и т.п.) платит профессиональному автору (журналисту, профильному эксперту, писателю и т.п.) деньги, за то, что он создает уникальный качественный контент. Затем журнал продает этот контент читателям (платная подписка, реклама на сайте и т.п.).
Зачем издателю покупать контент, который не будет ему принадлежать? Как он будет монетезировать такой конктент?
Вы хотите автора этого выбора лишить, оставив только один вариант. Зачем?
Вы авторов, которые пользуются услугами издетельств спросили, хотят ли они всем этим заморачиватся чтобы заработать больше или хотят потерять в деньгах, но иметь больше времени для творчества? Кто им сейчас запрещает не пользоваться услугами посредника?
А зачем между журналистом и читателем посредник в виде издателя в современном мире?Для фильтрации информации, централизации информации (читаю сразу много в одном месте, а не держу сотню закладок на блоги по одному посту в месяц), некое количество репутации (может быть как плюсом, так и минусом), открытие новых авторов. Это для пользователя. Для автора издатель полезен тем, что у него количество просмотров будет выше (кроме случая топ звезд) просто потому что там больше одного автора, не нужно заморачиваться монетизацией и продвижением — это отдельная работа на которую вполне может не быть времени и/или желания.
На самом деле функций у издателя еще больше, но даже этого достаточно для оправдания его существования.
2. Как обязать авторов приложений хранить все данные пользователя только в его поде? Если сможете сделать это — сделайте сейчас, без всякого Solid.
Я так понимаю, что вновь предлагается привязка данных к одному конкретному месту ("поду") и с его незапланированной утратой по той или иной причине с данными можно будет прощаться? В таком случае, это не интересно, поскольку уже есть решения которые это проблему, которая является одной из важнейших в децентрализованных сетях, уже решили.
Нда… Главное, нельзя сказать, что это вообще имеет смысл. Не хочу флеймить, но чем SOLID лучше ZeroNet? Вон, в зеронете есть форумы, соцсеть, вики, чаты, даже какой-то прототип онлайн-игр (disclaimer: мой) и т.д. При этом, о нем мало кто знает. Но стоит Бернерсу-Ли объявить о платформе (которая умеет гораздо меньше), как сразу начинает бурлить весь интернет… Это как?
То есть, например, я создаю свой узел вида mysite.pp/forum_profile и ввожу туда данные, а при регистрации на форуме не ввожу свои данные, а указываю этот путь, откуда форум (естественно написанный в такой же идеологии) в риал-тайме подгружает мои данные при показе моих сообщений. Также можно хранить и сообщения, и картинки и что угодно, главное чтобы обменивающиеся данными узлы поддерживали один формат данных — протоколы то давно существуют, и с авторизацией в том числе.
Или идея в чем-то принципиально другом?
Я просто уже третью статью на эту тему на Хабре читаю и ни в одной не увидел четкого и понятного объяснения что именно, как и зачем делается, и почему именно так, а не иначе.
Уже реализовано в виде протокола Zot6. Сейчас в процессе внедрения.
Причём с прозрачной аутентификацией в рамках сети.
https://macgirvin.com/wiki/mike/Zot%2BVI/Home
SOLID не взлетит по целой куче причин:
- SOLID ничего не даёт юзерам. Вся эта чушь про "владение" своими данными, "перемещение" своих данных, отсутствие необходимости "синхронизации" — если внимательно присмотреться, то на самом деле для юзера ничего не изменится.
- SOLID предполагает, что сложные данные можно оторвать от приложений. На данный момент не видно никаких реальных оснований для такого оптимизма. Да, есть универсальные интерфейсы для доступа к данным (файлы, SQL, key/value, HTTP, HTML, JSON, …) но они все отличаются тем, что никак не определяют природу/формат хранимых данных, и только по этой причине они популярны и широко используются. Все попытки придумать более конкретные способы разметки данных — либо так и не стали популярны, либо крайне ограничивают функционал и по этой причине используются исключительно для переноса данных из одного приложения в другое (и, как правило, это сопровождается потерей части данных — типичный пример это перенос контактов между разными прошивками/приложениями на телефоне, при котором теряется информация о группах контактов, портится качество фоточек контактов, etc.). Приложения конкурируют не столько по UI/UX, скольку по функционалу — а для разного функционала нужные разные данные. Соответственно, данные которые для себя создали разработчики одного приложения никак не стандартизированы, а значит не могут использоваться разработчиками других приложений. Стандартизировать эти данные, в общем случае, невозможно, потому что они постоянно изменяются вместе с функционалом создавшего их приложения. Иногда, для определённых типов данных, формируется достаточно универсальное/стандартное описание — но это занимает годы и случается довольно редко. Применить это в качестве общего подхода для всех приложений и всех данных — утопия.
- Текущее состояние технологий не предоставляет технической возможности получать данные из личных PODов сотен людей каждый раз, когда посетитель открывает страницу сайта вроде этой (статья, комменты, лайки, профили комментаторов, etc.). А это значит, что на практике все данные будут по-прежнему храниться в собственных БД приложений, даже если копия этих данных будет ещё и в PODе юзеров. Изображённое на этом слайде, на данный момент, не жизнеспособно:
Что же тогда остаётся и зачем нужен SOLID? Всё очень просто: "мы опоздали к делёжке данных пользователей, их уже разобрали между собой большие игроки, которые теперь контролируют доступ к этим данным — поэтому давайте мы отберём у них контроль над этими данными, и сделаем так, чтобы ни одна конкретная/большая компания не могла мешать новым/мелким компаниям получить доступ к данным пользователей".
Вы видимо не совсем понимаете децентрализванную суть неймспейсов. Каждая компания-разработчик может описывать свои данные в своём неймспейсе и хранить всё это в общем хранилище. Приложения других компаний могу поддержать эти неймспейсы, если хотят работать с данными, созданными теми приложениями. А всю недостающую функциональность реализовать в своём неймспейсе. Всегда будут один или несколько доминирующих неймспейсов. Обычно это либо какой-то стандартный неймспейс типа dublin core, либо неймспейс доминирующей в какой-то области компании типа facebook. Разумеется неймспейсы могут иметь версии, как имеют версии api. Так что при хранении данных в одном месте у пользователя данные не теряются при переходе с одного приложения на другое. Другое приложение может не поддерживать какой-то неймспейс, а потом начать поддерживать.
А вопрос агрегирования данных вполне может решаться отдельными сервисами, по типу сегодняшних поисковиков, которые будут мониторить прилинкованные ресурсы и предкешировать результат в одном. Этот момент у Тима не продуман, да. Но не взлетит оно не поэтому, а потому, что то, как оно выглядит сейчас — даже программисту не понятно, что уж говорить про обычных пользователей. А без красивой обёртки никакую революционную идею не продать. Тем более что да, нужны крупные игроки поддерживающие децентрализации, но им-то это не особо и надо. Даже наоборот.
Неймспейсы и версии решают эту проблему исключительно в теории, а на практике это работать не сможет. Если взять какой-то минимум конкретных данных, вроде базового профиля юзера, то эти данные ещё можно кое-как стандартизировать и сделать так, чтобы версий формата этих данных было не больше 3-4 штук и все приложения поддерживали все эти версии. Но как только речь заходит об основных данных какого-то приложения, то их формат может меняться раз в пару недель — как спринт закончился и релизнули новую версию приложения. Никакое стороннее приложение не в состоянии угнаться за этими изменениями (даже если эти изменения будут тщательно документироваться, что крайне сомнительно). Плюс ко всему, как только мы оторвали данные от приложения, мы получили ситуацию, когда у разных юзеров данные этого приложения используют разные версии — просто потому, что юзер давно не запускал приложение и оно не мигрировало свои данные в более новый формат. А значит стороннее приложение должно или уметь само выполнять миграцию данных чужого приложения, или поддерживать все существующие версии данных чужого приложения. Резюмируя — на практике это реализовать невозможно.
Что касается агрегаторов, то сторонний и универсальный должен будет иметь доступ к абсолютно всем данным всех юзеров, что убивает идею контроля доступа приложений к данным. А реализация агрегатора в рамках каждого приложения аккуратно возвращает нас к текущей ситуации, когда у каждого приложения своя БД со всеми нужными ему данными на его собственном сервере — только в случае SOLID приложения получают дополнительную головную боль непрерывной (и как бы не двухсторонней) синхронизации своей БД с сотнями тысяч удалённых PODов, причём в этих PODах часть данных этого приложения должна раскладываться в неймспейсы других приложений в разных форматах и версиях, а часть в собственный неймспейс.
Агрегатору будет иметь доступ ко всем публичным данным всех пользователей. Пользователь может выбрать тот или иной агрегатор и разрешить ему доступ к каким-то своим приватным данным, если хочет какую-то персонификацию. Вы бы вместо того, чтобы высасывать из пальца почему это «невозможно», подумали как это можно реализовать и как можно было бы решить те или иные проблемы малой кровью. Пользы было бы больше. Или вы считаете текущую ситуацию верхом совершенства?
Это вы сейчас сильно теоретизируете.
Скорее излагаю личный опыт 30 лет разработки софта.
АФАЙК никто сейчас не выкатывает ломающие изменения апи каждую неделю.
API — нет. БД — да (может, не неделю-две, а месяц-полтора, но это ничего не меняет). И нет, БД != API. С точки зрения теории/демагогии можно заявить что схема БД это тоже, в некотором смысле, API. Но на практике отношение к ним совершенно разное: API стараются проектировать намного тщательнее (что съедает намного больше ресурсов), и потому, что ломать API дорого и больно, и потому, что API вещь публичная и любая лажа в API быстрее приводит к убыткам (репутационным, проблемам с производительностью или безопасностью, etc.); в то же самое время схему БД меняют не сильно заморачиваясь, лишь бы не было явных проблем с консистентностью данных и скоростью доступа к ним.
Более того, следствием того, что требования к БД и API разные, является то, что нередко перед БД ставят отдельный микросервис, чья задача предоставлять стабильный API к БД с нестабильной схемой. И если бы реализация этого микросервиса была прямолинейной и тупой, то его бы просто назвали непосредственно "сервис БД" (и получилось бы что-нить вроде memcached/Redis), но, как правило, это не так — такие микросервисы поддерживают несколько версий API, занимаются кешированием, проксированием в другие микросервисы и агрегацией данных, балансировкой нагрузки, контролем доступа уровня приложения, и много ещё чем, что нельзя переложить на обычную БД.
Как раз таки именно формат и стандартизирован, а значит может быть прочитан и даже отображён генерализованным представлением, как это делают, например, RDF-браузеры. А вот онтологий (словарей семантики) может быть много разных. И если приложение понимает семантику, тот может отобразить данные в более удобном для пользователя виде.
У нас до сих пор нет меша, который бы работал из коробки на всех роутерах и ноутбуках. Нет общепринятой замены текущего ДНС и т.д.
golos.io/p2p/@foxcool/spasenie-interneta
Когда-то примерно то же самое говорили про опенсорс.
Даже сейчас есть вполне "взлетевшие" децентрализованные сервисы — начиная от веба, email, XMPP и заканчивая торрентами. Даже интернет как таковой — вполне себе децентрализованный сервис, если опустить некоторые нюансы вроде корневых DNS. Другое дело, что термин "децентрализованный" в отношении подхода SOLID и вышеупомянутых "сервисов" означает немного разные вещи. Непосредственный жёсткий контроль — это только один из способов делать деньги, очень грубый, прямолинейный, и он стремительно устаревает…
Не поймите не правильно сама идея мне очень нравится и я обеими руками за. Выбирать гда хранить свои данные этт круто и нужно. Но… я.не.верю уже. После примера как биткоин стал практически полностью централизован (биржи, пулы) я не знаю что должно произойти стобы в массе своей интернет стал децентрализироаанным
Плюс современные ютюб фейсбук инстаграмм уже могут влиять на картину мира большинства людей и как только почувствуют что пахнет жареным, они включать маховик пропаганды и все вернется наткруги своя.
Даже сейчас есть вполне «взлетевшие» децентрализованные сервисы — начиная от веба, email, XMPP и заканчивая торрентами.
Эти сервисы или основали сам сервис, или заняли вполне доступную нишу. Однако данные пользователей — слишком лакомый кусок, который делят сейчас все в сети. С трудом верится что взлетит как хотелось бы. И слишком беззаботные пользователи, которые абсолютно не думают куда сливаются их персональные данные.
Хотя конечно, видимо он займет свою нишу
Введение в SOLID: новый редецентрализованный интернет Тима Бернерса-Ли