История изменений

Можно оставить этот вопрос за скобками, потому что транспорт куда меньшая проблема, чем всё остальное. Лучше всего, если пользователю не придётся вообще ничего устанавливать, так-то говоря.

Я имел в виду скорее в целом подход «сделать всё академически правильно», не ограничиваясь только транспортным уровнем. Делая всё академически правильно, можно либо вообще не релизнуться, либо получить… телеграм.

Чтобы была возможность каким-то одним общим способом получить контент с определённого сайта и отобразить его в разных UI, возможно, даже от разных разработчиков.

Там же RESTful API. Делать клиенты можно уже сейчас.

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

Я поэтому и говорю о спокойном масштабировании обратно вниз до федерации, потому что можно уже сейчас начинать делать обычный веб-сайт с беком на PHP, NodeJS или чем угодно, который будет прокладкой между обычной клиент-серверной архитектурой и пиринговой сетью.

И, наверное, правильно делают. Нашей задачей является малой кровью объяснить возможные проблемы и дать простой способ посмотреть на альтернативы. P2P-решения часто ломают об колено весь опыт пользователя, что иногда даже оправданно.

/тяжкий вздох/

О да, торренты так сильно ломали опыт об колено… что аж dht-сеть торрента самая большая в мире.

А уж смартфоны-то как при своём появлении ломали опыт…

Что за странный консерватизм?

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

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

Но это и хорошо, потому что наконец-то возвращает пользователю окончательный и осязаемый контроль над его данными. Физический ключ это реальный ключ как ключи от квартиры. Это не эфемерная аутентификация по паролю, которую 99% пользователей не понимает и использует в качестве пароля кличку своей собаки.

Ты сам напросился на буквоедство, но в ActivityPub нет UI, хех.

Ну его и в ZeroNet нет. Ты понимаешь меня.

Уточка говорит зря-зря.

Уточка не так говорит. :duck:

Сравнивая с Ethereum, в нём реализовано то, о чём ранее упоминалось: мы можем обратиться к любой транзакции и смарт-контракту в блокчейне, вытащить оттуда данные и отобразить их произвольным образом. Как пользователю, нам необязательно иметь блокчейн у себя на компьютере — этим может заняться какой-нибудь внешний провайдер. Этот же провайдер может оказывать какую-нибудь полезную услугу в виде веб-сервиса — обычного веб-сайта, на который мы заходим с обычного веб-браузера или мобильного приложения. При этом взаимодействие с блокчейном может быть как полностью со стороны провайдера и без нашего контроля, так и полностью с нашей стороны, запуская DApp у себя на компьютере и логинясь с помощью нашего кошелька/секретного ключа — при этом блокчейн всё ещё необязательно хранить у себя на компьютере, мы можем быть тонким клиентом.

Не вижу архитектурной разницы.

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

У пользователя должна быть возможность хранить все эти тысячи постов и картинок. И должна быть возможность не хранить.

Сейчас у нас либо так, либо так. Либо ты тонкий клиент, который ничего не решает и не умеет, либо ты сам хранишь зеркало всей соцсети.

Но второй вариант можно плавно урезать до первого. А первый до второго поднять можно только «изобретением» P2P.

Это было первое.

Второе. На самом деле нам не нужен снимок всей сети точно так же как нам не нужны все узлы федерации разом. Нам нужен тематический контент. Если я подписан на группу «PHP Hater Handbook», а группа байкеров мне не интересна, то я посты байкеров и не храню.

Сами же на сайте писали про выгоду малых сообществ по сравнению с глобальным фидом в крупных соцсетях. Вот это то же самое, только более гибкое. Теперь тебе не обязательно менять ID аккаунта, чтобы быть в нескольких «домашних» группах.

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

Нет, не лишаемся. Синхронизация автоматическая. Серьёзно? Ты говоришь об отсутствии синхронизации в сети, суть которой основана на тотальной синхронизации? Сразу после того, как сама пишешь, что для создания соцсети синхронизации СЛИШКОМ МНОГО?

Мультидевайс не проблема, проблема мультиключ. Решаемая где-то за 4-5 дней кодинга на питоне, я гарантирую это.

Опять же, полнотекстовый поиск по истории где-то на год-второй назад.

У меня работает полнотекстовый поиск по всем 700 сайтам. Тупит, конечно. Но там притимивный sqlite под капотом, размещенный на ноутбучном HDD. Всё это решаемо техниками разного рода оптимизаций как по месту, так и введением отдельных поисковых серверов. Самое главное, что ты не обязана ДОВЕРЯТЬ такому поисковому серверу. И ты можешь СМЕНИТЬ его на тот, которому доверяешь. А если никому не доверяешь — просто включаешь полнотекстовый поиск и ждёшь по 3-5 минут, пока пир самостоятельно всё прошуршит.

