Господа, а кто чем в cljs графики рисует? Нашёл Oz, но пока вызывает сомнения

любая js библиотека которая тебе нравится

имхо нет смысла на обертках фиксироваться

емаксом не перестают пользоваться(скорее наоборот), изменяется состав пользователей. Если раньше под никсы фактически не было альтернатив для редактирования, только Emacs/Vim, то теперь их полно. Потому уходят люди, которые использовали емакс как базовый текстовый редактор (да, их много), зато приходят те, кому емакс действительно нужен. А так - package.el, MELPA (да что греха таить, и Spacemacs тоже) и прочие дали громадный толчок для развития и популяризации.

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

вот точно насчет других языков :)

😕

штульман не одобряет использование слова "кодер"!

Подскажите пожалуста, есть ли какая то либа для валидации форм в cljs с контролем состояния типа error, dirty, invalid? Как в redux-forms

опенсорсные - не знаю. Все свои пишут.

Вообщем там писанины немного

О, хороший вопрос, мне очень нравится final form

я даже думал обёртку на ней сделать cljs

кто про чарты спрашивал https://lambdaisland.com/blog/2019-12-10-advent-of-parens-10-hillchart-reagent-shadow-firebase

вам нужны интерактивные чарты? Я б их на сервере закатал и делов

о, ребят, давайте спрошу, вдруг кто в курсе, у меня тут проблемка:

Есть unforgeable токен (token1), которые нужно иметь возможность "оборачивать" (token2), т.е. добавлять новую информацию (data2) и подписывать своим ключом(secret2). Должны соблюдаться следующие условия:

1. Обладая token2 не должно быть возможности получить валидный token1
2. Верификатор должен иметь возможность проверить валидность всей цепочки.

Структрура токенов примерно следующая:

token1 = data1.apikey1.signature1
  where signature1 = sign(data1.apikey1, secret1)

token2 = data1.apikey1.data2.apikey2.signature2
  where signature2 = sign(data1.apikey1.signature1.data2.apikey2, secret2)

Используя hmac с симметричными ключами это легко сделать (apikeys в данном случае это просто идентификаторы по которым верификатор получает секреты), на этапе верификации мы просто воспроизводим всю цепочку и сравниваем итоговую подпись. Однако этот подход требует знания верификатором всех секретов.

Идеально было бы использовать асимметричные подписи: подписывать данные разными приватными ключами аккумулируя результат в одну подпись (сохраняя валидным требование 1.), проверять списком публичных.

Наиболее точное описание того, что я хочу я нашел тут [1], но оно все что дальше введения сильное академично, без имплементаций. Возможно, я просто не знаю как надо искать и это общеизвестный алгоритм? Или я хочу неправильного? Спасибо.

[1] https://eprint.iacr.org/2005/335.pdf

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

Тогда структура данных должна быть как дерево, чтобы каждая новая подпись враппила старый контент и его подпись.

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