? Editing: Post:21.body Save Delete Cancel
Content changed Sign & Publish new content

Детки из детской

Мы детки ZeroNet`a
(„˃‿˂„)

Follow in NewsfeedFollowing

Latest comments:

Add new post

Title

21 hours ago · 2 min read ·
3 comments
Body
Read more

Not found

[ZeroNet заметка] Неприятная особенность в ZeroMe

on May 12, 2019 · 4 min read

Детки не молчат,

[ZeroBlog_129hHL4SQ5ZXdUKn7RAZTF3ppjW4jeYnJZ]_zerome.png (565x373)

Юный Twitter, но не для всех

Первые шажки в ZeroNet`е, начинаются с предлагаемых ресурсов. ZeroMe относится к таковым, но содержит несколько сложностей. А реализация интерфейса в ZeroNet - сгущает краски. Федерация сломана или нет?



А как работает ZeroMe :

Me.ZeroNetwork.bit - предоставляет интерфейс пользователю и связывает/мержит все доп. сущности

  1. Содержит список своих/особенных хабов, которые рекомендуются пользователям во время регистрации

В него входят :

  1. ZeroMe user registry или ZeroMe user db - база пользователей

    1. Пользователь автоматически (при регистрации) добавляется в этот список независимо от выбранного хаба

    2. В этот список могут попасть только пользователи zeroid.bit или zeroverse.bit

      В содержимом content.json за это отвечают:
      
      "cert_signers": {
          "zeroid.bit": ["1iD5ZQJMNXu43w1qLB8sfdHVKppVMduGz"],
          "zeroverse.bit": ["1HPgDoReCFtE9qy71hnp55ksBVvV1gHJLQ"]
      }
    3. Эта база содержит краткую информацию о пользователях и создаётся/обновляется где-то на удалённом сервере

      Подтверждением со стороны пользователя будет: подписанный (автоматически) им /data/userdb/публичный_ключ_пользователя/content.json . После чего: пользователь будет добавлен в базу на удалённом сервере, а его подписанный content.json будет удалён (навсегда) командой "archived": {} в /data/userdb/content.json . Это предотвратит дальнейшие проблемы по обработке новых пользователей.

      База это: /data/userdb/users.json или /data/userdb/users_[1..n].json
      
      {
          "hub": "1BLueGvui1GdbtsjcKqCf4F67uKfritG49",
          "cert_user_id": "noftsh@zeroid.bit",
          "intro": "`ZeroNet dev.`",
          "avatar": "png",
          "auth_address": "1PJm5juxa6AxizD2KeBGRxwNHfLd5vBSzD",
          "date_added": 1512330228,
          "user_name": "Nofish"
      }
    4. Поиск по пользователями в Me.ZeroNetwork.bit взаимодействует только с этим списком. Поэтому вам не удастся найти нас или Lostfile через поиск пользователей

    5. Эта база - централизованная. Очень странно, что ZeroMe нужна такая сущность, особенно странно наблюдать отсутствие kxoid.bit в списке разрешённых id провайдеров

  2. Хабы - хранилище всех данных пользователя (т.е. вас)

    Знайте, что без добавления хаба - вы не увидите сообщения пользователей с этого хаба!

    Помните - у любого хаба есть владелец, это он устанавливает правила и имеет права на удаление вашего профиля!

    1. Хранит ваш профиль с ником/статусом/и т.п.

    2. Хранит все сообщения пользователя, которые он оставил на своей странице/стене в Me.ZeroNetwork.bit

    3. Хранит комментарии и лайки

      Комментарии или лайки, которые вы оставляете у пользователя в другом хабе - будут храниться на другом хабе, которому и принадлежит этот пользователя, а не на вашем. Умрёт хаб пользователя, которому вы писали комментарии - умрут и ваши комментарии.

    4. Имеет свои правила. Которые могут касаться: размера вашего профиля (т.е. сколько всего текста вы можете написать, это касается и комментариев/лайков), какие id провайдеры принимаются и остальные правила, которые не касаются технических ограничений.

      Про id провайдеров стоит уточнить, например: мы не можем написать комментарий/поставить лайк пользователям с хаба SubHub т.к. используем id провайдер kaffie.bit , который не разрешён на этом хабе.

      ZeroNet отрапортует невнятное Ошибка при публикации контента, комментарий/лайк оставит и мы будем его видеть, но другие пользователи этого не увидят и мы не получим этот комментарий/лайк на другом устройстве.

      Причина: хаб не разрешил нам (точнее с нашим id провайдером) писать в него, но ZeroNet сохранил локальные изменения. Поэтому мы видим свои комментарии/лайки.

      А как понять с какого хаба пользователь?

      Легко, ссылки на профиль пользователя в ZeroMe выглядят так:
      /Me.ZeroNetwork.bit/?Profile/12h51ug6CcntU2aiBjhP8Ns2e5VypbWWtv/1BkWiFaG1jeXVB4PDstZhRLjDLiVsBRKW8/
      12h51ug6CcntU2aiBjhP8Ns2e5VypbWWtv - публичный ключ хаба и его адрес
      1BkWiFaG1jeXVB4PDstZhRLjDLiVsBRKW8 - публичный ключ пользователя