Можно оставить этот вопрос за скобками, потому что транспорт куда меньшая проблема, чем всё остальное. Лучше всего, если пользователю не придётся вообще ничего устанавливать, так-то говоря.

Я имел в виду скорее в целом подход «сделать всё академически правильно», не ограничиваясь только транспортным уровнем. Делая всё академически правильно, можно либо вообще не релизнуться, либо получить… телеграм.

Чтобы была возможность каким-то одним общим способом получить контент с определённого сайта и отобразить его в разных UI, возможно, даже от разных разработчиков.

Там же RESTful API. Делать клиенты можно уже сейчас.

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

Я поэтому и говорю о спокойном масштабировании обратно вниз до федерации, потому что можно уже сейчас начинать делать обычный веб-сайт с беком на PHP, NodeJS или чем угодно, который будет прокладкой между обычной клиент-серверной архитектурой и пиринговой сетью.

И, наверное, правильно делают. Нашей задачей является малой кровью объяснить возможные проблемы и дать простой способ посмотреть на альтернативы. P2P-решения часто ломают об колено весь опыт пользователя, что иногда даже оправданно.

/тяжкий вздох/

О да, торренты так сильно ломали опыт об колено… что аж dht-сеть торрента самая большая в мире.

А уж смартфоны-то как при своём появлении ломали опыт…

Что за странный консерватизм?

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

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

Но это и хорошо, потому что наконец-то возвращает пользователю окончательный и осязаемый контроль над его данными. Физический ключ это реальный ключ как ключи от квартиры. Это не эфемерная аутентификация по паролю, которую 99% пользователей не понимает и использует в качестве пароля кличку своей собаки.

Ты сам напросился на буквоедство, но в ActivityPub нет UI, хех.

Ну его и в ZeroNet нет. Ты понимаешь меня.

Уточка говорит зря-зря.

Уточка не так говорит. :duck:

Сравнивая с Ethereum, в нём реализовано то, о чём ранее упоминалось: мы можем обратиться к любой транзакции и смарт-контракту в блокчейне, вытащить оттуда данные и отобразить их произвольным образом. Как пользователю, нам необязательно иметь блокчейн у себя на компьютере — этим может заняться какой-нибудь внешний провайдер. Этот же провайдер может оказывать какую-нибудь полезную услугу в виде веб-сервиса — обычного веб-сайта, на который мы заходим с обычного веб-браузера или мобильного приложения. При этом взаимодействие с блокчейном может быть как полностью со стороны провайдера и без нашего контроля, так и полностью с нашей стороны, запуская DApp у себя на компьютере и логинясь с помощью нашего кошелька/секретного ключа — при этом блокчейн всё ещё необязательно хранить у себя на компьютере, мы можем быть тонким клиентом.

Не вижу архитектурной разницы.

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

У пользователя должнга быть возможность хранить все эти тысячи постов и картинок. И должна быть возможность не хранить.

Сейчас у нас либо так, либо так. Либо ты тонкий клиент, который ничего не решает и не умеет, либо ты сам хранишь зеркало всей соцсети.

Но второй вариант можно плавно урезать до первого. А первый до второго поднять можно только «изобретением» P2P.

Это было первое.

Второе. На самом деле нам не нужен снимок всей сети точно так же как нам не нужны все узлы федерации разом. Нам нужен тематический контент. Если я подписан на группу «PHP Hater Handbook», а группа байкеров мне не интересна, то я посты байкеров и не храню.

Сами же на сайте писали про выгоду малых сообществ по сравнению с глобальным фидом в крупных соцсетях. Вот это то же самое, только более гибкое. Теперь тебе не обязательно менять ID аккаунта, чтобы быть в нескольких «домашних» группах.

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

Нет, не лишаемся. Синхронизация автоматическая. Серьёзно? Ты говоришь об отсутствии синхронизации в сети, суть которой основана на тотальной синхронизации? Сразу после того, как сама пишешь, что для создания соцсети синхронизации СЛИШКОМ МНОГО?

Мультидевайс не проблема, проблема мультиключ. Решаемая где-то за 4-5 дней кодинга на питоне, я гарантирую это.

Опять же, полнотекстовый поиск по истории где-то на год-второй назад.

У меня работает полнотекстовый поиск по всем 700 сайтам. Тупит, конечно. Но там притимивный sqlite под капотом, размещенный на ноутбучном HDD. Всё это решаемо техниками разного рода оптимизаций как по месту, так и введением отдельных поисковых серверов. Самое главное, что ты не обязана ДОВЕРЯТЬ такому поисковому серверу. И ты можешь СМЕНИТЬ его на тот, которому доверяешь. А если никому не доверяешь — просто включаешь полнотекстовый поиск и ждёшь по 3-5 минут, пока пир самостоятельно всё прошуршит.

