Недавно профессор Тим Бернерс-Ли представил проект под названием Solid. Я решил ознакомиться с ним. В этой статье я объясню, для чего нужен Solid и как вы можете начать работать с ним.
Что такое Solid?
Solid — это попытка редецентрализовать интернет.
Редецентрализовать?
Раньше интернет представляли как децентрализованное общее пространство для считывания и записи данных. Первый браузер, который назывался WorldWideWeb, был также и редактором.
Однако с развитием интернета структура веб-приложений по целому ряду причин стала централизоваться. Данные пользователей превратились в источник силы и дохода интернет-компаний.
Solid — решение этой проблемы.
Solid — это новая парадигма для веб-приложений, которая обратно совместима с существующим интернетом.
Solid — это набор технологий, группа связанных протоколов и внедрений, а также растущее сообщество. Совсем как интернет.
Разделение приложений и данных
До появления интернета ваши данные хранились на личном компьютере.
Как только люди начали пользоваться множеством компьютеров, а в повседневную жизнь вошли еще и смартфоны, модель «ваши данные остаются с вами» сменилась на «ваши данные находятся в одном или нескольких крупных центрах обработки и хранения информации по всему миру, которыми управляют разработчики приложений».
Таким образом, приложения оказались тесно связаны с данными пользователей. Создание какого-либо приложения для сети предполагает глобальное управление персональными данными.
Приложения и их способность приносить деньги измеряются тем, как построена их база данных. Ваши данные тяжело переносить, поскольку в разных приложениях хранение информации сильно различается.
Что в результате? Почти каждое приложение является изолированным. Это снижает мотивацию разработчиков вводить новшества на уровне приложений. Существующие платформы защищены от сбоев, так как блокировка данных ограничивает пользователей в перемещениях.
Правила защиты данных
В некоторых странах были приняты законы о защите данных. Компании обязаны сделать вашу личную информацию управляемой, чтобы вы могли скачать или удалить ее.
Таким образом пользователям пытаются вернуть контроль над их данными. Это законное предписание, но не техническая реальность. Вся информация о пользователях по-прежнему находится у разработчиков, и от возможности скачать свои данные мало толка, если вы не можете перенести их в другое приложение.
Поды: держите свои данные при себе
Проект Solid решает технический аспект этой проблемы. Он позволяет создавать приложения таким образом, чтобы они могли считывать и записывать данные, которые хранятся в вашем поде (англ. «pod» — personal online data).
У вас и ваших друзей есть поды, которые содержат информацию. Вы даете приложениям разрешение на доступ к вашему поду.
У вас их может быть несколько: один вы используете дома, другой на работе. Ваш под может существовать на компьютере, или распределяться между вашими устройствами, или храниться для вас на каком-то ресурсе.
Поды содержат связанные данные. Ваш под может быть связан с информацией на моем поде или где-то в интернете.
Мы хотим, чтобы приложения работали на разных устройствах, но при этом наши данные были независимыми. И нам нужно, чтобы различные приложения могли использовать одни и те же данные и имели к ним доступ.
Идеи, лежащие в основе Solid
Изучение проекта Solid напомнило мне, как я делал первые шаги в веб-разработке. Помню, как одновременно осваивал HTML, CSS, JavaScript и фреймворки, которые использовались на тот момент.
Отличие лишь в том, что Solid это новый проект и найти помощь в его освоении сложнее.
Если подумываете начать разработку для Solid, то перед вами собрание основных концептов.
(P.S. Если вы хотите сразу перейти к делу, читайте раздел «Первые шаги»).
Связанные данные
Сила Solid и интернета в целом заключается в том, как все данные скрепляются гиперссылками.
В Solid вы храните созданные вами данные где угодно. Ваша личная информация, скорее всего, хранится в вашем поде. Как и в интернете, для доступа к этим данным вам нужно перейти по URL-адресу.
Самое время представить вам расшифровку названия Solid: SOcial LInked Data (общественные связанные данные).
Читайте подробности о связанных данных в контексте проекта Solid.
Среда описания ресурса (RDF)
RDF — это способ представления связанных данных посредством утверждений вида
subject-predicate-object. Их также называют триплетами.RDF — это абстрактная модель. Ее даже можно представить на примере английских предложений. Перед вами задание из списка задач:
T1 is a task
T1 is labelled "Write an article about Solid"
T1 is due October 5rd 2018
T1 is assigned to @itsarnavb
T1 is incompleteTurtle
Turtle — это компактный способ представления данных RDF с помощью URL для передачи
subject, predicate и object.<http://example.org/person/Nassim_Taleb> <http://example.org/relation/author> <http://example.org/books/The_Black_Swan>.
<http://example.org/person/Nassim_Taleb> <http://example.org/relation/author> <http://example.org/books/Antifragile>.
<http://example.org/person/Nassim_Taleb> <http://example.org/relation/author> <http://example.org/books/Skin_in_the_Game>.Три ссылки в каждой строке — Subject, Predicate и Object соответственно.
Они повторяются, их тяжело читать, поэтому у turtle есть система префиксов и условных обозначений. Это особенно важно при работе с большими документами.
@prefix p: <http://example.org/person/> .
@prefix rel: <http://example.org/relation/> .
@prefix book: <http://example.org/book/> .
p:Nassim_Taleb rel:author book:The_Black_Swan,
book:Antifragile,
book:Skin_in_the_Game.Читайте больше о turtle. Также вы можете ознакомиться с полным документом о turtle здесь. Это подробный публичный профиль профессора Рубена Вербора, который является частью команды создателей Solid.
Семантическая паутина
Тим Бернерс-Ли наилучшим образом объясняет смысл всего этого:
«Я мечтаю о том, чтобы интернет [с помощью компьютеров] мог анализировать все сетевые данные — контент, ссылки и транзакции между людьми и компьютерами. «Семантическую паутину», которая сделает это возможным, еще только предстоит разработать, но когда это произойдет, ежедневными механизмами торговли, бюрократическими процедурами и нашей повседневной жизнью будут заниматься машины, общающиеся между собой. «Интеллектуальные агенты», которых люди так давно расхваливают, наконец-то станут реальностью».
Первые шаги
Выполняйте эти задачи в любой удобной для вас последовательности.
- Получите свой под: зарегистрируйтесь на любом бесплатном провайдере подов или, если хотите, запустите свой собственный сервер.
- Создайте Solid-приложение с помощью этого урока.
- Прочтите о следующих возможностях Solid.
- Ознакомьтесь с документацией Solid.
Переходите на Solid
Вы поможете экосистеме Solid, если:
- вложитесь в разработку самого проекта Solid и инфраструктуры, связанной с ним;
- будете разрабатывать приложения, используя Solid.
Но имейте в виду, что в данный момент разработка для Solid — это тернистый путь со множеством проб и ошибок, на котором вам придется задавать глупые вопросы и искать на них ответы. Тут нет Stack Overflow, куда можно было бы обратиться. Для того, чтобы отладить некоторые ошибки, вам, вероятно, потребуется погрузиться в исходный код.
Вот сообщества, в которых вам могут помочь:
- r/solid (я являюсь одним из модераторов);
- gitter.im/solid.
И наконец, вот мой Twitter для личных сообщений: @itsarnavb. Я попытаюсь ответить на все поступающие вопросы или найду того, кто сможет это сделать.
Я буду поддерживать актуальность этой статьи, опираясь на лучшие ресурсы для изучения Solid.
Дополнительные материалы
Комментарии (74)
Hardcoin
10.11.2018 11:48+1Обрабатывать такие данные будет невозможно. Всё равно копию приложение будет хранить для себя. В итоге в под просто будет выгружаться что-то типа бэкапа. Бэкапы и свободный формат выгрузки данных, это хорошо, но на революцию и "новый интернет" не похоже.
Sabubu
11.11.2018 03:17Я думаю, тут нужен какой-то принципиальный механизм, который позволяет загрузить приложение и прочитать данные, но не позволяет этому приложению ничего отправить «домой». Интересно, конечно, как это сделать?
В моем понимании, единственный реалистичный вариант — после открытия доступа к перс. данным приложению должен закрываться доступ в интернет.gdt
11.11.2018 10:21+1… После чего эти данные записываются в local storage, и отправляются на сервер, как только появляется доступ к интернет.
Hardcoin
11.11.2018 14:54+1Люди просто не будут писать приложения с использованием такой "технологии", как вы описали. Под будет не просто защищен, но и никому не нужен.
Sabubu
12.11.2018 03:04По вашей логике, open source код тоже никто не пишет. Кто-нибудь да будет. Тем более что предлагаемая схема работы не исключает возможность оплаты приложений. Первое, что приходит в голову — всякие бизнес-сервисы и онлайн бухгалтерии: люди явно предпочтут сервис, который ничего принципиально слить не может. Также, сервисы для работы с документами внутри компании.
Hardcoin
12.11.2018 10:16Оплата тут ни при чем. За пример спасибо, действительно рынок может найтись. Узкоспециализированный.
qw1
10.11.2018 12:19И ни слова об изменении идентификации ресурсов. Во всех примерах HTTP-URI, значит простым пользователям нельзя будет легко перенести ресурс на другой домен, не поломав ссылки. А самое главное, от централизации не избавляемся из-за DNS.
mxms
10.11.2018 17:59Да, много вопросов и это ещё одна важная проблема при децентрализации (чуть ниже о другой). Имеется прозрачная аутентификация при перемещении по сети, каковая, к примеру, реализована в Hubzilla?
Насколько мне известно это на сегодня вообще вне поля зрения Solid. Печально.
не избавляемся из-за DNS
DNS это меньшее из зол. Вообще, вы знаете хоть один (!) децентрализованный протокол, где бы удалось реализовать отвязку от DNS или, что хуже, собственных сервисов каталогов на этапе discovery? Я пока ни одного не видел.
robux
10.11.2018 23:38В ZeroNet вместо централизованной DNS для коротких имён используется блокчейн Namecoin, в котором зарегистрированы пары "sitename.bit" — <hash-адрес>.
mxms
10.11.2018 23:52+1Ага, а discovery происходит обращением к централизованному каталогу (торрент-треккеру). Спасибо, но вариант с DNS выглядит куда как более надёжным.
Ivanq
11.11.2018 08:13Ну, нет. Давно уже сделали PEX. Привязку к трекерам можно отключить, руками добавить одного пира и пошло-поехало. Да, могут быть проблемы со скачиванием новых сайтов, но они решаются.
mxms
11.11.2018 13:46Ну это всё о том же. "Тот пир" всё равно должен как-то находить адресатов с доселе неизвестной или изменившейся локацией. То есть в рамках самой системы проблема не решена (скорее даже не решаема).
qw1
11.11.2018 14:06Для поиска пиров есть DHT. Хеш пира ничем не отличается от хеша торрент-раздачи, и если перед протоколом стоит задача поиска пира (например, для прямого соединения), то у этой задачи уже есть готовое решение.
mxms
11.11.2018 14:21Вопрос не в том, как кого-то найти, когда узел в сети, тут решений вагон, а в первичном discovery. Да и не только. При распределённой базе возможен вариант, что хранимый локально кусок будет полностью содержать устаревшие данные и ни один из пиров будет недоступен. И вот, опять, вопрос как найти контакт.
Можно хранить всю карту сети. Но решение так себе при мало-мальски серьёзных размерах сети по ряду причин.qw1
11.11.2018 15:04Первичный discovery несложно делается.
Во-первых, если сервис не скрывается (как телеграм), он может держать веб-сайт, раздающий по HTTP списки пиров (и когда пир обращается за списком, он сам попадает в него). Сервис можно сделать открытым (всего лишь 1 php-файл) и энтузиасты, у которых есть сайт, могут хостить его сами и давать адреса bootstrap-сервиса где угодно (а в клиенте можно вести список bootstrap-сервисов, пополняемый юзером).
Во-вторых, клиент перед закрытием может сохранять на диск сотню адресов известных пиров. Высока веорятность, что даже через месяц-два из этой сотни кто-нибудь, да выживет.
В-третьих, ручной ввод ip-адреса пира. Адреса можно публиковать децентрализованно где угодно, хоть в комментариях на Хабре, но благодаря первым двум пунктам к этому вряд ли придётся прибегнуть.Ivanq
11.11.2018 15:23Кстати, вы по сути описали то, как peer discovery сделан в ZeroNet. Любой может поднять трекер с помощью встроенного плагина (дальше просто даешь остальным IP или домен). Пиры сохраняются в peers.json. Руками тоже можно добавить, но тут придется руками peers.json менять, а не через UI, это минус.
mxms
11.11.2018 15:28Во-первых, если сервис не скрывается (как телеграм), он может держать веб-сайт, раздающий по HTTP
И далее по пунктам, как раз, вот такая "децентрализация" нам и не нужна. Именно об этом я и пишу.
Спасибо, но лучше DNS based тогда. Именно потому что он децентрализован, распределён и многократно продублирован.qw1
11.11.2018 16:21И далее по пунктам, как раз, вот такая «децентрализация» нам и не нужна
Это хорошая децентрализация, потому что любой может стать координатором (поднять сервис discovery и пиарить его через любые доступные каналы).
Спасибо, но лучше DNS based тогда.
Чтобы его РосКомНадзор выпилил, или домен через суд отняли?mxms
11.11.2018 16:35Любой может поднять свой домен и пиарить его через любые доступные каналы.
А выпилить вас и так ничего не помешает. Путём блокировки вашего IP, блокировки линка или отключения сервера, например. Транспорт тот же, так что никакой разницы.
Или вообще по порту выпилить ваш ZeroNet чего с DNS сделать никому в здравом сознании в голову не придёт.
Да, если вы пропустили, от перехвата DNS трафика есть DNS-over-TLS и иные более велосипедные варианты, а для валидации данных DNSSEC.qw1
11.11.2018 17:28Любой может поднять свой домен и пиарить его через любые доступные каналы.
Но этот любой не владеет доменом, даже в США домен могут отнять через суд.
А выпилить вас и так ничего не помешает. Путём блокировки вашего IP, блокировки линка или отключения сервера, например. Транспорт тот же, так что никакой разницы
IP или сервер можно сменить.
Или вообще по порту выпилить ваш ZeroNet чего с DNS сделать никому в здравом сознании в голову не придёт.
Используется TCP-соединение с рандомным портом. Удачи выпиливать )))
Да, если вы пропустили, от перехвата DNS трафика есть DNS-over-TLS и иные более велосипедные варианты, а для валидации данных DNSSEC.
А толку, если домен разделегируют.mxms
11.11.2018 18:14Но этот любой не владеет доменом, даже в США домен могут отнять через суд.
В любой стране через суд могут отнять ваш компьютер, право пользоваться сетью и даже свободу. Много вариантов.
IP или сервер можно сменить.
Или домен.
Короче, ни о чём.qw1
11.11.2018 18:26А как насчёт таких недостатков DNS:
1. Нужно регулярно платить деньги
2. Нет анонимной регистрации
Мне вот просто лень заводить домены, потому что в ру-центр нужно будет слать сканы документов.mxms
11.11.2018 18:54Так вы жадный или ленивый?
В первом случае вам сюда
http://freedns.afraid.org/domain/registry/
а во втором, без DNS геморроя поболее.
qw1
11.11.2018 15:08Можно хранить всю карту сети. Но решение так себе при мало-мальски серьёзных размерах сети по ряду причин.
Теоретически, этот вопрос решает DHT. Это хорошо масштабируемый и отказоустойчивый механизм для сохранения большого кол-ва пар ключ/значение (например, список пиров у раздачи с определённым хешем). Когда юзер входит в сеть, он отправляет свой адрес в DHT, или когда обновляет данные, тоже отправляет их в DHT, и актуальные данные быстро реплицируются.
unxed
11.11.2018 00:24А как должна выглядеть полная децентрализация? Ручками вбей IP друга? В i2p, кажется, так можно, да и не только в нём.
mxms
11.11.2018 00:45Да, попадался такой вариант в одном из проектов. Типа сканируется QR друг у друга и тогда есть контакт.
Я к тому, что в сравнении с остальными discovery посредством DNS выглядит лучшим из возможных вариантов.
Вообще, возвращаясь к Solid очень много вопросов даже по важным деталям самой концепции, не говоря уже о технических подробностях.unxed
11.11.2018 15:15В любом случае с проблемой контроля сервисов над данными необходимо что-то делать. Гугл хотя бы архивом всё отдать готов, у них там законы такие, положено. А вот вытянуть весь свой контент из бложика во вконтакте я вообще никак не могу. А, учитывая, что инструментов для удобного доступа к своим же постам, скажем, годичной давности, там вообще нет — становится и вовсе печально.
mxms
11.11.2018 15:39+1Да, но я не вижу как её решает Solid. То есть он решает её не в большей степени, чем, к примеру, нынешние HTML/HTTP. Попало в сеть, получил доступ, закэшировал и адьос амигос. Теперь ты свои данные не контролируешь.
unxed
11.11.2018 16:05Не совсем так. Возможность вытянуть (и удобно использовать / автоматизированно обрабатывать) данные и возможность отозвать данные — разные вещи. Проблемы сейчас и с тем, и с другим; Solid, еяпп, целится в первое, а вот возможно ли второе в принципе, да и нужно ли — мне вот лично пока не ясно, тем более, что это уже до неотличимости похоже на DRM становится.
С другой стороны, если речь идёт о моём семейном порно, DRM перестаёт казаться такой уж плохой идеей. Впрочем, с чего бы вдруг моему семейному порно вообще оказываться в сети? Разве что личка, ну так для таких особо особых кейсов есть всякие Tux, которые мало того что всегда end-to-end шифрованные, так ещё и неуловимые Джо до кучи. Хотя дефакто все пользуются телегой, причём даже без сикрет чатов, считая, что это уже достаточно секьюрно, и так, по-видимому, будет до первых серьёзных компроментаций :)
larienovich
10.11.2018 13:22Уже давно пора надо было это сделать. Свои данные держи при себе и храни как хочешь. Я думаю взлетит. Ток не понял как будут проверять валидность подов? Провайдеры будут какой ключ давать?
unxed
11.11.2018 00:24А кто помешает приложению, единожды получившему доступ к данным, оставить копию у себя навечно? Впрочем, кому нужны не актуализирующиеся данные. Но вот штуки типа соответствия реального имени и емэйла всё равно придётся отдавать фактически навечно.
mkulesh
10.11.2018 13:43Спасибо за перевод, замечательная статья, есть над чем подумать. Только вот я не совсем понял концепцию
Таким образом, приложения оказались тесно связаны с данными пользователей. Создание какого-либо приложения для сети предполагает глобальное управление персональными данными.
В профессиональном плане я разрабатываю системы управления воздушным движением. Сегодня они сетевые и зачастую глобальные (учитывают погоду по всему шарику, данные по линии IATA/ICAO). Плюс терабайты данных с радаров и специализированных подсистем типа менеджеров взлета, посадки, управления терминалами и взлетно-посадочным полем. Пользовательских данных — 0. То есть это по факту не сетевое приложение?
Или вот недавно я для себя написал Андроид-приложение управления сетевым музыкальным плеером по сети. Никаких пользовательских данных, только протокол команда/ответ. Это тоже не сетевое приложение?
Для музыки я пользуюсь стриминговыми сервисами (на данный момент Deezer). Да, они сохранили мой логин. Но суммарный объем именно пользовательских данных много-много-много меньше, чем базовый контент (музыка). То есть по факту это тоже не сетевое приложение?
Или прямые покупки в интернет-магазинах. Помимо логина, у них есть еще и платежные данные и адрес. Но и этот объем много-много-много меньше, чем базовый контент (данные о товарах). Это тоже не сетевое приложение?
На первый взгляд, эта технология нужна только для того, чтобы переписать фейсбук/твиттер/VK так, чтобы не было самого фейсбук/твиттер/VK, то есть для децентрализованной социальной сети. Но ведь жизнь не ограничивается только социальными сетями?
В любом случае, еще раз спасибо за перевод, попробую по приведенным ссылкам разобраться с этими своими вопросами.
vintage
10.11.2018 21:17+1Дело не в том сколько данных, а в том, что введённые пользователем данные должны принадлежать этому пользователю. Он должен иметь право перемещать их между провайдерами, давать и забирать у приложений доступ к ним. И никакой модератор в сети не должен иметь право удалять плоды творчества любого пользователя — только отлинковать их от модерируемого им места.
AlexTest
11.11.2018 08:58+1Вот если вы говорите про модератора, то первый тип приложений, что приходит в голову это — форумы. Давай те попробуем на примере форумов рассмотреть сказанное вами:
1. введённые пользователем данные должны принадлежать этому пользователю
Что касается вводимых логина/пароля/профайла — если они принадлежат только пользователю, то он имеет право порождать эти сущности в любом количестве — как тогда защититься форуму от мультиаккаутинга? Если же потребовать некоего уникального идентификатора для всех профилей создаваемых пользователем, то как тогда обеспечивать его анонимность в сети?
2. Он должен иметь право перемещать их между провайдерами, давать и забирать у приложений доступ к ним.
Предположим пользователь пишет платные посты на некий форум — эти посты принадлежат форуму или ему? Если форуму, то как это соотносится с вашим 1-м утверждением и может ли пользователь тогда делать все перечисленное в вашем 2-м утверждении?
3. никакой модератор в сети не должен иметь право удалять плоды творчества любого пользователя — только отлинковать их от модерируемого им места
Если модератор форума забанит/отлинкует пользователя от форума, то пользователь естественно вправе забрать у этого форума доступ ко всем своим постам (отлинковать их в отместку например). Что тогда будет со структурой этого форума, если профиль этого пользователя и его посты упоминались-цитировались в постах других пользователей?
Как вообще быть со всей этой концепцией, если по ней — любой мой бесплатный пост на некоем форуме принадлежит только мне и я могу с ним делать все что захочу — изменять до тех пор пока мне не надоест или и вовсе удалить — причем неважно, что на это пост кто-то мог уже ответить или процитировать?
Или же все-таки эта концепция не работает и данные, вводимые пользователем таки могут принадлежать не только ему и подчиняться некоему регламенту — если это так, то чем тогда это все отличается от нынешней ситуации?vintage
11.11.2018 11:20если они принадлежат только пользователю, то он имеет право порождать эти сущности в любом количестве
Он и так и так может порождать сущности в любом количестве, если его не идентифицировать.
Если же потребовать некоего уникального идентификатора для всех профилей создаваемых пользователем, то как тогда обеспечивать его анонимность в сети?
Никак. Либо одно либо другое. Сервис волен не пускать анонимов. Вы вольны не посещать такой сервис.
Предположим пользователь пишет платные посты на некий форум — эти посты принадлежат форуму или ему?
Зависит от того какие именно неимущественные права на своё произведение продал пользователь. В любом случае я бы сделал неотчуждаемым право иметь свою копию поста. А право публикации отчуждаемым лишь до тех пор пока издатель его реализует. Перестал обеспечивать доступность н времени — право возвращается автору. Если пойти ещё дальше, то я бы и продавать неимущественные права запретил и ограничивать распространение легально опубликованных материалов.
Если модератор форума забанит/отлинкует пользователя от форума, то пользователь естественно вправе забрать у этого форума доступ ко всем своим постам (отлинковать их в отместку например).
Имеет. И форум перестанет получать уведомления об их редактировании. Форум же точно так же имеет право использовать свою копию опубликованных в свободный доступ данных на какой-то момент времени. А не опубликованных — не имеет.
я могу с ним делать все что захочу — изменять до тех пор пока мне не надоест или и вовсе удалить — причем неважно, что на это пост кто-то мог уже ответить или процитировать?
Вы и так на многих форумах можете редактировать ваши посты как угодно.
вводимые пользователем таки могут принадлежать не только ему
Разумеется не только. А я где-то утверждал, что его права не отчуждаемы?
чем тогда это все отличается от нынешней ситуации?
Эти отличия я перечислил в том сообщении, на которое вы отвечали. Или вы из тех, кто дальше первого предложения не читает и спешит написать разгромный комментарий?
DaneSoul
11.11.2018 13:23Если пойти ещё дальше, то я бы и продавать неимущественные права запретил и ограничивать распространение легально опубликованных материалов.
Это убьет профессиональную журналистику.
Издатель (журнал, газета, сайт и т.п.) платит профессиональному автору (журналисту, профильному эксперту, писателю и т.п.) деньги, за то, что он создает уникальный качественный контент. Затем журнал продает этот контент читателям (платная подписка, реклама на сайте и т.п.).
Зачем издателю покупать контент, который не будет ему принадлежать? Как он будет монетезировать такой конктент?vintage
11.11.2018 13:38А зачем между журналистом и читателем посредник в виде издателя в современном мире? На мой взгляд вся не личная информация должна свободно распространяться. Пока этого не будет — наживаться на информации будут издатели и другие посредники, но не авторы.
DaneSoul
11.11.2018 13:52Сейчас у автора есть выбор — либо распространяй сам и решай кучу административных вопросов (издание, реклама, прием оплаты и т.п.) с этим связанных или отдай часть дохода и вопросы распространения издателю, а сам занимайся только творчеством.
Вы хотите автора этого выбора лишить, оставив только один вариант. Зачем?
Вы авторов, которые пользуются услугами издетельств спросили, хотят ли они всем этим заморачиватся чтобы заработать больше или хотят потерять в деньгах, но иметь больше времени для творчества? Кто им сейчас запрещает не пользоваться услугами посредника?vintage
11.11.2018 14:40+1Те авторы, что меня интересуют (в основном с хабра и ютуба) чуть ли не сами доплачивают, чтобы донести свои свои материалы до аудитории. И знаете, их материалы пусть и не всегда имеют хорошее оформление, но часто интересней и полезней, чем то, что делают «профессиональные журналисты» типа Ализара и Ко. И плачу я им за это той же монетой — создавая совершенно бесплатные материалы.
dimm_ddr
12.11.2018 13:27А зачем между журналистом и читателем посредник в виде издателя в современном мире?
Для фильтрации информации, централизации информации (читаю сразу много в одном месте, а не держу сотню закладок на блоги по одному посту в месяц), некое количество репутации (может быть как плюсом, так и минусом), открытие новых авторов. Это для пользователя. Для автора издатель полезен тем, что у него количество просмотров будет выше (кроме случая топ звезд) просто потому что там больше одного автора, не нужно заморачиваться монетизацией и продвижением — это отдельная работа на которую вполне может не быть времени и/или желания.
На самом деле функций у издателя еще больше, но даже этого достаточно для оправдания его существования.vintage
12.11.2018 21:30Так никто не спорит, что издатель-как-сервис может быть полезен. Но не издатель-как-заказчик.
eugenero
10.11.2018 15:321. Допустим, вы разрешили приложению доступ к своему поду. Кто помешает ему скопировать эти данные куда-то и продать, как это делается сейчас?
2. Как обязать авторов приложений хранить все данные пользователя только в его поде? Если сможете сделать это — сделайте сейчас, без всякого Solid.
mxms
10.11.2018 17:52Я так понимаю, что вновь предлагается привязка данных к одному конкретному месту ("поду") и с его незапланированной утратой по той или иной причине с данными можно будет прощаться? В таком случае, это не интересно, поскольку уже есть решения которые это проблему, которая является одной из важнейших в децентрализованных сетях, уже решили.
robux
10.11.2018 23:47+1Опять никаких технических деталей, но по общим словам похоже, что Бернерс-Ли-Company мутит гибрид Disapora и ZeroNet с семантическими связями и привязкой к DNS.
Ivanq
11.11.2018 08:18Нда… Главное, нельзя сказать, что это вообще имеет смысл. Не хочу флеймить, но чем SOLID лучше ZeroNet? Вон, в зеронете есть форумы, соцсеть, вики, чаты, даже какой-то прототип онлайн-игр (disclaimer: мой) и т.д. При этом, о нем мало кто знает. Но стоит Бернерсу-Ли объявить о платформе (которая умеет гораздо меньше), как сразу начинает бурлить весь интернет… Это как?
DaneSoul
11.11.2018 01:11Что нам мешает реализовать подобное в текущем Вебе на текущих технологиях путем веб-сервисов с API обменивающимися и хранящими данными в виде JSON / XML?
То есть, например, я создаю свой узел вида mysite.pp/forum_profile и ввожу туда данные, а при регистрации на форуме не ввожу свои данные, а указываю этот путь, откуда форум (естественно написанный в такой же идеологии) в риал-тайме подгружает мои данные при показе моих сообщений. Также можно хранить и сообщения, и картинки и что угодно, главное чтобы обменивающиеся данными узлы поддерживали один формат данных — протоколы то давно существуют, и с авторизацией в том числе.
Или идея в чем-то принципиально другом?
Я просто уже третью статью на эту тему на Хабре читаю и ни в одной не увидел четкого и понятного объяснения что именно, как и зачем делается, и почему именно так, а не иначе.vintage
11.11.2018 02:34Это собственно оно и есть. Так, как вы описали. SOLID — попытка протолкнуть единый межсервисный апи.
mxms
11.11.2018 13:39Уже реализовано в виде протокола Zot6. Сейчас в процессе внедрения.
Причём с прозрачной аутентификацией в рамках сети.
https://macgirvin.com/wiki/mike/Zot%2BVI/Home
powerman
11.11.2018 12:15+3SOLID не взлетит по целой куче причин:
- SOLID ничего не даёт юзерам. Вся эта чушь про "владение" своими данными, "перемещение" своих данных, отсутствие необходимости "синхронизации" — если внимательно присмотреться, то на самом деле для юзера ничего не изменится.
- SOLID предполагает, что сложные данные можно оторвать от приложений. На данный момент не видно никаких реальных оснований для такого оптимизма. Да, есть универсальные интерфейсы для доступа к данным (файлы, SQL, key/value, HTTP, HTML, JSON, …) но они все отличаются тем, что никак не определяют природу/формат хранимых данных, и только по этой причине они популярны и широко используются. Все попытки придумать более конкретные способы разметки данных — либо так и не стали популярны, либо крайне ограничивают функционал и по этой причине используются исключительно для переноса данных из одного приложения в другое (и, как правило, это сопровождается потерей части данных — типичный пример это перенос контактов между разными прошивками/приложениями на телефоне, при котором теряется информация о группах контактов, портится качество фоточек контактов, etc.). Приложения конкурируют не столько по UI/UX, скольку по функционалу — а для разного функционала нужные разные данные. Соответственно, данные которые для себя создали разработчики одного приложения никак не стандартизированы, а значит не могут использоваться разработчиками других приложений. Стандартизировать эти данные, в общем случае, невозможно, потому что они постоянно изменяются вместе с функционалом создавшего их приложения. Иногда, для определённых типов данных, формируется достаточно универсальное/стандартное описание — но это занимает годы и случается довольно редко. Применить это в качестве общего подхода для всех приложений и всех данных — утопия.
- Текущее состояние технологий не предоставляет технической возможности получать данные из личных PODов сотен людей каждый раз, когда посетитель открывает страницу сайта вроде этой (статья, комменты, лайки, профили комментаторов, etc.). А это значит, что на практике все данные будут по-прежнему храниться в собственных БД приложений, даже если копия этих данных будет ещё и в PODе юзеров. Изображённое на этом слайде, на данный момент, не жизнеспособно:
Что же тогда остаётся и зачем нужен SOLID? Всё очень просто: "мы опоздали к делёжке данных пользователей, их уже разобрали между собой большие игроки, которые теперь контролируют доступ к этим данным — поэтому давайте мы отберём у них контроль над этими данными, и сделаем так, чтобы ни одна конкретная/большая компания не могла мешать новым/мелким компаниям получить доступ к данным пользователей".
vintage
11.11.2018 12:52Вы видимо не совсем понимаете децентрализванную суть неймспейсов. Каждая компания-разработчик может описывать свои данные в своём неймспейсе и хранить всё это в общем хранилище. Приложения других компаний могу поддержать эти неймспейсы, если хотят работать с данными, созданными теми приложениями. А всю недостающую функциональность реализовать в своём неймспейсе. Всегда будут один или несколько доминирующих неймспейсов. Обычно это либо какой-то стандартный неймспейс типа dublin core, либо неймспейс доминирующей в какой-то области компании типа facebook. Разумеется неймспейсы могут иметь версии, как имеют версии api. Так что при хранении данных в одном месте у пользователя данные не теряются при переходе с одного приложения на другое. Другое приложение может не поддерживать какой-то неймспейс, а потом начать поддерживать.
А вопрос агрегирования данных вполне может решаться отдельными сервисами, по типу сегодняшних поисковиков, которые будут мониторить прилинкованные ресурсы и предкешировать результат в одном. Этот момент у Тима не продуман, да. Но не взлетит оно не поэтому, а потому, что то, как оно выглядит сейчас — даже программисту не понятно, что уж говорить про обычных пользователей. А без красивой обёртки никакую революционную идею не продать. Тем более что да, нужны крупные игроки поддерживающие децентрализации, но им-то это не особо и надо. Даже наоборот.
powerman
11.11.2018 13:26+1Неймспейсы и версии решают эту проблему исключительно в теории, а на практике это работать не сможет. Если взять какой-то минимум конкретных данных, вроде базового профиля юзера, то эти данные ещё можно кое-как стандартизировать и сделать так, чтобы версий формата этих данных было не больше 3-4 штук и все приложения поддерживали все эти версии. Но как только речь заходит об основных данных какого-то приложения, то их формат может меняться раз в пару недель — как спринт закончился и релизнули новую версию приложения. Никакое стороннее приложение не в состоянии угнаться за этими изменениями (даже если эти изменения будут тщательно документироваться, что крайне сомнительно). Плюс ко всему, как только мы оторвали данные от приложения, мы получили ситуацию, когда у разных юзеров данные этого приложения используют разные версии — просто потому, что юзер давно не запускал приложение и оно не мигрировало свои данные в более новый формат. А значит стороннее приложение должно или уметь само выполнять миграцию данных чужого приложения, или поддерживать все существующие версии данных чужого приложения. Резюмируя — на практике это реализовать невозможно.
Что касается агрегаторов, то сторонний и универсальный должен будет иметь доступ к абсолютно всем данным всех юзеров, что убивает идею контроля доступа приложений к данным. А реализация агрегатора в рамках каждого приложения аккуратно возвращает нас к текущей ситуации, когда у каждого приложения своя БД со всеми нужными ему данными на его собственном сервере — только в случае SOLID приложения получают дополнительную головную боль непрерывной (и как бы не двухсторонней) синхронизации своей БД с сотнями тысяч удалённых PODов, причём в этих PODах часть данных этого приложения должна раскладываться в неймспейсы других приложений в разных форматах и версиях, а часть в собственный неймспейс.
vintage
11.11.2018 13:48Это вы сейчас сильно теоретизируете. АФАЙК никто сейчас не выкатывает ломающие изменения апи каждую неделю. Так как это сказывается прежде всего на своих же приложениях, которые пользователи не так чтобы часто обновляют. Давайте не высасывать проблемы из пальца. Формат данных меняется весьма редко. Но да, нужно поддерживать несколько версий и уметь читать/сохранять и в старые версии тоже. Это, конечно, проблема, но не фатальная.
Агрегатору будет иметь доступ ко всем публичным данным всех пользователей. Пользователь может выбрать тот или иной агрегатор и разрешить ему доступ к каким-то своим приватным данным, если хочет какую-то персонификацию. Вы бы вместо того, чтобы высасывать из пальца почему это «невозможно», подумали как это можно реализовать и как можно было бы решить те или иные проблемы малой кровью. Пользы было бы больше. Или вы считаете текущую ситуацию верхом совершенства?powerman
11.11.2018 15:22Это вы сейчас сильно теоретизируете.
Скорее излагаю личный опыт 30 лет разработки софта.
АФАЙК никто сейчас не выкатывает ломающие изменения апи каждую неделю.
API — нет. БД — да (может, не неделю-две, а месяц-полтора, но это ничего не меняет). И нет, БД != API. С точки зрения теории/демагогии можно заявить что схема БД это тоже, в некотором смысле, API. Но на практике отношение к ним совершенно разное: API стараются проектировать намного тщательнее (что съедает намного больше ресурсов), и потому, что ломать API дорого и больно, и потому, что API вещь публичная и любая лажа в API быстрее приводит к убыткам (репутационным, проблемам с производительностью или безопасностью, etc.); в то же самое время схему БД меняют не сильно заморачиваясь, лишь бы не было явных проблем с консистентностью данных и скоростью доступа к ним.
Более того, следствием того, что требования к БД и API разные, является то, что нередко перед БД ставят отдельный микросервис, чья задача предоставлять стабильный API к БД с нестабильной схемой. И если бы реализация этого микросервиса была прямолинейной и тупой, то его бы просто назвали непосредственно "сервис БД" (и получилось бы что-нить вроде memcached/Redis), но, как правило, это не так — такие микросервисы поддерживают несколько версий API, занимаются кешированием, проксированием в другие микросервисы и агрегацией данных, балансировкой нагрузки, контролем доступа уровня приложения, и много ещё чем, что нельзя переложить на обычную БД.
vintage
11.11.2018 21:29А при чём тут БД? Солид — он про апи хранения данных. Единое для всех апи.
qw1
11.11.2018 21:51Речь о том, что формат хранения не стандартизован, и одно приложение не сможет читать данные другого (или без спецификаций будет это делать глючно)
vintage
11.11.2018 22:23Как раз таки именно формат и стандартизирован, а значит может быть прочитан и даже отображён генерализованным представлением, как это делают, например, RDF-браузеры. А вот онтологий (словарей семантики) может быть много разных. И если приложение понимает семантику, тот может отобразить данные в более удобном для пользователя виде.
qw1
12.11.2018 00:00Контейнер стандартизирован, не более. Так можно сказать, что у документов Word, Excel и приложений Android одинаковый формат — ZIP файл, и есть универсальный браузер этого формата — WinRAR. Разве что семантика разная, но это мелочи.
vintage
12.11.2018 01:35Архиватор, файловый менеджер, редактор хмл и вьювер картинок — это замечательный пример как приложения, которые совершенно не зная про документы позволяют работать с их содержимым, не теряя данные.
qw1
12.11.2018 16:32Все под-форматы по отдельности известны, но этих знаний недостаточно, чтобы выполнить согласованное изменение набора данных (например, заменить в нужном месте текст на картинку).
Foxcool
11.11.2018 12:59+1Не совсем понятен акцент именно на веб. Не стоит ли сначала решить проблему той же фильтрации трафика или слежки, например? Или той же передачи статического контента. Это, конечно итак решается новыми системами вроде IPFS, но хотелось бы, чтобы они или более развитые аналоги были продвинуты как стандарт, нарпример.
У нас до сих пор нет меша, который бы работал из коробки на всех роутерах и ноутбуках. Нет общепринятой замены текущего ДНС и т.д.
golos.io/p2p/@foxcool/spasenie-interneta
zim32
11.11.2018 13:16Все децентрализированные сервисы не взлетят. Почему? Деньги. Ниодин крупный инвестор не будет инвестировать проект, в котором он не имеет доступ и контроль над всеми данными (слишком сейчас лакомый кусок). Без крупного инвестора все эти проекты будут занимать какую-то свою мини нишу, которой будет недостаточно для массово продвижения. Добавить сюда более скудный ф-ционал из-за сложности работы с такими данными и отсутствие каких-то явных плюсов для пользоватетя и получается картина совсем грустная.
powerman
11.11.2018 13:41Когда-то примерно то же самое говорили про опенсорс.
Даже сейчас есть вполне "взлетевшие" децентрализованные сервисы — начиная от веба, email, XMPP и заканчивая торрентами. Даже интернет как таковой — вполне себе децентрализованный сервис, если опустить некоторые нюансы вроде корневых DNS. Другое дело, что термин "децентрализованный" в отношении подхода SOLID и вышеупомянутых "сервисов" означает немного разные вещи. Непосредственный жёсткий контроль — это только один из способов делать деньги, очень грубый, прямолинейный, и он стремительно устаревает…
zim32
11.11.2018 13:53+1Не поймите не правильно сама идея мне очень нравится и я обеими руками за. Выбирать гда хранить свои данные этт круто и нужно. Но… я.не.верю уже. После примера как биткоин стал практически полностью централизован (биржи, пулы) я не знаю что должно произойти стобы в массе своей интернет стал децентрализироаанным
zim32
11.11.2018 14:37Плюс современные ютюб фейсбук инстаграмм уже могут влиять на картину мира большинства людей и как только почувствуют что пахнет жареным, они включать маховик пропаганды и все вернется наткруги своя.
qw1
11.11.2018 15:10Если будут объективные преимущества, например, как у торрентов — бесплатность, а тут — неподконтрольность модерированию со стороны сервиса, то как ни пропагандируй, никто уже не вернётся.
fn112
12.11.2018 09:12Даже сейчас есть вполне «взлетевшие» децентрализованные сервисы — начиная от веба, email, XMPP и заканчивая торрентами.
Эти сервисы или основали сам сервис, или заняли вполне доступную нишу. Однако данные пользователей — слишком лакомый кусок, который делят сейчас все в сети. С трудом верится что взлетит как хотелось бы. И слишком беззаботные пользователи, которые абсолютно не думают куда сливаются их персональные данные.
Хотя конечно, видимо он займет свою нишу
XAHTEP26
Чуть чуть недоперевели.
Plarium Автор
Спасибо за внимательность). Вставили переведенное, обновитесь.