Для прочитавших, мы публикуем список найденных хабов !

Хабы по размеру:
KaffieHub
SunHub
OrangeHub
WhiteHub
RedHub
GreenHub
BlueHub
ChameleonHub chameleon.bit
MoonHub
GirlHub
AmethystHub
Bot Hub
ZeroHub
YellowHub
Anonymous Hub
torrents Hub
Bitcoin
IPFS Hub
Icf20's Hub
Trump 2016
YellowHub
Anarcho Capitalism
Religion
True red hub
OrangeIsTheNewBlack Hub

Хабы с языковым предпочтением:
无限额度hub 0pan.bit
Hub Español

Может противоречить вашим взглядам:
PedoHub

Последняя активность в 2016-2018 годах:
hi/ hub
The Great Dane Hub
Lime hub
GigaByteHub (100GB/user)

🍪 для ZeroMe !


12 Comments:

user_name1 day ago
Reply
Body
kids@1PoWiD2vr5mBTAq6sGDfkDBTB6Q2UesaX4on May 29, 2019
Reply

anon@kaffie.bit: Странно, специально попытался найти родамап, но на сайте проекта его нет... Значит все оставлено на усмотренее сообщества.

Его редко публикуют (везде) , но есть ToDo лист на GitHub`е. Получается, что не совсем "на сообществе". Можно разобрать первые коммиты: First release, remove not used lines from gitignore https://github.com/HelloZeroNet/ZeroNet/commit/d28e1cb4a6d3193a39431c316244e7bbd641a883 , если код написан нормально, то какой-то план есть/был.

anon@kaffie.bit: Какой процент успешных проектов, типа Гугл, приходится на все остальные, которые "не взлетели"?

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

anon@kaffie.bit: Скорость разработки несомненно является конкурентным преимуществом, но с кем конкурирует ZeroNet? Те компании и их коммерческие проекты, нацелены в первую очередь на извлечение прибыли, их нельзя сравнивать по скорости развития со свободными, держащимися исключительно на энтузиазме.

Конкурирует с временем, да и гугл не создавался под давлением: инвесторов, гонки за прибылью или конкуренции. Не успел занять нишу и начать развиваться в ней - опоздал. И вопрос не только в популярности, технологии спешат вперёд: раньше был чистый HTML, вчера JS, а сегодня ИИ направляет майнеров прямо в мозг.

anon@kaffie.biton May 28, 2019
Reply

kids@1PoWiD2vr5mBTAq6sGDfkDBTB6Q2UesaX4: Ну он был, правда на определённый промежуток. Промежуток пройден. Собственно, вы сами упомянули "4 года", вот и получается, что план содержал презентацию и дальнейшее развитие сообществом, которое будет развивать проект по потребностям.

Странно, специально попытался найти родамап, но на сайте проекта его нет... Значит все оставлено на усмотренее сообщества. Хотя, сообщество тоже необходимо как-то координировать, что бы не получилось "лебедь, рак и щука" совмещенное с "квартетом".

Мы не готовы согласиться с такой точкой зрения, лучше делать, но без костылей (так можно) . Как минимум, появится альтернативная реализация, которая сможет учесть архитектурные решения при разработке ZeroNet`а, но ещё не всё потеряно.

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

