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

Можно еще в жсон, но жсон не такой универсальный как хотелось бы

В общем планирую
data |> :erlang.term_to_binary() |> :zlib.zip() |> Base.encode64(padding: false)
получается более-менее

А зачем :zlib.zip ?
Во-первых, у :erlang.term_to_binary есть встроенные опции для сжатия данных
Во-вторых, лучше всё-таки знать конкретную структуру, которую ты будешь класть в урл
В-третьих, в урлы можно нативно класть и списки и туплы и кортежи
В-четвертых, это очень похоже на XY проблему. Лучше не делать :erlang.binary_to_term на данных без валидации. Недавно на этом попалась либа paginator и получила RCE

1. Не знал, что есть опции сжатия. спасибо, полезно.
2. Структуру я и так знаю, просто не хочется при добавлении очередного параметра переписывать энкодинг/декодинг этой структуры
3. Как?
4. И опция safe не помогла?

2. Тогда может лучше  использовать просто Jason.encode ?
3. http://my.site/path?x=[1,2,3]
4. Опция safe не помогает, конечно же.
Например, протокол Enumerable определён для функций. А ты, как я понял, собираешься использовать список для энкодинга в бинарь

2. Jason не умеет в кортежи, а глобальный протокол городить не хочется.
3. Ну так все равно надо эти списки и кортежи в строку сериализовать и обратно.
4. Результат  binary_to_term я, естественно валидирую, плюс safe, этого недостаточно?

А зачем тебе кортежи? Может можно обойтись без них?
И, если я не ошибаюсь, phoenix сам энкодит и декодит массивы в url

У меня на самом деле мапа, внутри которой есть кортежи. Избавиться от них можно, но нужно ли? Кроме того в эту мапу могуть попасть в будущем какие-то нетривиальные параметры фильтрации контента.
Так что либо в жсон либо в бинарь. С точки зрения размера и производительности полагаю term_to_binary будет уделывать Jason, но это не точно. Тут важнее, что term_to_binary умеет сериализовать что угодно

В описании опции safe для binary_to_term написано:

Use this option when receiving binaries from an untrusted source.

When enabled, it prevents decoding data that can be used to attack the Erlang system. In the event of receiving unsafe data, decoding fails with a badarg error.

This prevents creation of new atoms directly, creation of new atoms indirectly (as they are embedded in certain structures, such as process identifiers, refs, and funs), and creation of new external function references. None of those resources are garbage collected, so unchecked creation of them can exhaust available memory.

Поэтому если либа paginator схлопотала RCE, то по идее и эта функция эрланга должна схлопотать RCE.
Если конечно в либе косяк не по другим причинам.

Use this option when receiving binaries from an untrusted source.

When enabled, it prevents decoding data that can be used to attack the Erlang system. In the event of receiving unsafe data, decoding fails with a badarg error.

This prevents creation of new atoms directly, creation of new atoms indirectly (as they are embedded in certain structures, such as process identifiers, refs, and funs), and creation of new external function references. None of those resources are garbage collected, so unchecked creation of them can exhaust available memory.

Я же тебе написал почему paginator поймал RCE — он брал safe-овый binary_to_term и вызывал Enum.map

А Enumerable заимплеменчен для функций
Так что там просто в бинаре лежала функция

Выдавать в интернет данные без схемы — скользкая дорожка. Особенно в параметрах урла. Дело твоё, но я тебя предупредил

А ну так тут дело не в binary_to_term. И это не мой случай. Я валидирую то, что вернула эта функция.

Схема есть, вопрос тупо в сериализации и десериализации в url.

Так и сериализируй в JSON, убери из структуры тупплы, это же не сложно

Я не уверен, что жертвовать безопасностью против какой-то микрооптимизации, это хорошая идея

Особенно учитывая, что в структуру без схемы могут попасть всякие pid-ы, port-ы и всё такое

Но ладно, дело твоё

Вообще, binary_to_term и term_to_binary это отличные фичи языка, но, как грица "Don't drink to much Kool-aid"

Я подумаю. Хз будет ли дыра, ведь все эти pid-ы и port-ы все равно буду порезаны на стадии валидации.

а еще есть protobuf, trift, avro

То что они вообще просачиваются, попахивает, согласен.
Тут скорее не в микрооптимизациях , а в простоте. Жсон сложнее, атомы херит, например,