Happ Crypt v5: что изменилось для пользователей и провайдеров

В документации Happ появилась формулировка, которую легко прочитать неправильно: старую версию шифрования ссылок crypt4 зачеркнули и назвали устаревшей, а на её месте появилась crypt5. Это не смена протокола внутри самого приложения Happ и не новая настройка в интерфейсе — это смена версии на стороне инструмента, который провайдер использует для шифрования адреса подписки.

Подробный разбор того, что вообще шифрует happ://crypto и чем отличаются версии Happ Crypt, уже разобран в глоссарии и на отдельной странице про версии Happ Crypt. Здесь — не пересказ, а взгляд с двух сторон одновременно: что это значит для пользователя, который получает готовую ссылку, и что стоит сделать провайдеру, который эти ссылки выпускает.

С точки зрения человека, который просто добавляет подписку по присланной ссылке, версия шифрования не видна ни до, ни после добавления. И crypt4, и crypt5 выглядят одинаково — строка после happ://crypto, которую приложение расшифровывает само.

Практический вывод один: если зашифрованная ссылка не добавляется, дело почти наверняка не в номере версии шифрования. Разумный порядок диагностики — от простого к сложному: сначала проверить, что ссылка скопирована целиком и не обрезана мессенджером, затем — что Happ обновлён до актуальной версии на этой платформе, и только потом писать провайдеру с просьбой перевыпустить ссылку.

Единственная реальная зависимость от версии приложения — это то, когда конкретная платформа вообще научилась работать с зашифрованными ссылками и их частными случаями. Так, поддержка шифрования появилась в Happ Desktop версии 1.4.0, а после — в разных релизах desktop и Android встречались точечные исправления обработки именно happ://crypt ссылок, например при HTTP-редиректах. Это подсказывает, что при проблеме с конкретной зашифрованной ссылкой стоит в первую очередь проверить версию приложения, а не искать причину в самой ссылке.

Провайдер не выбирает версию Happ Crypt вручную — crypto.happ.su и его API сами подставляют актуальный номер в момент шифрования. Из этого следует практический вывод: обновлять ничего специально не нужно, если ссылки создаются каждый раз заново через веб-страницу или API, а не берутся из старого архива уже готовых ссылок.

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

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

Открытых источников о будущих версиях Happ Crypt нет: судя по нумерации, до crypt4 существовали и более ранние версии, но текущая документация их не описывает, а о планах после crypt5 разработчик не сообщает. Единственный надёжный способ узнать о следующей смене версии — сама документация Happ и страница Провайдер ID для тех, кто уже пользуется расширенными параметрами подписки.

Для провайдера практичнее не привязываться к конкретному номеру версии в инструкциях для своих клиентов, а описывать процесс через сам инструмент: «зашифруйте ссылку на crypto.happ.su» вместо «используйте crypt5» — тогда инструкция не устареет при следующей смене номера. Как ещё провайдеры защищают выданные ссылки — в обзоре HWID-ссылок и в инструкции как поделиться конфигурацией.