rPman

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

В самом простом случае, можете реализовать ВЕСЬ платный функционал на сервере, а на клиенте только интерфейс (вернуться во времена http rest архиетктуры, ну с оглядкой на эффективность и отзывчивость).

Из бесплатных (и наверное полулегальных) можно воспользоваться обычным android + google apps, там возможна установка гугловского синтезатора речи, для кучи языков, и по каждому можно подгрузить языковые данные для работы offline. Попробуйте все это в эмуляторе.

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

Если вы подключаетесь к серверу по rdp то после отключения сессия блокируется и GUI не работает

Вам необходимо либо держать сессию rdp открытой либо подключиться к консоли например vnc/teamviewer (в датацентре провайдеры вам это не дадут)

p.s. я решал проблему запуском десктопной windows в виртуалке, заодно оно работало на linux но с заметным понижением скорости

Легально проверить наличие - последовательно добавлять телефоны в контакт лист своего телефона и смотреть на реакцию чат-приложений.

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

Пример бота рассылки сообщений - на базе web telegram, приложение эмитирует буквально добавление контакта, ввод посимвольно текста и прочее, само собой с фиктивных аккаунтов, ибо после спам деятельности они будут забанены почти моментально.

итак, 2 главных правила:
1. приватные ключи адресов, выдаваемых пользователям НЕ ДОЛЖНЫ храниться на веб-сервере, мало того, так как вы не выдаете монеты, храните их лично на своем (владельца сервиса) аппаратном кошельке
2. bitcoind с ключом -prune 512 после прогрузки блокчейна будет занимать на диске примерно 6 гигабайт и через api будет полноценно работать с wallet.dat и адресами в нем в режиме просмотра и проверки прихода депозитов, запускать так же на сервере рядом с веб, на текущий момент этот демон может работать даже на малинке (файловую систему лучше использовать по сети на быстром файловом сервере, ибо у малинки только ОЧЕНЬ медленный usb), правда первичную загрузку лучше проводить на быстрой машине.

Вам достаточно генерировать на своей локальной машине и импортировать на веб сервер большими пакетами адреса для приема платежей (по уму это не так обязательно делать постоянно, но настоятельно рекомендуется один платеж - новый адрес) и все, больше ваш кошелек не потребуется. Чтобы защититься от ddos опустошения адресов приема, подсовывайте клиентам старые адреса без входящих переводов.

Существуют иные библиотеки, занимающие меньше ресурсов (подключаются напрямую к сети и не проводят никаких проверок кроме наличия подтверждения от майнеров, этого более чем достаточно), но формально они 'не официальные' (хотя это философский вопрос что есть официальное в децентрализованной криптовалюте, но если что то реализует, ломающее совместимость, то в первую очередь в bitcoind).

Это самый правильный и простой способ организации приема платежей.

p.s. ждите релиза lightning network, скоро это станет стандартом де факто для приема платежей

p.p.s. Если у вас есть задача переводов от вас, то реализуйте ее на отдельном сервере, коммуникация между веб-сервером и этим платежным сервером должна проводиться через специальный модуль безопасности (и разработанный для этого api), перепроверяющий все что только можно, в идеале разработанный разработчиками, отличными от тех кто делал веб-сервер.

https://github.com/tradingview дает библиотеку для своего красивого графика

Кажется вам лучше выбрать что-нибудь поддерживающее IMAP и воспользоваться какой-нибудь хорошей библиотекой на клиенте (или, если нужно, изобретите прослойку в виде сервера, тупо транслирующую вызовы по сети)

Поделись в личку ссылку на сервис, пожалуйста.

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

Намного проще оказалось реализовать основную (или часть) логику автоматизации и анализа в самом браузере с помощью javascript (со всей мощью jquery и т.п.), запуская браузер в какой либо компоненте в своем приложении (я использовал mono и компоненту штатную WebBrowser, она основана как я понимаю на firefox), приложение спокойно собирается в cli и работает на 'безголовых' серверах linux, при этом нет нужды бороться с владельцем сайта, который борется с ботами и ддос, выявляя тех кто эмитируют POST и GET запросы с помощью curl…

Объясните мне глупому, какого роды проблемы могут возникнуть у банка? Банки из принципа не хотят делать APi или все таки, как мне кажется, по глупости и заскорузлости мозга?

Никто не говорит о бесплатности и никто не требует нечто супер-функциональное… самый минимум — прием платежей, создание счета, принятие счета, отказ счета,… это ТАК СЛОЖНО?