Pull to refresh

Comments 74

Turtle is a compact way of representing RDF data, using URLs to represent subject, predicate and object.

Чуть чуть недоперевели.
Спасибо за внимательность). Вставили переведенное, обновитесь.

Обрабатывать такие данные будет невозможно. Всё равно копию приложение будет хранить для себя. В итоге в под просто будет выгружаться что-то типа бэкапа. Бэкапы и свободный формат выгрузки данных, это хорошо, но на революцию и "новый интернет" не похоже.

Я думаю, тут нужен какой-то принципиальный механизм, который позволяет загрузить приложение и прочитать данные, но не позволяет этому приложению ничего отправить «домой». Интересно, конечно, как это сделать?

В моем понимании, единственный реалистичный вариант — после открытия доступа к перс. данным приложению должен закрываться доступ в интернет.
… После чего эти данные записываются в local storage, и отправляются на сервер, как только появляется доступ к интернет.

Люди просто не будут писать приложения с использованием такой "технологии", как вы описали. Под будет не просто защищен, но и никому не нужен.

По вашей логике, open source код тоже никто не пишет. Кто-нибудь да будет. Тем более что предлагаемая схема работы не исключает возможность оплаты приложений. Первое, что приходит в голову — всякие бизнес-сервисы и онлайн бухгалтерии: люди явно предпочтут сервис, который ничего принципиально слить не может. Также, сервисы для работы с документами внутри компании.

Оплата тут ни при чем. За пример спасибо, действительно рынок может найтись. Узкоспециализированный.

И ни слова об изменении идентификации ресурсов. Во всех примерах HTTP-URI, значит простым пользователям нельзя будет легко перенести ресурс на другой домен, не поломав ссылки. А самое главное, от централизации не избавляемся из-за DNS.

Да, много вопросов и это ещё одна важная проблема при децентрализации (чуть ниже о другой). Имеется прозрачная аутентификация при перемещении по сети, каковая, к примеру, реализована в Hubzilla?
Насколько мне известно это на сегодня вообще вне поля зрения Solid. Печально.


не избавляемся из-за DNS

DNS это меньшее из зол. Вообще, вы знаете хоть один (!) децентрализованный протокол, где бы удалось реализовать отвязку от DNS или, что хуже, собственных сервисов каталогов на этапе discovery? Я пока ни одного не видел.

В ZeroNet вместо централизованной DNS для коротких имён используется блокчейн Namecoin, в котором зарегистрированы пары "sitename.bit" — <hash-адрес>.

Ага, а discovery происходит обращением к централизованному каталогу (торрент-треккеру). Спасибо, но вариант с DNS выглядит куда как более надёжным.

Ну, нет. Давно уже сделали PEX. Привязку к трекерам можно отключить, руками добавить одного пира и пошло-поехало. Да, могут быть проблемы со скачиванием новых сайтов, но они решаются.

Ну это всё о том же. "Тот пир" всё равно должен как-то находить адресатов с доселе неизвестной или изменившейся локацией. То есть в рамках самой системы проблема не решена (скорее даже не решаема).

Для поиска пиров есть DHT. Хеш пира ничем не отличается от хеша торрент-раздачи, и если перед протоколом стоит задача поиска пира (например, для прямого соединения), то у этой задачи уже есть готовое решение.

Вопрос не в том, как кого-то найти, когда узел в сети, тут решений вагон, а в первичном discovery. Да и не только. При распределённой базе возможен вариант, что хранимый локально кусок будет полностью содержать устаревшие данные и ни один из пиров будет недоступен. И вот, опять, вопрос как найти контакт.
Можно хранить всю карту сети. Но решение так себе при мало-мальски серьёзных размерах сети по ряду причин.

Первичный discovery несложно делается.

Во-первых, если сервис не скрывается (как телеграм), он может держать веб-сайт, раздающий по HTTP списки пиров (и когда пир обращается за списком, он сам попадает в него). Сервис можно сделать открытым (всего лишь 1 php-файл) и энтузиасты, у которых есть сайт, могут хостить его сами и давать адреса bootstrap-сервиса где угодно (а в клиенте можно вести список bootstrap-сервисов, пополняемый юзером).