А возвращаясь к вопросу о проектировании, серебряной пули не существует, посмотрите историю гугл`а и 10-ка подобных компаний, представьте: на сколько пришлось бы отодвинуть их появление, если бы они занимались проектированием. Баланс соблюдать надо, но время играет не в пользу проектирования.

Какой процент успешных проектов, типа Гугл, приходится на все остальные, которые "не взлетели"? Скорость разработки несомненно является конкурентным преимуществом, но с кем конкурирует ZeroNet? Те компании и их коммерческие проекты, нацелены в первую очередь на извлечение прибыли, их нельзя сравнивать по скорости развития со свободными, держащимися исключительно на энтузиазме. Здесь никого не гонят вперед, устанавливая дедлайны: ни инвесторы, ни акционеры. Поэтому можно было спокойно, без спешки подумать: что делать и как, и что из всего этого должно получится.

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

kids@1PoWiD2vr5mBTAq6sGDfkDBTB6Q2UesaX4on May 28, 2019
Reply

anon@kaffie.bit: Все же должен быть разумный предел понимания - как это все должно работать. Причем, не абстрактно, а конкретно.

Нас с детства учат оперировать абстракциями, а теперь конкретно? Кхе-кхе, ах да...

Ну он был, правда на определённый промежуток. Промежуток пройден. Собственно, вы сами упомянули "4 года", вот и получается, что план содержал презентацию и дальнейшее развитие сообществом, которое будет развивать проект по потребностям.

anon@kaffie.bit: Порой лучше вообще ничего не делать, отказавшись от такого проекта на ранней стадии, пока не вложено столько сил в сам код, с которым будет жалко расставаться, что повлечет вторичную волну костылинга

Мы не готовы согласиться с такой точкой зрения, лучше делать, но без костылей (так можно) . Как минимум, появится альтернативная реализация, которая сможет учесть архитектурные решения при разработке ZeroNet`а, но ещё не всё потеряно.

А возвращаясь к вопросу о проектировании, серебряной пули не существует, посмотрите историю гугл`а и 10-ка подобных компаний, представьте: на сколько пришлось бы отодвинуть их появление, если бы они занимались проектированием. Баланс соблюдать надо, но время играет не в пользу проектирования.

anon@kaffie.biton May 27, 2019
Reply

kids@1PoWiD2vr5mBTAq6sGDfkDBTB6Q2UesaX4: Это хороший посыл, но он - не работает. Существует краткий план по основному функционалу и примерный способ реализации. Если бы было возможно проработать (любую) идею до чёткого понимания в головах у разработчиков, то наблюдали бы - идеальный мир. Анн нет, идеального мира, даже близко нету. Начальный план существовал (мы надеемся), но подход к разработке с сообществом - плохо совместим с таким планом.

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

Мы хотели сказать, что можно всю жизнь потратить на планирование, а в итоге: жизнь закончилась и реализация не наступила. Невозможно всё просчитать или спланировать, уже давно всё упирается в время. Но оправдывать разработчиков - не будем (▼ー▼)Ψ

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

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

kids@1PoWiD2vr5mBTAq6sGDfkDBTB6Q2UesaX4on May 27, 2019
Reply

anon@kaffie.bit: Следует различать: качество проработки идеи, положенной в основу проекта и качество реализации этой идеи в коде. В идеале, перед написанием первой строчки кода в головах у разрабов должно бычь четкое понимание - что они будут делать и как.

Это хороший посыл, но он - не работает. Существует краткий план по основному функционалу и примерный способ реализации. Если бы было возможно проработать (любую) идею до чёткого понимания в головах у разработчиков, то наблюдали бы - идеальный мир. Анн нет, идеального мира, даже близко нету. Начальный план существовал (мы надеемся), но подход к разработке с сообществом - плохо совместим с таким планом.
Мы хотели сказать, что можно всю жизнь потратить на планирование, а в итоге: жизнь закончилась и реализация не наступила. Невозможно всё просчитать или спланировать, уже давно всё упирается в время. Но оправдывать разработчиков - не будем (▼ー▼)Ψ

anon@kaffie.biton May 26, 2019
Reply

kids@1PoWiD2vr5mBTAq6sGDfkDBTB6Q2UesaX4: Вы иронизируете, ведь это не в их интересах. Попробуйте и вас поддержат („◕‿˂„)〜☆ . Но недостаточно вывалить список хотелок, надо разжевать и привести use case`ы, тогда не отвертятся (▼ー▼)Ψ

