Metta grabber (uvvy)

(Disclaimer: здесь и далее читать как «для меня», «в моём сегодняшнем понимании» и т.п.)

Metta is about belongings.

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

Метта для меня выглядит не как новый способ «работать» — взаимодействовать — с материалом. Метта для меня — новый способ не терять нажитое, держать его под рукой, не заботиться о бренном. (Это ни плохо, ни хорошо, а product boundaries)

Omnia metta mecum porto.

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

Спасти и сохранить

Я очень много вынужден думать (и делать) о бренном, что может мне когда-нибудь пригодиться. Я организую себе сложный инструментарий избыточного дублирования всего, что я произвожу (сложнее всего с видео). Я пытаюсь не потерять всё, что мне важно — начиная с вдохновляющей музыки и заканчивая книгами. Я уж не говорю о том, чтобы не терять там статьи, письма и прочий преходящий скарб, который мне в 99,99% случаев не понадобится, но именно из-за 0,01% я порой таскаю его с собой.

И вот я чего бы хотел. Я бы хотел инструмент, который перекладывает весь мой скарб из локальных хранилищ и из чужого интернета в метта-сеть. И чтобы эта метта-сеть была так устроена, чтобы я её мог легко развернуть на машинах в разных хостингах, легко сбрасывать в Glacier — чтобы ничего из неё не потерялось for sure.

Найти и доставить

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

Некоторый софт, который будет при 404 в браузере находить слепок страницы в метта-нете. Который при каком-то достаточно простом запросе сможет достать и доставить на устройство (например, в телефон) документ, который когда-то я в почте видел, который мне когда-то в почте «запомнился». Который граббер переложил из почты в метта-сеть «на всякий случай».

Меховая логика

Случаи бывают всякие и, видимо, граббер как-то умно должен складывать всё в метта-сеть. Видео не все, что встречает, а которые я посмотрел хоть сколько-то или отложил. Документы в почте точно не все! Страницы посещённые тоже не все, а какие-то особенные. Которые я кому-то пересылал, например. Которые мне присылали.

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

От пользователя

Скажу с позиции пользователя.

Я бы боялся, лично, что в какое-то хранилище случайно уйдёт то, чего бы я не хотел, чтобы ушло. И это даже важнее чем нести свои over9000 документов с собой. И, конечно же, спрашивать меня каждый раз тоже не вариант. Я должен быть уверен, что я всегда знаю, что там. Если это будут миллионы отрезков документов, то степень доверия уменьшится, по крайней мере, если они не будут чётко структурированными и доступны со скоростью света.

Доверие к облакам на данный момент у многих отсутствует, поэтому если делать что-то такое, то пользователь должен иметь возможность всегда абсолютно чётко знать, что находится в облаке, без связи в джунглях или африке, воспринимать его как физический диск его текущего девайса (там процент доверия 95%), копия которого есть где-то в не менее надёжном месте

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

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

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

Ну я с позиции "поциента" которому непонятно что там внутри, сколько ему ни объясняй технические тонкости — он доверием не проникнется. Он будет верить только тому, что видит наглядно. Я шарю и свою локацию и прочую белиберду, но многие ещё отказываются в виде "а зачем этой программе знать мой адрес?".

«многие» — надо бы постепенно начинать использовать несубъективные кванторы. (сейчас не могу на бегу извлечь ссылку, пробегало исследование по количеству заблокированных location, оно мизерное)

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

privacy should be built upon principals not services. Бессмысленно давать доступ к GPS для Твиттера. Осмысленно давать доступ к GPS для моей семьи regardless сервис, которым она пользуется (твиттер, форсквер, инстаграм, етц)

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

Вот это да, и у меня есть такое ощущение.

Вообще, Dropbox + iCloud + Google Drive = вполне достаточно места на данный момент чтобы что-либо хранить. Из недостатков у последних двух — ограниченный набор типов документов, у всех трёх — в упомянутой дублированности, но она волшебно решится, если, например, Dropbox и Windows начнут качественно поддерживать симлинки.

Кстати, самые кажущиеся надёжными системы это DVCS.

Искать в дропбоксе без синхронизирования всех данных на локальный диск мне кажется вполне себе невозможно. Ну или надо лезть в веб-интерфейс. тыОблако и драйв примерно то же самое.

В принципе их можно использовать как "dumb storage" если скидывать туда шифрованные блобы и индекс.

DVCS работает примерно на таких же принципах, в частности гит сохраняет хешированные блоки данных, которые по этому хешу потом можно найти.

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

В DVCS надёжность именно в том (для меня), что ты вручную мёрджишь и пушаешь данные и стабильно где-то у тебя есть клон, точное содержание которого ты знаешь, потому что у тебя есть зеркало. И ты всегда знаешь, что туда ушло, а что нет.

По поводу "стоит ли начинать имплементить". Стоит имплементить всё, главное хоть что-то доимплеменчивать и доводить до ума). И давать людям поглядеть на что-то сырое, но с какими-то охрененными, уже работающими, фичами. И чтобы эти фичи в работе выглядели нестыдно.

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

Да, поддерживаю фидбек.

К реализации

чтобы граббер возник нужен

• протокол роутинга и поиска нодов. Пока простой вариант - DHT (Chord/Kademlia) + обычный rendezvous server для бутстрапа. https://github.com/berkus/librouting

• протокол синхронизации награбленного между нодами

• энное количество нод куда можно скидывать (поднять ли ес2 или ледник, или просто пару машин постоянно работающих, это неважно)

  Я бы хотел видеть скорее легко развёртывающиеся пресеты приватных нод — для носимого и домашнего компьютера, для ес2, для ледника, для vps. Чтобы не быть как диаспора по части поднимания своего пространства пользователем и не подставлять собственные мощности под удары фрирайдеров

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

  для ледника афаик надо иметь приложение-проксиноду

плюс со стороны интерфейса - пограбить код евернота или йожимбы или чего подобного чтобы можно было выделять произвольные куски информации и скидывать их в обладилище ("облачное хранилище" + обладать)

1. должна быть возможность добавить устройство в "кластер" своих устройств, разрешая ему таким образом поиск по всему кластеру и возможность модифицировать данные в этом кластере.
2. должна быть возможность удалить устройство из кластера, при этом доступа к этому устройству может уже и не быть. Например, потерянный телефон.
3. устройства, внесенные в кластер стараются всегда знать статус других устройств в кластере и приоритетно с ними синхронизироваться.
4. объект синхронизации - некий блоб и связанные с ним метаданные. структура блоба никак не определена, сохраняются и синхронизируются только изменения. структура метаданных - стандартный key-value storage.
5. поиск между устройствами ведется по индексу метаданных, которые устройства стараются синхронизировать приоритетно относительно других объектов.
6. если найденные метаданные указывают на блоб, отсутствующий в локальном хранилище, система старается провести поиск этого блоба на других устройствах и синхронизировать его.
7. в первой версии ареал хранения можно ограничить только устройствами внутри кластера.