Ну как самое тривиальное: вынести этот код в отдельный файл, подгрузить его AJAX-запросом и подклеить в DOM страницы. Говнокод, но в битрике всё равно всё им увешивают...
Этот вопрос лучше задать Амазону. Ну для начала, зайти в их "личный кабинет" или как он там называется и узнать статус своих серверов. Может, они просто в тыкву превратились, а IP отданы кому-то ещё?
В интернетах пишут RestoreCord был продан его владельцем какому-то челу, который потом попался на сливе данных. Ну и плюс может существовать файльшивое приложение с таким же именем.
Дело скорее даже не в коммерческой тайне, а в исключительной узости решений, которые используются в частной имплементации под частные условия с частным уровнем нагрузок. Так-то подобные вещи бизнесы иногда даже рассказывают на разных конференциях или в технических блогах.
При этом иногда могут изобретать разного рода кадавров, например, часть данных класть в кликхаус, а часть - в кассандру - в зависимости от типа данных и сценария их использования. Причём могут и одни и те же данные туда класть, для использования в разных задачах.
В моей практике был такой случай: нужно было под какую-то задачу иногда выгружать какие-то сведения о данных за прошедшие полгода, DBA там какую-то автогенерируемую таблицу соорудили, которая на тестах нормально работала, а на проде сильно медленно, в итоге сделали репликацию нужных данных с помощью nifi в кликхаус, где нужная задача решалась весьма эффективно.
billybonns, вот кстати если файлы видны - то их как раз сохранить просто - они в каталог WhatsApp Images кладутся (по крайней мере на андроиде). Я даже синхронизацию этих файлов в NextCloud настраивал...
Например, файлы в такой группе качаются не с сервера, а у других участников. Если другой участник офлайн или файл у него уже удалён, то это скачать его не удастся.
Matox, если перекидывает на сайт по url-ссылке, то просто пусть бот в этот url добавляет параметры. Если flet даже не умеет параметры из ссылки брать - то это негодное решение для написания сайта.
А как пользователь попадает в приложение? Какая-то ссылка?
Так-то можно в ссылку передать user_id. Условно, пусть есть url://to.application/some/path, вот превратить его в url://to.application/some/path?u=id_пользователя. Можно для защиты от ручного спуффинга id приделать тривиальную криптографию. Например, приписывам тайное слово к id, берём MD5 и получаем некий проверочный код. Можно даже отрезать от него несколько символов. Тогда передаём в ссылке u=id_пользователя&d=секретный_код и на стороне приложения проверяем, что вычисленный по id код совпадает с переданным.
Я просто не знаю, можно ли в ссылках на приложение передавать параметры...
Для видео скорее нет, чем да. Слишком уж накладно хранить видео, и все, у кого это легко и просто делать, как правило быстро загибаются. Именно поэтому в большинстве случаев видео использует embedded player или SDK.
Я бы рекомендовал всё же двигаться в сторону доработки викидвижка до состояния, когда в него можно вставить внешний плеер. Ну или таки заложить расходы на хранение своих видеофайлов (вероятно, также поупражнявшись с пережиманием видео в поисках приемлемого качества при минимальном размере).
d-stream, нет, снег зимой - это примерно так же осмысленно, как странно настроенный сервер с дефолтной схемой не public.
Обычно лучше добавить лишний запрос в инициализацию коннекта к базе, чем прыгать с бубном вокруг почти нереальных особенностей каждой имплементации базы данных.