Во-вторых, клиент перед закрытием может сохранять на диск сотню адресов известных пиров. Высока веорятность, что даже через месяц-два из этой сотни кто-нибудь, да выживет.

В-третьих, ручной ввод ip-адреса пира. Адреса можно публиковать децентрализованно где угодно, хоть в комментариях на Хабре, но благодаря первым двум пунктам к этому вряд ли придётся прибегнуть.
Кстати, вы по сути описали то, как peer discovery сделан в ZeroNet. Любой может поднять трекер с помощью встроенного плагина (дальше просто даешь остальным IP или домен). Пиры сохраняются в peers.json. Руками тоже можно добавить, но тут придется руками peers.json менять, а не через UI, это минус.
Во-первых, если сервис не скрывается (как телеграм), он может держать веб-сайт, раздающий по 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 или сервер можно сменить.

Или домен.
Короче, ни о чём.

А как насчёт таких недостатков DNS:
1. Нужно регулярно платить деньги
2. Нет анонимной регистрации

Мне вот просто лень заводить домены, потому что в ру-центр нужно будет слать сканы документов.
Можно хранить всю карту сети. Но решение так себе при мало-мальски серьёзных размерах сети по ряду причин.
Теоретически, этот вопрос решает DHT. Это хорошо масштабируемый и отказоустойчивый механизм для сохранения большого кол-ва пар ключ/значение (например, список пиров у раздачи с определённым хешем). Когда юзер входит в сеть, он отправляет свой адрес в DHT, или когда обновляет данные, тоже отправляет их в DHT, и актуальные данные быстро реплицируются.

Да, в теории и даже на практике в текущих небольших сетях оно как-то работает. Но проблема остаётся.

проблема остаётся
Какая проблема, конкретно? Найти узел в сети — не проблема.

Конечно. Используя DNS легко.

На крайний случай можно использовать перебор IP адресов. С некоторыми оптимизациями это укладывается в пару минут уже сейчас, при повсеместном использовании это будет работать за секунды.

Секунды при канале в интернет в 10 гигабит?
А как должна выглядеть полная децентрализация? Ручками вбей IP друга? В i2p, кажется, так можно, да и не только в нём.

Да, попадался такой вариант в одном из проектов. Типа сканируется QR друг у друга и тогда есть контакт.
Я к тому, что в сравнении с остальными discovery посредством DNS выглядит лучшим из возможных вариантов.
Вообще, возвращаясь к Solid очень много вопросов даже по важным деталям самой концепции, не говоря уже о технических подробностях.

В любом случае с проблемой контроля сервисов над данными необходимо что-то делать. Гугл хотя бы архивом всё отдать готов, у них там законы такие, положено. А вот вытянуть весь свой контент из бложика во вконтакте я вообще никак не могу. А, учитывая, что инструментов для удобного доступа к своим же постам, скажем, годичной давности, там вообще нет — становится и вовсе печально.

Да, но я не вижу как её решает Solid. То есть он решает её не в большей степени, чем, к примеру, нынешние HTML/HTTP. Попало в сеть, получил доступ, закэшировал и адьос амигос. Теперь ты свои данные не контролируешь.

Не совсем так. Возможность вытянуть (и удобно использовать / автоматизированно обрабатывать) данные и возможность отозвать данные — разные вещи. Проблемы сейчас и с тем, и с другим; Solid, еяпп, целится в первое, а вот возможно ли второе в принципе, да и нужно ли — мне вот лично пока не ясно, тем более, что это уже до неотличимости похоже на DRM становится.

С другой стороны, если речь идёт о моём семейном порно, DRM перестаёт казаться такой уж плохой идеей. Впрочем, с чего бы вдруг моему семейному порно вообще оказываться в сети? Разве что личка, ну так для таких особо особых кейсов есть всякие Tux, которые мало того что всегда end-to-end шифрованные, так ещё и неуловимые Джо до кучи. Хотя дефакто все пользуются телегой, причём даже без сикрет чатов, считая, что это уже достаточно секьюрно, и так, по-видимому, будет до первых серьёзных компроментаций :)

