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.
Обычно лучше добавить лишний запрос в инициализацию коннекта к базе, чем прыгать с бубном вокруг почти нереальных особенностей каждой имплементации базы данных.
d-stream, многим проектам схемы - это из пушки по воробьям. Кроме того, это может быть неудобно для переносимого кода. Например, какой-нить CMS на php pg-специфиеская возня со схемами в запросах ни к чему.
Не знаю как конкретно в этих роботах, но вообще в робототехнике могут просто отдаваться данные в облако, где и выполняются сложные вычисления. И в стандарте 5G есть движуха в сторону того, что базовые станции 5G будут также предоставлять локальные вычислительные ресурсы для всяких IoT. Такие вот местные микрооблака.
InessaPlaksa, очень просто было бы, если бы дата реально была необходима. Если хранение даты необходимо для работы сайта, то она просто необходима. Поэтому удалить дату вы можете только с полным удалением аккаунта пользователя. Как и где получена эта дата неважно.
Но в данном случае проблема надумана. Вам не нужно знать дату рождения пользователя на постоянной основе. Это нужно только в момент создания аккаунта. Потом дату можно спокойно "забыть". Факт наличия верифицированного через надёжный источник аккаунта подтверждает, что на момент регистрации пользователю было необходимое число лет.
Вот если бы у вас сайт был 18-, то вам пришлось бы следить за тем, что аккаунт перерастёт пороговое значение, в этом случае дата была бы необходима.
Я делаю две сети, устройство цепляю к обоим, но автоконнект с 2.4 ГГц убираю. Тогда если припрёт слишком далеко отойти (на даче например), то просто руками цепляю телефон к нужной сетке, при этом обычным автоконнектом он на неё не прыгает.
... Но в целом у меня на даче не такой интернет, чтобы 5 ГГц прям требовался, да и конкурирующих сетей нет - ближайшие соседин около 200 метров с деревьями посередине.
Как бы всех, кто криптовалютами начинают пользоваться, предупреждают о том, что они рискуют.