Можно оставить этот вопрос за скобками, потому что транспорт куда меньшая проблема, чем всё остальное. Лучше всего, если пользователю не придётся вообще ничего устанавливать, так-то говоря.

Я имел в виду скорее в целом подход «сделать всё академически правильно», не ограничиваясь только транспортным уровнем. Делая всё академически правильно, можно либо вообще не релизнуться, либо получить… телеграм.

Чтобы была возможность каким-то одним общим способом получить контент с определённого сайта и отобразить его в разных UI, возможно, даже от разных разработчиков.

Там же RESTful API. Делать клиенты можно уже сейчас.

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

Я поэтому и говорю о спокойном масштабировании обратно вниз до федерации, потому что можно уже сейчас начинать делать обычный веб-сайт с беком на PHP, NodeJS или чем угодно, который будет прокладкой между обычной клиент-серверной архитектурой и пиринговой сетью.

И, наверное, правильно делают. Нашей задачей является малой кровью объяснить возможные проблемы и дать простой способ посмотреть на альтернативы. P2P-решения часто ломают об колено весь опыт пользователя, что иногда даже оправданно.

/тяжкий вздох/

О да, торренты так сильно ломали опыт об колено… что аж dht-сеть торрента самая большая в мире.

А уж смартфоны-то как при своём появлении ломали опыт…

Что за странный консерватизм?

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

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

Но это и хорошо, потому что наконец-то возвращает пользователю окончательный и осязаемый контроль над его данными. Физический ключ это реальный ключ как ключи от квартиры. Это не эфемерная аутентификация по паролю, которую 99% пользователей не понимает и использует в качестве пароля кличку своей собаки.

Ты сам напросился на буквоедство, но в ActivityPub нет UI, хех.

Ну его и в ZeroNet нет. Ты понимаешь меня.

Уточка говорит зря-зря.

Уточка не так говорит. :duck:

Сравнивая с Ethereum, в нём реализовано то, о чём ранее упоминалось: мы можем обратиться к любой транзакции и смарт-контракту в блокчейне, вытащить оттуда данные и отобразить их произвольным образом. Как пользователю, нам необязательно иметь блокчейн у себя на компьютере — этим может заняться какой-нибудь внешний провайдер. Этот же провайдер может оказывать какую-нибудь полезную услугу в виде веб-сервиса — обычного веб-сайта, на который мы заходим с обычного веб-браузера или мобильного приложения. При этом взаимодействие с блокчейном может быть как полностью со стороны провайдера и без нашего контроля, так и полностью с нашей стороны, запуская DApp у себя на компьютере и логинясь с помощью нашего кошелька/секретного ключа — при этом блокчейн всё ещё необязательно хранить у себя на компьютере, мы можем быть тонким клиентом.

Не вижу архитектурной разницы.

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

У пользователя должнга быть возможность хранить все эти тысячи постов и картинок. И должна быть возможнгость не хранить.

Сейчас у нас либо так, либо так. Либо ты тонкий клиент, который ничего не решает и не умеет, либо ты сам хранишь зеркало всей соцсети.

Но второй вариант можно плавно урезать до первого. А первый до второго поднять можно только «изобретением» P2P.

Это было первое.

Второе. На самом деле нам не нужен снимок всей сети точно так же как нам не нужны все узлы федерации разом. Нам нужен тематический контент. Если я подписан на группу «PHP Hater Handbook», а группа байкеров мне не интересна, то я посты байкеров и не храню.

Сами же на сайте писали про выгоду малых сообществ по сравнению с глобальным фидом в крупных соцсетях. Вот это то же самое, только более гибкое. Теперь тебе не обяхательно менять ID аккакнта, чтобы быть в нескольких «домашних» группах.

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

Нет, не лишаемся. Синхронизация автоматическая. Серьёзно? Ты говоришь об отсутствии синхронизации в сети, суть которой основана на тотальной синхронизации? Сразу после того, как сама пишешь, что для создания соцсети синхронизации СЛИШКОМ МНОГО?

Мультидевайс не проблема, проблема мультиключ. Решаемая где-то за 4-5 дней кодинга на питоне, я гарантирую это.

Опять же, полнотекстовый поиск по истории где-то на год-второй назад.

У меня работает полнотекстовый поиск по всем 700 сайтам. Тупит, конечно. Но там притимивный sqlite под капотом, размещенный на ноутбучном HDD. Всё это решаемо техниками разного рода оптимизаций как по месту, так и введением отдельных поисковых серверов. Самое главное, что ты не обязана ДОВЕРЯТЬ такому поисковому серверу. И ты можешь СМЕНИТЬ его на тот, которому доверяешь. А если никому не доверяешь — просто включаешь полнотекстовый поиск и ждёшь по 3-5 минут, пока пир самостоятельно всё прошуршит.