Уже давно пора надо было это сделать. Свои данные держи при себе и храни как хочешь. Я думаю взлетит. Ток не понял как будут проверять валидность подов? Провайдеры будут какой ключ давать?

А кто помешает приложению, единожды получившему доступ к данным, оставить копию у себя навечно? Впрочем, кому нужны не актуализирующиеся данные. Но вот штуки типа соответствия реального имени и емэйла всё равно придётся отдавать фактически навечно.

Спасибо за перевод, замечательная статья, есть над чем подумать. Только вот я не совсем понял концепцию


Таким образом, приложения оказались тесно связаны с данными пользователей. Создание какого-либо приложения для сети предполагает глобальное управление персональными данными.

В профессиональном плане я разрабатываю системы управления воздушным движением. Сегодня они сетевые и зачастую глобальные (учитывают погоду по всему шарику, данные по линии IATA/ICAO). Плюс терабайты данных с радаров и специализированных подсистем типа менеджеров взлета, посадки, управления терминалами и взлетно-посадочным полем. Пользовательских данных — 0. То есть это по факту не сетевое приложение?


Или вот недавно я для себя написал Андроид-приложение управления сетевым музыкальным плеером по сети. Никаких пользовательских данных, только протокол команда/ответ. Это тоже не сетевое приложение?


Для музыки я пользуюсь стриминговыми сервисами (на данный момент Deezer). Да, они сохранили мой логин. Но суммарный объем именно пользовательских данных много-много-много меньше, чем базовый контент (музыка). То есть по факту это тоже не сетевое приложение?


Или прямые покупки в интернет-магазинах. Помимо логина, у них есть еще и платежные данные и адрес. Но и этот объем много-много-много меньше, чем базовый контент (данные о товарах). Это тоже не сетевое приложение?


На первый взгляд, эта технология нужна только для того, чтобы переписать фейсбук/твиттер/VK так, чтобы не было самого фейсбук/твиттер/VK, то есть для децентрализованной социальной сети. Но ведь жизнь не ограничивается только социальными сетями?


В любом случае, еще раз спасибо за перевод, попробую по приведенным ссылкам разобраться с этими своими вопросами.

Дело не в том сколько данных, а в том, что введённые пользователем данные должны принадлежать этому пользователю. Он должен иметь право перемещать их между провайдерами, давать и забирать у приложений доступ к ним. И никакой модератор в сети не должен иметь право удалять плоды творчества любого пользователя — только отлинковать их от модерируемого им места.
Вот если вы говорите про модератора, то первый тип приложений, что приходит в голову это — форумы. Давай те попробуем на примере форумов рассмотреть сказанное вами:
1. введённые пользователем данные должны принадлежать этому пользователю
Что касается вводимых логина/пароля/профайла — если они принадлежат только пользователю, то он имеет право порождать эти сущности в любом количестве — как тогда защититься форуму от мультиаккаутинга? Если же потребовать некоего уникального идентификатора для всех профилей создаваемых пользователем, то как тогда обеспечивать его анонимность в сети?
2. Он должен иметь право перемещать их между провайдерами, давать и забирать у приложений доступ к ним.
Предположим пользователь пишет платные посты на некий форум — эти посты принадлежат форуму или ему? Если форуму, то как это соотносится с вашим 1-м утверждением и может ли пользователь тогда делать все перечисленное в вашем 2-м утверждении?
3. никакой модератор в сети не должен иметь право удалять плоды творчества любого пользователя — только отлинковать их от модерируемого им места
Если модератор форума забанит/отлинкует пользователя от форума, то пользователь естественно вправе забрать у этого форума доступ ко всем своим постам (отлинковать их в отместку например). Что тогда будет со структурой этого форума, если профиль этого пользователя и его посты упоминались-цитировались в постах других пользователей?

Как вообще быть со всей этой концепцией, если по ней — любой мой бесплатный пост на некоем форуме принадлежит только мне и я могу с ним делать все что захочу — изменять до тех пор пока мне не надоест или и вовсе удалить — причем неважно, что на это пост кто-то мог уже ответить или процитировать?
Или же все-таки эта концепция не работает и данные, вводимые пользователем таки могут принадлежать не только ему и подчиняться некоему регламенту — если это так, то чем тогда это все отличается от нынешней ситуации?

