Боюсь, ваша статья вводит в заблуждение, потому что вы перепутали PGP с SSL. За последний отвечает технология PKI и это не совсем децентрализованная сеть, так как имеет корневые центры.
У iFrame существует еще недостаток - у меня события PostMessage режутся на стандартных фильтрах AdBlock и в окружении инкогнито для моего браузера.
В качестве решения по изолированию стилей, без применения iFrame, неплохо подойдут веб-компоненты. Еще одно решение, делать скоуп стили через атрибут style, - scoped, но это поддерживается сегодня только в браузерах FF.
Некоторых не устраивает наличие одного AP эндпоинта.
Нет нормального генератора API.
Каждый волен создавать свои кастомные ошибки. Из-за этого, переключаясь в другом проекте на JSON-RPC, будет тяжелее ориентироваться (условно, каждый придумывает свою ошибку 404) Думаю, это можно решить семантическими кодами.
JSON - человекочитаемый текстовый формат, некоторым нужны бинарные данные, что ускоряет передачу данных и позволяет повесить любую схему типов.
JSON-RPC может не подойти для очень сложных реквестов или респонсов, тут GraphQL выигрывает.
Еще - коммьюнити у JSON-RPC меньше, описанные выше минусы можно было бы исправить в JSON-RPC 3, но бигтеху это не надо, а свободное сообщество предпочло REST.
Для меня Web 3 — это просто маркетинговое слово, под внутренностями подразумевающее несколько особенностей:
Данные принадлежат автору (проект SOLiD) и могут отдаваться другим при его желании.
Общение с сетью просто как общение на человеческом языке (боты проходящие тест тьюринга, ChatGPT)
Данные представлены в формате знаний (Linked Data)
Знания доступны через машиночитаемый эндпоинт (SPARQL)
Общение между узлами основано на P2P (без DNS)
Каждое устройство в сети имеет физический IPv6 адрес.
Доверие к транзакциям в сети основано на Блокчейне или с помощью глобальной криптографии (проект ПостПлатформ)
И если посмотрите, то текущие технологии уже как бы есть, но нуждаются в доработке, потому и Web 3, отдаляется и все никак не настанет. Плюс, бигтеху такой Веб 3 не нужен, потому что все же работает. Вот и имеем дело. Хотите чтобы наступило светлое Web 3 будущее, то нужно работать, решая текущие проблемы. Если из списка, хотя бы перейдем на IPv6 то это уже будет большая победа.
Хотелось бы подискутировать с автором насчет вида семантичного веба.
В моем представлении, сайту должен отдаваться только JSON-LD, где в качестве значений параметров будут ссылки на другие Linked-Data, в которых будут ссылки на прочие mime-типы данных: text, ogg, avi, etc. Браузеру потребуется самостоятельно провести запросы по ссылкам графа, чтобы построить визуальное содержимое.
{
"@type": "Movie",
"name": "The Hitchhiker's Guide to the Galaxy",
"video": "https://mymovie.com/film.jsonld",
"sameAs": [
"https://www.wikidata.org/wiki/Q836821"
],
"discussionUrl": "https://anothersite.com/film.jsonld"
}
Выше базовый пример, в котором содержимое видео, его описание и комментарии по видео находятся в других доменах.
Функционал ГЛВРД можно получить в виде докер контейнера. Если такое будет интересно пользователям, я смогу добавить функционал получения по API на другом хосте.
Боюсь, ваша статья вводит в заблуждение, потому что вы перепутали PGP с SSL. За последний отвечает технология PKI и это не совсем децентрализованная сеть, так как имеет корневые центры.
У iFrame существует еще недостаток - у меня события PostMessage режутся на стандартных фильтрах AdBlock и в окружении инкогнито для моего браузера.
В качестве решения по изолированию стилей, без применения iFrame, неплохо подойдут веб-компоненты. Еще одно решение, делать скоуп стили через атрибут style, - scoped, но это поддерживается сегодня только в браузерах FF.
Минусы:
Некоторых не устраивает наличие одного AP эндпоинта.
Нет нормального генератора API.
Каждый волен создавать свои кастомные ошибки. Из-за этого, переключаясь в другом проекте на JSON-RPC, будет тяжелее ориентироваться (условно, каждый придумывает свою ошибку 404) Думаю, это можно решить семантическими кодами.
JSON - человекочитаемый текстовый формат, некоторым нужны бинарные данные, что ускоряет передачу данных и позволяет повесить любую схему типов.
JSON-RPC может не подойти для очень сложных реквестов или респонсов, тут GraphQL выигрывает.
Еще - коммьюнити у JSON-RPC меньше, описанные выше минусы можно было бы исправить в JSON-RPC 3, но бигтеху это не надо, а свободное сообщество предпочло REST.
Для меня Web 3 — это просто маркетинговое слово, под внутренностями подразумевающее несколько особенностей:
Данные принадлежат автору (проект SOLiD) и могут отдаваться другим при его желании.
Общение с сетью просто как общение на человеческом языке (боты проходящие тест тьюринга, ChatGPT)
Данные представлены в формате знаний (Linked Data)
Знания доступны через машиночитаемый эндпоинт (SPARQL)
Общение между узлами основано на P2P (без DNS)
Каждое устройство в сети имеет физический IPv6 адрес.
Доверие к транзакциям в сети основано на Блокчейне или с помощью глобальной криптографии (проект ПостПлатформ)
И если посмотрите, то текущие технологии уже как бы есть, но нуждаются в доработке, потому и Web 3, отдаляется и все никак не настанет. Плюс, бигтеху такой Веб 3 не нужен, потому что все же работает. Вот и имеем дело. Хотите чтобы наступило светлое Web 3 будущее, то нужно работать, решая текущие проблемы. Если из списка, хотя бы перейдем на IPv6 то это уже будет большая победа.
Хотелось бы подискутировать с автором насчет вида семантичного веба.
В моем представлении, сайту должен отдаваться только JSON-LD, где в качестве значений параметров будут ссылки на другие Linked-Data, в которых будут ссылки на прочие mime-типы данных: text, ogg, avi, etc. Браузеру потребуется самостоятельно провести запросы по ссылкам графа, чтобы построить визуальное содержимое.
Выше базовый пример, в котором содержимое видео, его описание и комментарии по видео находятся в других доменах.
Идея хорошая. Сейчас для CJM используется Miro, что в нынешних экономических ситуациях вынуждает большие компании отказываться от него.
Из новых идей- нужна интеграция с той же Jira.
Функционал ГЛВРД можно получить в виде докер контейнера. Если такое будет интересно пользователям, я смогу добавить функционал получения по API на другом хосте.