Здесь не тот случай. Для того что бы реализовать данные хотелки придется переделать все с нуля. Они не укладываются в использованную концепцию, которую разрабы приняли исходя из неких собственных соображений.

Вряд ли была цель: оправдать костыли. Учитывая скорость развития технологий/и т.д. - лучший подход. Всегда есть шанс, что прототип превратится во что-то большее, ещё рано сгущать краски, разработка идёт и проект жив.

Жив, то он жив, только развивается в непонятном направлении. По крайней мере, не понятном лично мне. Если проект, который задумывался, как массовый, на протяжении 4-х лет сущесвования так и не приобрел популярность, а наоборот испытывает спад, значит самое время задуматься о причине происходящего.

Где-то была хорошая цитата по этому поводу, но мы не помним, суть её примерно такая: "Сразу сделать идеально, это слишком самонадеянно" и мы согласны с такой позицией. Но это не значит, что можно делать: тяп-ляп и готово.

Следует различать: качество проработки идеи, положенной в основу проекта и качество реализации этой идеи в коде. В идеале, перед написанием первой строчки кода в головах у разрабов должно бычь четкое понимание - что они будут делать и как. Если этого нет, то вероятность успеха резко падает. Даже идеальнейший код не спасет от ошибок проектирования. Если следовать паттернам: "разберемся на месте", "проблемы следует решать по мере их возникновения" - всегда будут костыли.

По мере ознакомления с проектом начинает складываться впечатление, что разрабы двигаются в направлении "куда кривая выведет". Как федеративные сервисы появились в децентрализованной сети? Их проще было прикрутить. Почему нет DHT? Оно и так работает. Что за фигня со статическими сайтами? Мы продвигаем свои "зайты", до остального - нет дела. Почему такая неудобная и бесполезная админка? Она красиво и модно выглядит. И так далее.

kids@1PoWiD2vr5mBTAq6sGDfkDBTB6Q2UesaX4on May 25, 2019
Reply

anon@kaffie.bit: Высказанные идеи не укладываются в концепцию ZeroNet , в связи с чем их бесполезно озвучивать в контексте предложений и пожеланий ее дальнейшего развития.
...
Боюсь даже предствить, куда меня пошлют разрабы, и что предложат сделать по прибытии в место назначения, если я озвучу мой скромный список пожеланий? :)))

Вы иронизируете, ведь это не в их интересах. Попробуйте и вас поддержат („◕‿˂„)〜☆ . Но недостаточно вывалить список хотелок, надо разжевать и привести use case`ы, тогда не отвертятся (▼ー▼)Ψ

kids@1PoWiD2vr5mBTAq6sGDfkDBTB6Q2UesaX4: ZeroMe и подобное - демонстрация возможностей ZeroNet`а, вряд ли стояла задача по созданию полноценного решения.

