По мотивам истории об угнанном велосипеде я решил поизучать какие есть решения для помощи в поиске украденных вещей. У AirTag, который помог найти велосипед, есть один существенный недостаток — функция защиты от нежелательного отслеживания (unwanted tracking protection). Эта функция предусмотрена для того, чтобы нельзя было незаметно подбросить метку другому человеку и следить за ним. Благодаря ей, сколько-нибудь подготовленный вор, с помощью стандартного встроенного в ОС софта, легко узнает, что к велосипеду прикреплён AirTag или другая совместимая гео-метка.

Поэтому я бы хотел найти такую гео-метку, которая обладала бы следующими свойствами (в порядке убывания важности):

• не детектится программами типа FindMy,
• имеет широкую сеть покрытия. То есть украденную вещь можно обнаружить даже если её увезли в другой город или страну. Последнее актуально для Германии, так как здесь украденные велики часто переправляют в Польшу,
• имеет долгий срок работы от батарейки, хотя бы 10-12 месяцев,
• работает по принципу: купил, установил и забыл. Никаких платных подписок, дорогостоящего или трудоёмкого обслуживания и так далее.

В итоге, я пришел к тому, что есть четыре типа устройств, о которых я расскажу ниже. Если коротко, то, к сожалению, сейчас на рынке нет ничего лучше AirTag.

Итак, четыре типа устройств:

1. RFID/NFC метки,
2. Bluetooth-устройства — AirTag и совместимые с ними гео-метки от других производителей, а также несовместимые устройства того же типа,
3. GSM/GPS трекеры,
4. LPWAN устройства.

Суть всех вариантов кроме третьего заключается в том, что есть два типа устройств: гео-метка и ридер (считыватель).

Гео-метка прикрепляется к отслеживаемому объекту, а ридер может находить метки находящиеся неподалёку. Чем сильнее сигнал от гео-метки, тем дальше может находиться ридер чтобы её найти, но и тем больше требуется энергии для работы метки. Как следствие — тем больше нужна батарейка или тем чаще придётся её менять.

В зависимости от типа метки, ридером может выступать или специализированное устройство, или обычный телефон. Ридер знает свои координаты и по мощности сигнала от метки может определить примерное расстояние до неё и направление к ней.

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

Таким образом, выбор устройства — это поиск компромисса между:

• размером и энергоэффективностью меток,
• сложностью и стоимостью обслуживания меток и ридеров,
• размером и надёжностью сети ридеров.

В двух предыдущих постах я рассказал о том, что такое ipfs и как развернуть сайт в ipfs и, помимо этого, для эксперимента настроил раздачу своего блога через ipfs: ipfs.romka.eu.

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

В моём случае ipfs работает в докер-контейнере, который запускается через docker compose. Поэтому я сконфигурировал запуск контейнера следующим образом, чтобы сильно ограничить потребляемые ресурсы:

  ipfs:
    image: ipfs/kubo:latest
    container_name: ipfs_container
    volumes:
      - /home/romka/ipfs:/data/ipfs
      - /var/www/romka.eu/public:/data/ipfs/public:ro
    <...>
    restart: always
    command: daemon --enable-gc --migrate=true --enable-pubsub-experiment
    cpus: 0.3
    mem_limit: 256m
    memswap_limit: 256m
    environment:
      GOMAXPROCS: 1

Теперь ipfs-процесс ограничен по ресурсам и хостер доволен, но вот команда ipfs add стала падать с ошибкой вида Error: unexpected EOF. Я не стал копать глубже, но в свете того что ошибка появилась после добавления ограничений, похоже на то что это следствие того что ОС просто прибивает процесс ipfs из-за Out of Memory error (OOM). Дальше я расскажу как мне удалось исправить эту проблему.

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

Для начала я в двух словах объясню в чём состоит различие между динамическими и статическими веб-сайтами.

У динамических веб-сайтов за отдачу содержимого отвечает какая-то программа. Обычно такие программы пишутся на одном из языков вроде PHP, JavaScript, Python, Go и других. Запрос от браузера пользователя обслуживается веб-сервером, который перенаправляет его программе, а программа в ответ на лету генерирует какую-то html-страницу, которая возвращается пользователю. В теории, запросы к одному и тому же адресу от разных пользователей могут получать разные ответы. Такой подход оправдан в случае если действительно есть необходимость отдавать разным пользователям разный контент при запросе одних и тех же страниц. Например, в социальных сетях одна и та же страница новостей для разных пользователей содержит разные новости.

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

IPFS – это распределённое хранилище и оно не способно обслуживать динамические сайты, однако вполне подходит для статических. Фактически, статический веб-сайт это просто директория с набором html-файлов, css, скриптов и картинок. Чтобы разместить такой сайт в IPFS достаточно добавить эти файлы в систему командой вида ipfs add .... Однако есть несколько важных нюансов, о которых я бы хотел рассказать.

Для того чтобы сделать статический веб-сайт доступным в IPFS нужно выполнить 4 шага:

1. запустить ipfs daemon,
2. в html-файлах использовать относительные ссылки на локальные ресурсы,
3. добавить dnslink,
4. использовать IPNS и включить его автоообновление.

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