Можно оставить этот вопрос за скобками, потому что транспорт куда меньшая проблема, чем всё остальное. Лучше всего, если пользователю не придётся вообще ничего устанавливать, так-то говоря.

Я имел в виду скорее в целом подход «сделать всё академически правильно», не ограничиваясь только транспортным уровнем. Делая всё академически правильно, можно либо вообще не релизнуться, либо получить… телеграм.

Чтобы была возможность каким-то одним общим способом получить контент с определённого сайта и отобразить его в разных UI, возможно, даже от разных разработчиков.

Там же RESTful API. Делать клиенты можно уже сейчас.

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

Я поэтому и говорю о спокойном масштабировании обратно вниз до федерации, потому что можно уже сейчас начинать делать обычный веб-сайт с беком на PHP, NodeJS или чем угодно, который будет прокладкой между обычной клиент-серверной архитектурой и пиринговой сетью.

И, наверное, правильно делают. Нашей задачей является малой кровью объяснить возможные проблемы и дать простой способ посмотреть на альтернативы. P2P-решения часто ломают об колено весь опыт пользователя, что иногда даже оправданно.

/тяжкий вздох/

О да, торренты так сильно ломали опыт об колено… что аж dht-сеть торрента самая большая в мире.

А уж смартфоны-то как при своём появлении ломали опыт…

Что за странный консерватизм?

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

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

Но это и хорошо, потому что наконец-то возвращает пользователю окончательный и осязаемый контроль над его данными. Физический ключ это реальный ключ как ключи от квартиры. Это не эфемерная аутентификация по паролю, которую 99% пользователей не понимает и использует в качестве пароля кличку своей собаки.

Ты сам напросился на буквоедство, но в ActivityPub нет UI, хех.

Ну его и в ZeroNet нет. Ты понимаешь меня.

Уточка говорит зря-зря.

Уточка не так говорит. :duck:

Сравнивая с Ethereum, в нём реализовано то, о чём ранее упоминалось: мы можем обратиться к любой транзакции и смарт-контракту в блокчейне, вытащить оттуда данные и отобразить их произвольным образом. Как пользователю, нам необязательно иметь блокчейн у себя на компьютере — этим может заняться какой-нибудь внешний провайдер. Этот же провайдер может оказывать какую-нибудь полезную услугу в виде веб-сервиса — обычного веб-сайта, на который мы заходим с обычного веб-браузера или мобильного приложения. При этом взаимодействие с блокчейном может быть как полностью со стороны провайдера и без нашего контроля, так и полностью с нашей стороны, запуская DApp у себя на компьютере и логинясь с помощью нашего кошелька/секретного ключа — при этом блокчейн всё ещё необязательно хранить у себя на компьютере, мы можем быть тонким клиентом.

Не вижу архитектурной разницы.

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

У пользователя должнга быть возможность хранить все эти тысячи постов и картинок. И должна быть возможнгость не хранить.

Сейчас у нас либо так, либо так. Либо ты тонкий клиент, который ничего не решает и не умеет, либо ты сам хранишь зеркало всей соцсети.

Но второй вариант можно плавно урезать до первого. А первый до второго поднять можно только «изобретением» P2P.

Это было первое.

Второе. На самом деле нам не нужен снимок всей сети точно так же как нам не нужны все узлы федерации разом. Нам нужен тематический контент. Если я подписан на группу «PHP Hater Handbook», а группа байкеров мне не интересна, то я посты байкеров и не храню.

Сами же на сайте писали про выгоду малых сообществ по сравнению с глобальным фидом в крупных соцсетях. Вот это то же самое, только более гибкое. Теперь тебе не обяхательно менять ID аккакнта, чтобы быть в нескольких «домашних» группах.

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

Нет, не лишаемся. Синхронизация автоматическая. Серьёзно? Ты говоришь об отсутствии синхронизации в сети, суть которой основана на тотальной синхронизации? Сразу после того, как сама пишешь, что для создания соцсети синхронизации СЛИШКОМ МНОГО?

Мультидевайс не проблема, проблема мультиключ. Решаемая где-то за 4-5 дней кодинга на питоне, я гарантирую это.

Опять же, полнотекстовый поиск по истории где-то на год-второй назад.

У меня работает полнотекстовый поиск по всем 700 сайтам. Тупит, конечно. Но там притимивный sqlite под капотом, размещенный на ноутбучном HDD. Всё это решаемо техниками разного рода оптимизаций как по месту, так и введением отдельных поисковых серверов. Самое главное, что ты не обязана ДОВЕРЯТЬ такому поисковому серверу. И ты можешь СМЕНИТЬ его на тот, которому доверяешь. А если никому не доверяешь — просто включаешь полнотекстовый поиск и ждёшь по 3-5 минут, пока пир самостоятельно всё прошуршит.