Не мешайте романтикам мечтать своим грубым прагматизмом. :)

если они принадлежат только пользователю, то он имеет право порождать эти сущности в любом количестве

Он и так и так может порождать сущности в любом количестве, если его не идентифицировать.


Если же потребовать некоего уникального идентификатора для всех профилей создаваемых пользователем, то как тогда обеспечивать его анонимность в сети?

Никак. Либо одно либо другое. Сервис волен не пускать анонимов. Вы вольны не посещать такой сервис.


Предположим пользователь пишет платные посты на некий форум — эти посты принадлежат форуму или ему?

Зависит от того какие именно неимущественные права на своё произведение продал пользователь. В любом случае я бы сделал неотчуждаемым право иметь свою копию поста. А право публикации отчуждаемым лишь до тех пор пока издатель его реализует. Перестал обеспечивать доступность н времени — право возвращается автору. Если пойти ещё дальше, то я бы и продавать неимущественные права запретил и ограничивать распространение легально опубликованных материалов.


Если модератор форума забанит/отлинкует пользователя от форума, то пользователь естественно вправе забрать у этого форума доступ ко всем своим постам (отлинковать их в отместку например).

Имеет. И форум перестанет получать уведомления об их редактировании. Форум же точно так же имеет право использовать свою копию опубликованных в свободный доступ данных на какой-то момент времени. А не опубликованных — не имеет.


я могу с ним делать все что захочу — изменять до тех пор пока мне не надоест или и вовсе удалить — причем неважно, что на это пост кто-то мог уже ответить или процитировать?

Вы и так на многих форумах можете редактировать ваши посты как угодно.


вводимые пользователем таки могут принадлежать не только ему

Разумеется не только. А я где-то утверждал, что его права не отчуждаемы?


чем тогда это все отличается от нынешней ситуации?

Эти отличия я перечислил в том сообщении, на которое вы отвечали. Или вы из тех, кто дальше первого предложения не читает и спешит написать разгромный комментарий?

Если пойти ещё дальше, то я бы и продавать неимущественные права запретил и ограничивать распространение легально опубликованных материалов.
Это убьет профессиональную журналистику.
Издатель (журнал, газета, сайт и т.п.) платит профессиональному автору (журналисту, профильному эксперту, писателю и т.п.) деньги, за то, что он создает уникальный качественный контент. Затем журнал продает этот контент читателям (платная подписка, реклама на сайте и т.п.).
Зачем издателю покупать контент, который не будет ему принадлежать? Как он будет монетезировать такой конктент?
А зачем между журналистом и читателем посредник в виде издателя в современном мире? На мой взгляд вся не личная информация должна свободно распространяться. Пока этого не будет — наживаться на информации будут издатели и другие посредники, но не авторы.
Сейчас у автора есть выбор — либо распространяй сам и решай кучу административных вопросов (издание, реклама, прием оплаты и т.п.) с этим связанных или отдай часть дохода и вопросы распространения издателю, а сам занимайся только творчеством.
Вы хотите автора этого выбора лишить, оставив только один вариант. Зачем?
Вы авторов, которые пользуются услугами издетельств спросили, хотят ли они всем этим заморачиватся чтобы заработать больше или хотят потерять в деньгах, но иметь больше времени для творчества? Кто им сейчас запрещает не пользоваться услугами посредника?
Те авторы, что меня интересуют (в основном с хабра и ютуба) чуть ли не сами доплачивают, чтобы донести свои свои материалы до аудитории. И знаете, их материалы пусть и не всегда имеют хорошее оформление, но часто интересней и полезней, чем то, что делают «профессиональные журналисты» типа Ализара и Ко. И плачу я им за это той же монетой — создавая совершенно бесплатные материалы.
А зачем между журналистом и читателем посредник в виде издателя в современном мире?
Для фильтрации информации, централизации информации (читаю сразу много в одном месте, а не держу сотню закладок на блоги по одному посту в месяц), некое количество репутации (может быть как плюсом, так и минусом), открытие новых авторов. Это для пользователя. Для автора издатель полезен тем, что у него количество просмотров будет выше (кроме случая топ звезд) просто потому что там больше одного автора, не нужно заморачиваться монетизацией и продвижением — это отдельная работа на которую вполне может не быть времени и/или желания.
На самом деле функций у издателя еще больше, но даже этого достаточно для оправдания его существования.
Так никто не спорит, что издатель-как-сервис может быть полезен. Но не издатель-как-заказчик.
1. Допустим, вы разрешили приложению доступ к своему поду. Кто помешает ему скопировать эти данные куда-то и продать, как это делается сейчас?
2. Как обязать авторов приложений хранить все данные пользователя только в его поде? Если сможете сделать это — сделайте сейчас, без всякого Solid.

