тоже надо отваливаться

Так как ts это типизированный js я теряю типизацию)

Прошу прощения что опять поднимаю эту тему, после фееричного баттла: нжинэкс против ковбоя. Но у меня возникли вопросы именно по этому репозиторию, остальные не смотрел. Как именно будет организовываться анонимность и децентрализация в сети и p2p? Сейчас в исходниках я вижу банальный tcp. Наличие там шифрования делает почти ничего для обеспечения анонимности. Для p2p и децентрализации нужно что-то более хитрое нежели бутстрапинг через одну ноду. Где dht? Где дисковеринг нод? Извините, если моё сообщение выглядит как критиканство. Я просто хочу разобраться. Возможно я не внимательно смотрел.

Это верно если нет tls, а с шифрованием, nginx, явно, быстрее устанавливает секурные соединения с клиентами, а проксирует он ковбою уже просто http1.1 запросы

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

Привет! Нам не нужно беспокоиться об анонимности реальных IP-адресов майнеров и узлов, если кто-то хочет скрыть свой IP, он может использовать VPN. Анонимность проявляется на уровне транзакций, где фактические пользователи цепочки (люди, отправляющие транзакции) должны иметь возможность отправлять транзакции без привязки к ним, даже псевдонимно. Для этого мы будем использовать zkSNARKS, который позволяет нам создавать транзакции, которые поддаются достоверной проверке, не делясь сведениями о самой транзакции, такими как адреса внутри транзакции или сумма

понятно, спасибо

При этом мы пока не внедрили zkSNARKS, но мы будем внедрять его в ближайшем будущем. Кроме того, что касается безопасности данных tcp, мы используем SRP и AES256 для сквозного шифрования данных, передаваемых между узлами. Первоначальное обнаружение одноранговых узлов выполняется через центральный сервер начальной загрузки (поскольку это неизбежно), а затем одноранговый узел запрашивает своих одноранговых узлов

анонимность только транзакций допустим ок. Но не задумывались ли вы что один (два-три-...) бутстрап сервер(а) это прям таки централизованная централизация?

Господа, пожалуйста, помогите разобраться с 302 редиректом в контроллере, как сделать? Описание ситуации по ссылке - https://gist.github.com/lyo5ha/26bd10d55c7810dc28a5cd389658c543

но ведь ковбой это http2 (гифка с сильнорасстроенным персонажем)

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

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

ну окей, тогда понятно

> поскольку это неизбежно
Таки можно развернуть несколько бустрап-нод и хоть захардкодить их для остальных пользователей. В случае чего пользователи смогут поменять. А так, при закрытии центрального сервера вся система падает.

это не жестко, его вариант конфигурации. узлы могут использовать любой сервер начальной загрузки, который им нравится

тебе надо поймать ответ шттпойзона с редиректом, и сделать conn |> put_status(302) |> redirect(to: куда там тебе надо) в таком духе.

Привет, Никита! Как там крипта? В этом редиректе есть куки с ключом. И они в conn не кладутся. Вернее не так - кладутся, но реальный редирект в браузере, который делаю в контроллере (redirect(external: <домен>)) уже без этого ключа в куках.

О, попробую, put_status не пробовал.

ну и куку положить попробуй, чего эт она не кладется то