anon@kaffie.bit: Такой подход оправдывает и костыли и подпорки, но в конечном итоге приводит к краху - проект навсегда остается демонстрационным прототипом, непригодным к повседневному использованию.

Вряд ли была цель: оправдать костыли. Учитывая скорость развития технологий/и т.д. - лучший подход. Всегда есть шанс, что прототип превратится во что-то большее, ещё рано сгущать краски, разработка идёт и проект жив.

Где-то была хорошая цитата по этому поводу, но мы не помним, суть её примерно такая: "Сразу сделать идеально, это слишком самонадеянно" и мы согласны с такой позицией. Но это не значит, что можно делать: тяп-ляп и готово.

anon@kaffie.biton May 25, 2019
Reply

kids@1PoWiD2vr5mBTAq6sGDfkDBTB6Q2UesaX4: Если нужна версионность - git (что-то подобное уже было) , независимый - IPFS? Это всё витает в воздухе и понятно, попробуйте спросить разработчиков. Или предложите свои идеи, можно в рамках [en]ZeroTalk провести обсуждение.

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

ZeroMe и подобное - демонстрация возможностей ZeroNet`а, вряд ли стояла задача по созданию полноценного решения.

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

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

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

  1. Никаких торрентов - изначально DHT
  2. Универсальный транспорт: i2p, tor, clearnet
  3. Никакой зависимости core-функционала от федеративных сервисов.
  4. Отдельный режим просмотра с полным отключением JS, в которм не будут загружаться сайты требующие его задействования.

Боюсь даже предствить, куда меня пошлют разрабы, и что предложат сделать по прибытии в место назначения, если я озвучу мой скромный список пожеланий? :)))

kids@1PoWiD2vr5mBTAq6sGDfkDBTB6Q2UesaX4on May 25, 2019
Reply

anon@kaffie.bit: Каждое сообщение, пост, страница, картинка должны быть атомарными независимыми сетевыми объектами ... Хотя, в таком случае придется управлять версиями.

Если нужна версионность - git (что-то подобное уже было) , независимый - IPFS? Это всё витает в воздухе и понятно, попробуйте спросить разработчиков. Или предложите свои идеи, можно в рамках [en]ZeroTalk провести обсуждение.

anon@kaffie.bit: разрабы решили удариться в федеративность, намеренно создавая точки проблем и отказов?

Скорее всего, её было легче реализовать, особенно после введения мержей. Если проследить активность на github`е в рамках ZeroNet`а, то её больше в back-end`е (core/api/etc) и меньше в front-end`е (web часть). Надо ждать хороших веб-разработчиков. ZeroMe и подобное - демонстрация возможностей ZeroNet`а, вряд ли стояла задача по созданию полноценного решения.

anon@kaffie.bit: Увы. Очередная замечательная технология губится прямо на глазах топорной реализацией. Разрабы сами не знают чего хотят.

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

anon@kaffie.biton May 24, 2019
Reply

kids@1PoWiD2vr5mBTAq6sGDfkDBTB6Q2UesaX4:
удаление всего контента через content.json или подобным способом

Крайне веселый сценарий в случае утечки приватного ключа у владельца популярного хаба.

п.с. Хранение всех хабов - не гарантирует сохранность сообщений

А вот это - архитектурный фейл. Каждое сообщение, пост, страница, картинка должны быть атомарными независимыми сетевыми объектами и иметь атрибуты: идентификатор, паблишер, дата публикации, уникальный URL в локальном хринилище и подпись паблишера. Только при таких условиях ничего из однажды опубликованного не пропадет - случайно или злонамеренно. Хотя, в таком случае придется управлять версиями.

Ваш пример, вариант хорошей федерации, точнее децентрализации.