Я так понимаю, что вновь предлагается привязка данных к одному конкретному месту ("поду") и с его незапланированной утратой по той или иной причине с данными можно будет прощаться? В таком случае, это не интересно, поскольку уже есть решения которые это проблему, которая является одной из важнейших в децентрализованных сетях, уже решили.

Опять никаких технических деталей, но по общим словам похоже, что Бернерс-Ли-Company мутит гибрид Disapora и ZeroNet с семантическими связями и привязкой к DNS.

Нда… Главное, нельзя сказать, что это вообще имеет смысл. Не хочу флеймить, но чем SOLID лучше ZeroNet? Вон, в зеронете есть форумы, соцсеть, вики, чаты, даже какой-то прототип онлайн-игр (disclaimer: мой) и т.д. При этом, о нем мало кто знает. Но стоит Бернерсу-Ли объявить о платформе (которая умеет гораздо меньше), как сразу начинает бурлить весь интернет… Это как?

Что нам мешает реализовать подобное в текущем Вебе на текущих технологиях путем веб-сервисов с API обменивающимися и хранящими данными в виде JSON / XML?
То есть, например, я создаю свой узел вида mysite.pp/forum_profile и ввожу туда данные, а при регистрации на форуме не ввожу свои данные, а указываю этот путь, откуда форум (естественно написанный в такой же идеологии) в риал-тайме подгружает мои данные при показе моих сообщений. Также можно хранить и сообщения, и картинки и что угодно, главное чтобы обменивающиеся данными узлы поддерживали один формат данных — протоколы то давно существуют, и с авторизацией в том числе.
Или идея в чем-то принципиально другом?
Я просто уже третью статью на эту тему на Хабре читаю и ни в одной не увидел четкого и понятного объяснения что именно, как и зачем делается, и почему именно так, а не иначе.
Это собственно оно и есть. Так, как вы описали. SOLID — попытка протолкнуть единый межсервисный апи.

SOLID не взлетит по целой куче причин:


  • SOLID ничего не даёт юзерам. Вся эта чушь про "владение" своими данными, "перемещение" своих данных, отсутствие необходимости "синхронизации" — если внимательно присмотреться, то на самом деле для юзера ничего не изменится.
  • SOLID предполагает, что сложные данные можно оторвать от приложений. На данный момент не видно никаких реальных оснований для такого оптимизма. Да, есть универсальные интерфейсы для доступа к данным (файлы, SQL, key/value, HTTP, HTML, JSON, …) но они все отличаются тем, что никак не определяют природу/формат хранимых данных, и только по этой причине они популярны и широко используются. Все попытки придумать более конкретные способы разметки данных — либо так и не стали популярны, либо крайне ограничивают функционал и по этой причине используются исключительно для переноса данных из одного приложения в другое (и, как правило, это сопровождается потерей части данных — типичный пример это перенос контактов между разными прошивками/приложениями на телефоне, при котором теряется информация о группах контактов, портится качество фоточек контактов, etc.). Приложения конкурируют не столько по UI/UX, скольку по функционалу — а для разного функционала нужные разные данные. Соответственно, данные которые для себя создали разработчики одного приложения никак не стандартизированы, а значит не могут использоваться разработчиками других приложений. Стандартизировать эти данные, в общем случае, невозможно, потому что они постоянно изменяются вместе с функционалом создавшего их приложения. Иногда, для определённых типов данных, формируется достаточно универсальное/стандартное описание — но это занимает годы и случается довольно редко. Применить это в качестве общего подхода для всех приложений и всех данных — утопия.
  • Текущее состояние технологий не предоставляет технической возможности получать данные из личных PODов сотен людей каждый раз, когда посетитель открывает страницу сайта вроде этой (статья, комменты, лайки, профили комментаторов, etc.). А это значит, что на практике все данные будут по-прежнему храниться в собственных БД приложений, даже если копия этих данных будет ещё и в PODе юзеров. Изображённое на этом слайде, на данный момент, не жизнеспособно: image

Что же тогда остаётся и зачем нужен 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-браузеры. А вот онтологий (словарей семантики) может быть много разных. И если приложение понимает семантику, тот может отобразить данные в более удобном для пользователя виде.

Контейнер стандартизирован, не более. Так можно сказать, что у документов Word, Excel и приложений Android одинаковый формат — ZIP файл, и есть универсальный браузер этого формата — WinRAR. Разве что семантика разная, но это мелочи.
Архиватор, файловый менеджер, редактор хмл и вьювер картинок — это замечательный пример как приложения, которые совершенно не зная про документы позволяют работать с их содержимым, не теряя данные.
Все под-форматы по отдельности известны, но этих знаний недостаточно, чтобы выполнить согласованное изменение набора данных (например, заменить в нужном месте текст на картинку).
Не совсем понятен акцент именно на веб. Не стоит ли сначала решить проблему той же фильтрации трафика или слежки, например? Или той же передачи статического контента. Это, конечно итак решается новыми системами вроде IPFS, но хотелось бы, чтобы они или более развитые аналоги были продвинуты как стандарт, нарпример.
У нас до сих пор нет меша, который бы работал из коробки на всех роутерах и ноутбуках. Нет общепринятой замены текущего ДНС и т.д.

golos.io/p2p/@foxcool/spasenie-interneta
Все децентрализированные сервисы не взлетят. Почему? Деньги. Ниодин крупный инвестор не будет инвестировать проект, в котором он не имеет доступ и контроль над всеми данными (слишком сейчас лакомый кусок). Без крупного инвестора все эти проекты будут занимать какую-то свою мини нишу, которой будет недостаточно для массово продвижения. Добавить сюда более скудный ф-ционал из-за сложности работы с такими данными и отсутствие каких-то явных плюсов для пользоватетя и получается картина совсем грустная.

Когда-то примерно то же самое говорили про опенсорс.


Даже сейчас есть вполне "взлетевшие" децентрализованные сервисы — начиная от веба, email, XMPP и заканчивая торрентами. Даже интернет как таковой — вполне себе децентрализованный сервис, если опустить некоторые нюансы вроде корневых DNS. Другое дело, что термин "децентрализованный" в отношении подхода SOLID и вышеупомянутых "сервисов" означает немного разные вещи. Непосредственный жёсткий контроль — это только один из способов делать деньги, очень грубый, прямолинейный, и он стремительно устаревает…

Не поймите не правильно сама идея мне очень нравится и я обеими руками за. Выбирать гда хранить свои данные этт круто и нужно. Но… я.не.верю уже. После примера как биткоин стал практически полностью централизован (биржи, пулы) я не знаю что должно произойти стобы в массе своей интернет стал децентрализироаанным

Плюс современные ютюб фейсбук инстаграмм уже могут влиять на картину мира большинства людей и как только почувствуют что пахнет жареным, они включать маховик пропаганды и все вернется наткруги своя.

Если будут объективные преимущества, например, как у торрентов — бесплатность, а тут — неподконтрольность модерированию со стороны сервиса, то как ни пропагандируй, никто уже не вернётся.
Даже сейчас есть вполне «взлетевшие» децентрализованные сервисы — начиная от веба, email, XMPP и заканчивая торрентами.

Эти сервисы или основали сам сервис, или заняли вполне доступную нишу. Однако данные пользователей — слишком лакомый кусок, который делят сейчас все в сети. С трудом верится что взлетит как хотелось бы. И слишком беззаботные пользователи, которые абсолютно не думают куда сливаются их персональные данные.
Хотя конечно, видимо он займет свою нишу
Sign up to leave a comment.