Просто я удивлен: для чего имея в своем распоряжении квазидецентрализованную сеть (до момента пока не устранена зависимость от доступности трекеров) разрабы решили удариться в федеративность, намеренно создавая точки проблем и отказов?

Столкнёмся с проблемами поиска как в RetroShare и дублированием коннекта, а решения этого в ZeroNet`е мы не нашли.

Хранить на каждой ноде обновляемый реестр существующих сетевых адресов, на подобии списка рутеров в i2p. Кроме того, в данном списке можно хранить информацию о доступности (распространенности) - количестве копий каждого сайта. Будет автоматически обновляемый рейтинг популярности.
Если кто-то захочет сделать поисковик, то просто устроит сканирование адресов из данного списка. Кроме того можно будет создать полную копию контента сети.

Но больше всего похоже, что ZeroNet хочет усидеть на двух стульях сразу, позиционирует себя как децентрализованная веб сеть (wiki: decentralized web-like network или Peer-to-peer web hosting) и реализует федерацию. Концовка при таком подходе - туманна...

Увы. Очередная замечательная технология губится прямо на глазах топорной реализацией. Разрабы сами не знают чего хотят.

kids@1PoWiD2vr5mBTAq6sGDfkDBTB6Q2UesaX4on May 24, 2019
Reply

anon@kaffie.bit: Действительно, не продуманно, не логично и самое плохое - имеется риск потерять свои посты, или придется локально хранить актуальные копии всех хабов... По идеи, все свое надо хранить у себя: все сообщения, комментарии и картинки - как свои, так и всех своих "followed users", а так же все лайканные посты.

Сразу определимся, федеративный сервер - хаб. А смерть хаба - удаление всего контента через content.json или подобным способом.
п.с. Хранение всех хабов - не гарантирует сохранность сообщений, типичный пример.

Ваш пример, вариант хорошей федерации, точнее децентрализации. Но федерация работает иначе, например в matrix она реализована похожим способом. Но там есть хоть какая-то гарантия, что при смерти хаба, сообщения с него - не испарятся. Происходит это, благодаря хранению локальной копии (условно) каждым хабом и владелец хаба не может сказать: "Эй, а ну удалил всё!111". Ну это в теории конечно, разобраться в matrix намного сложнее, а учитывая его популярность и отсутствие федерации через tor, нет смысла.

anon@kaffie.bit: Наверное разрабы побоялись, что без агрегаторов, которыми выступают "хабы" приложение будет плохо масштабироваться и станет тупить при большой активности.

Основным агрегатором выступает ZeroMe, это он мержит все хабы. Если перенести хранение копии на плечи хаба и сделать hub per user, то получим децентрализацию. Столкнёмся с проблемами поиска как в RetroShare и дублированием коннекта, а решения этого в ZeroNet`е мы не нашли. Возможно получится заморочиться через опциональные файлы, но это плохо представляется. Да и сказать: "Хей, у нас есть сообщения с мёртвого хаба, забирай!" без подводных камней - проблематично. Ещё интерфейс ZeroHello с hub per user не готов к такому.

Но больше всего похоже, что ZeroNet хочет усидеть на двух стульях сразу, позиционирует себя как децентрализованная веб сеть (wiki: decentralized web-like network или Peer-to-peer web hosting) и реализует федерацию. Концовка при таком подходе - туманна..

anon@kaffie.biton May 22, 2019
Reply

Комментарии или лайки, которые вы оставляете у пользователя в другом хабе - будут храниться на другом хабе, которому и принадлежит этот пользователя, а не на вашем. Умрёт хаб пользователя, которому вы писали комментарии - умрут и ваши комментарии.

Действительно, не продуманно, не логично и самое плохое - имеется риск потерять свои посты, или придется локально хранить актуальные копии всех хабов... По идеи, все свое надо хранить у себя: все сообщения, комментарии и картинки - как свои, так и всех своих "followed users", а так же все лайканные посты.

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

This page is a snapshot of ZeroNet. Start your own ZeroNet for complete experience. Learn More