Многие из нас замечают, что с увеличением числа онлайн-сервисов, контроль над личными данными кажется ускользающим. Наши файлы и личная информация хранятся на удаленных серверах, защищенные паролями и методами двухфакторной аутентификации, и доступны нам только до тех пор, пока мы оплачиваем подписку. Но что произойдет, если потеряется SIM-карта, истечет срок подписки, или если вдруг аккаунт будет заблокирован из-за санкций? Есть ли план на случай, если сервис, который мы используем для работы с паролями или заметками, внезапно прекратит свое существование? Как тогда быть с экспортом и импортом данных? Это вопросы, о которых задумывается каждый из нас, исследуя цифровую эру и свое место в ней.
Эта статья предлагает уникальный взгляд на то, как мы можем взять лучшее из прошлого и будущего, чтобы исправить ошибки в управлении данными. Она расскажет о методах, позволяющих вновь контролировать личную информацию, обезопасить её от утечек и избежать ограничений, налагаемых поставщиками услуг. Кроме того, статья раскрывает, как сделать личные данные одновременно более открытыми и защищёнными.
Давайте предоставим лёгкий способ использовать искусственный интеллект для работы с вашими данными, минуя сложные технологические процессы и зависимости от крупных корпораций. Это позволит вам свободно работать с разными типами данных, не привязываясь к конкретной операционной системе или программе, и при этом не терять в качестве, а даже приобретать новые возможности.
Эта статья предназначена для тех, кто интересуется технологиями и смотрит в будущее. Она обращена к любознательным и немного гиковатым читателям, которые осознают растущую роль искусственного интеллекта в повседневной жизни, включая программное обеспечение и операционные системы.
Чем плох тот подход что есть сейчас?
Блокировки и доверие
Современные подходы к хранению данных обычно предполагают, что все данные хранятся внутри приложения, с резервным копированием на сервере этого приложения, или полностью на сервере, а приложение служит лишь для их отображения. Это означает, что мы полагаемся на разработчиков и поставщиков этих программ для работы с нашими данными. Однако возникает вопрос: насколько надежно данные хранятся? А ещё, любые централизованные хранилища данных могут привлекать хакеров, что делает их потенциальной целью для атак.
Утечки и надежность
Даже такие крупные компании как Google иногда теряют пользовательские данные из-за неудачных обновлений. Примеры утечек данных, например, инциденты с "голыми знаменитостями" от Apple, показывают, что никто не застрахован от ошибок. Даже базы данных таких организаций, как ГИБДД, оказываются под угрозой. Часто компании передают данные спецслужбам по законным требованиям, что добавляет риски. Эти события подчеркивают, что хранение данных миллионов пользователей — это сложная задача и что доверие своих данных третьим сторонам влечет за собой множество рисков.
Давайте обсудим важность безопасности личных данных в приложениях, особенно в тех, где мы используем свои логины и пароли. Когда мы вводим такую информацию в приложение, существует риск, что она может попасть в руки недобросовестных разработчиков. Это особенно опасно, так как одна и та же комбинация логина и пароля часто используется для доступа к разным аккаунтам – от электронной почты до облачных сервисов, как, например, iCloud. Примеры таких утечек в прошлом, включая инциденты с Apple, подчеркивают важность осторожного отношения к выбору приложений и внимания к безопасности данных.
Хранение данных в локальной базе данных приложения также может быть рискованным. Иногда обновление программы может случайно повредить эту базу данных, что приведет к потере информации. Такие ситуации уже случались в прошлом.
Изоляция и интеграции
Как вы думаете, почему мы стали хранить данные непосредственно в приложениях вместо использования стандартных папок, таких как 'Документы' или 'Фотографии', в наших операционных системах? Раньше это было обычным делом. Не кажется ли вам, что пора вернуться к этой простой и удобной практике?
В настоящее время данные, хранящиеся в программе, недоступны для внешних сервисов, за исключением случаев наличия у программы специализированного API, такого как инструмент индексации данных Apple. Представляете, был разработан целый SDK и проведена интеграция в систему, только чтобы данные могли храниться в приложении и синхронизироваться с серверами производителя. Кажется удивительным, что для достижения такой задачи было затрачено столько усилий.
Я действительно не до конца понимаю для чего нас всех так сильно прижали, сколько лишней работы было проделано для интеграции этой концепции…
Давайте обсудим обмен данными между различными платформами. И тут все ещё веселее. Если для вашей платформы нет программы, вы не сможете работать со своими данными на этой платформе. Это своего рода призыв оставаться в рамках одной экосистемы. Как будто говорят: "Зачем вам другие опции? Останьтесь с нами и станьте полностью зависимыми от нашей системы". Как пример можно представить приложенир Фото, от Apple.
Как насчет использования искусственного интеллекта для улучшения поиска и организации наших данных, например, для создания описаний фотографий для поиска? Возьмем, к примеру, всё то же приложение Фото от Apple: если вы попробуете найти "красную машину", оно может не выдать ничего или показать любые красные объекты. Попытки использовать осмысленные запросы часто приводят к нерелевантным результатам. Но мы не можем интегрировать собственный ИИ непосредственно в это приложение. Это означает, что нужно искать альтернативные, более умные программы, которые пока не существуют. Таким образом, мы оказываемся в тупике, где наши данные ограничены рамками лишь одной программы, не умеющей нормально обработать фотографии ИИ.
Итак, в результате текущего положения вещей, нам не хватает связи между различными платформами, каждая из которых предлагает свои уникальные решения для работы с данными. Часто бывает так, что отличное приложение доступно только для одной или двух платформ, игнорируя остальные. Иногда приложения не предоставляют API для интеграции дополнительных функций, таких как обработка данных с помощью искусственного интеллекта или даже простых скриптов. Для разработчиков это создает дополнительные трудности: нужно создавать и поддерживать свой продукт одновременно на нескольких платформах.
Что в итоге, мы имеем проблемы с:
утечками наших данных
потерей наших данных
потерями данных после обновлений приложений
утечками наших данных по запросам
утечкой доступов через сторонние программы для доступа к данным
блокировкой нашего аккаунта с данными
постоянной платой за пользование нашими данными
возможной потерей симки или пароля для доступа к нашим данным
переносом данных из одной программы в другую
переносом данных из одной платформы в другую
запертыми данными внутри приложений
разработкой софта под каждую платформу и поддержка
отсутствием API для работы с даными в каждой программе
Чем хорош новый подход, что ты предлагаешь?
Для начала я предлагаю освободить данные, точнее освободиться от тех программ которые хранят данные внутри себя. Данные должны храниться в папках.
Программы должны выполнять только функции отображения данных пользователей, без необходимости напрямую соединяться с серверами или хранить данные в себе. Таким образом, они станут простыми интерфейсами, что повысит легкость их использования. Основная обработка данных должна быть передана доверенным системным сервисам. В то же время, хранение пользовательских данных следует организовать с помощью файловой системы.
Навскидку, можно предложить несколько простых сервисов, для получения данных из различных источников:
Email
SMS
RSS (readonly)
Расшаренные папки
Сообщения в мессенджерax
Загрузки из интернета
Контакты
Заметки
Календари
Представьте, что для каждого типа данных мы создаём универсальный сервис. Этот сервис будет способен выполнять основные функции: получать, обрабатывать, хранить, удалять и отправлять данные. Особенностью такого сервиса является его способность работать только с одним определённым видом данных, делая это на высоком уровне. Возможно, для достижения лучших результатов, потребуется не один сервис, а комбинация нескольких утилит. Главная цель — специализация на обработке данных от конкретного источника.
Чтобы облегчить доступ к этим сервисам, можно разработать пользовательский интерфейс любого вида и качества, будь то веб-приложение или программа, управляемая из командной строки. Также есть возможность создать собственную уникальную программу и предложить ее пользователям через такие платформы, как AppStore.
Приведи пример о чем речь вообще… нифига же не понятно
Окей, давайте рассмотрим простой случай для лучшего понимания: представьте, что у нас есть приложение для работы с электронной почтой. Обычно оно самостоятельно подключается к серверу и управляет письмами. Теперь представим, что вместо этого приложения мы используем специализированный сервис.
Получение данных, обработка и хранение
Пусть email сервис автоматически скачивает письма с сервера и сохраняет их как файлы в формате .eml в определённой папке. Затем вступает в работу ИИ, который анализирует содержимое каждого письма. Он распознает и извлекает из них различные данные, такие как подпись и контактную информацию отправителя. Также ИИ определяет тип письма, например, является ли оно спамом, уведомлением от банка или личным сообщением. На основе этого анализа, к каждому файлу присваиваются соответствующие теги, упрощая дальнейшую организацию и поиск по письмам.
Представьте, что у нас есть сервис для получения текстовых сообщений СМС. Как только поступает новое сообщение, оно сохраняется в определённой папке в виде текстового файла с расширением .txt. Затем, сервис на основе искусственного интеллекта анализирует эти сообщения и присваивает им соответствующие теги для удобства дальнейшего использования.
Мы также используем сервис управления контактами, который автоматически обрабатывает данные из локальных источников, например из папок с письмами и СМС. Этот сервис сканирует теги и, обнаружив данные о новых пользователях, которые написали нам, автоматически создает новые контактные файлы формата .vcf с уже заполненными полями.
Просмотр данных
Давайте так, уже на данном этапе обработка данных становится более удобной прямо из операционной системы. Теперь у нас есть возможность индексации данных в текстовом формате, в отличие от старого метода, когда все сообщения хранились в базах данных внутри каждого приложения.
В новом подходе, для просмотра сообщений, вы можете использовать обычный файловый менеджер для доступа к папке с письмами и текстами. Это значит, что для работы с сообщениями вы можете применять все удобства файлового менеджера, включая создание "умных" папок, которые автоматически организуют ваши сообщения по тегам или именам отправителей. Т.е. мы получаем как бы классический GUI в котором слева ФИО отправителей, а при нажатии на них видим список всех сообщений этого отправителя как на почту так и в виде СМС.
Пример, который я привел, может показаться сложным и неудобным для обычных пользователей, но важно понимать, что он упрощает работу с данными. И если бы данный подход существовал давно, AppStore имел бы огромное количеатво удобных и красивых приложений для работы с данными и их визуализации, делая этот процесс доступным для каждого.
Ещё раз о секъюрности
Когда мы даем сторонним приложениям доступ к нашей электронной почте, мы рискуем что наши данные могут быть переданы третьим лицам. Примером такой ситуации может служить инцидент с Apple, когда произошла массовая утечка личных фотографий знаменитостей. Все произошло из-за использования одинаковых логина и пароля для iCloud и почтовых аккаунтов. Это дало сторонним почтовым приложениям возможность доступа ко всему содержимому iCloud пользователей.
Если бы за работу с почтой отвечал лишь сервис находящийся в операционной системе, он бы получал и отправлял письма, сохранял бы данные локально. А остальные программы бы работали лишь с этими данными и с API этого сервиса, то такой утечки бы просто не могло случиться.
Ещё раз. Представим, что операционной системе есть сервис котрый забирает письма с сервера и кладет их в папку локально. Далее любая GUI программа которая хочет красиво отобразить нам списки писем, просто берёт эти файлы и отображает. Т.е. она не лезет сама на сервер, она не имеет вообще никакой чувствительной информации, которая через неё может утечь. Более того, раз отправка писем лежит на сервисе, а не на данной программе, то ей можно вообще запретить ВЕСЬ исходящий трафик фаерволом. Т.е. никакой утечки при всем желании не может случиться.
Старый подход − доверие логина паорля каждой новой программе работы с почтой
Новый подход − почтовая программа лишь отображает письма, программа закрыта фаерволом по всем исходящим портам и протоколам
Что то поконкретнее может?
Представьте программу, которая автоматически отслеживает ваши доходы и расходы. Обычно, для этого нужно вручную вводить данные по каждому расходу или доходу, либо использовать API банка, что может быть сложно и не всегда безопасно. Более того не у всех банков имеется такой API, а уж охватить разом все банки вообще для разработчика не возможно.
Однако у многих банков есть уведомления по электронной почте и СМС, которые мы часто игнорируем. Что если использовать их? Используя сервисы описанные выше, мы можем автоматизировать сбор информации о движениях на счетах, анализируя письма и СМС, распознавая нужные данные благодаря искусственному интеллекту.
Таким образом, в нашей финансовой программе будут отображаться все поступления и расходы в режиме реального времени, без необходимости предоставления доступа к API банка. Это делает процесс не только удобным, но и повышает безопасность ваших данных.
Ещё пример пожалуйста и в этот раз без почты
Окей, давайте рассмотрим ситуацию с программами для заметок. Сейчас существует множество таких программ, каждая из которых использует свою внутреннюю базу данных. Но что если программа прекратит своё существование, как это уже случалось? Встаёт вопрос о сохранении и переносе данных.
Итак, какой выход?
Один из способов − хранение данных не в специализированной базе данных приложения, а прямо в файловой системе в универсальном формате для заметок. Это позволит обеспечить переносимость данных между различными программами, ведь все они будут работать с одним и тем же типом файлов, используя свой уникальный интерфейс. Таким образом, вы сохраняете свои данные и обеспечиваете лёгкость их переноса в случае необходимости.
Ну… может ещё один последний примерчик?
Окей, работа с сообщениями. Например сейчас у нас есть Whatsapp, Telegram, iMessage и другие программы, включая обычные СМС. И что нам приходится делать? Правильно заходить в каждую программу где нам написали, что бы в ней ответить. Но вот если бы для каждой программы был бы сервис, который бы каждое сообщение клал в виде файла в папку то все бы изменилось.
Тогда любые сообщения любого мессенджера мы могли бы видеть в одном интерфейсе и отвечать в каждый из них так же как раньше, не думая откуда тебе кто написал. Это было бы удобно.
А не будет это тормозить, БД же быстрее?
Сейчас SSD по скорости даже быстрее чем память пятилетней давности. Но не это главное, а главное то что никто не заставляет например не использовать кеширование в самой программе. Т.е. предзагрузить часть данных в память например.
Так какие же плюсы?
Опять же на вскидку мы получаем следующий набор плюсов:
наши данные принадлежат нам
нет утечек все секъюрно
нет зависимости от вендора
нет зависимости от автора программы
легкая обработка данных своими сервисами ИИ
даные доступны к просмотру любым способом, даже из командной строки
нет возможности залочить ваши данные санкциями
лекгая переносимость данных между приложениями
легкая переносимость между платформами
гибкая система настройки
Какие же минусы?
Хранение данных на устройстве занимает место, т.е. это должны быть устройства с большим объемом. Если говорить про телефоны, то конечно iPhone во всех планах выступит как аутсайдер… как по цене за телефон с большим диском так и по ограничениям операционной системы. Лучше посмотреть телефон на linux, с картой microSD на любой объем.
Что бы не начинать холивар, сразу скажу, что например приложение Файлы на iOS, в котором у меня хранятся сканы некоторых документов, обычно должно подгрузить сканы и этот процесс занимает время, а когда интеренет оставляет желать лучшего, то в такие моменты понимаешь, что если бы данные лежали непосредственно на устройстве жизнь была бы значительно проще.
Так что даже эти минусы, это скорее плюсы.
Итоги
Я разработал идею, концепцию и поделился ей с вами для того что бы показать, что с данными можно работать иным способом, более безопасным и более простым и открытым. Показал на примерах, что сделать такое вполне было реально для любой операционной системы, и объяснил почему это не делалось. Рассказал как вендоры возвели заборы вокруг своих экосистем, борясь за каждый бат данных пользователя и чем это иногда заканчивалось.
Сейчас мы имеем то что имеем, но выход из этой ситуации я тоже описал. Для себя я решил начать именно с проектирования этой схемы работы с данными, а продолжить написанием отрытых сервисов на своем github на golang или любом ином языке. Если кому то как и мне эта тема не безразлична, пишите мне, я постараюсь всем ответить. Если вы хотите присоедениться к разработке сервисов, то я так же буду очень рад.
Всех с наступающим 2024 годом. Пора вернуть свои данные себе.
Комментарии (138)
nin-jin
29.12.2023 11:42Так же не "разработан" вопрос синхронизации: на двух девайсах изменил один файл и привет, конфликт изменении. Чтобы с этим совладать нужен CRDT, но это уже далеко не просто текстовые файлики, а куча мета инфы.
Ну и отказоустойчивости: вырубился комп, пока пишешь в файл, - получили битый файл. Собственно, одна из основных задач субд - восстанавливать целостность бд после сбоя.
svanichkin Автор
29.12.2023 11:42Либо сервис может работать на каждом девайсе, либо можно использовать сервис лишь на одном устройстве а синхранизация данных может проходить через Syncthing, и только теми папками которые на девайсе требуются.
Например на игровой консоли будет только папка с играми, а вот NAS например будет синхронизировать вощбе все папки.
Целостность данных обеспечивается ФС (zfs, apfs и т.д.), но если взять именно ваш пример, где мы пишем например вот этот сообщение и прямо сейчас отключется комп, то данные так и так будут потеряны, если их не сохранять после ввода каждого символа.
nin-jin
29.12.2023 11:42Syncthing не решает проблему конфликтов, а запуск сервиса на одном девайсе делает систему централизованной.
Копировать несколько блоков для записи одного байта - такая себе оптимизация получится. И да, некоторые субд могут сохранять каждый символ в реальном времени.
svanichkin Автор
29.12.2023 11:42Syncthing решает проблему конфликтов, но есть решения лучше, я же привел в пример первый попавшийся.
Записывать каждый символ можно и в файл. Опять же я нигде не говорил про экономию или что то подобное, Я написал, что есть некоторая усталость от таких решений вроде программы "Фото" от Apple. И есть риски того что ваши данные уже не ваши.
Я просто хотел бы что бы каждый кто прочитал статью понял это. Переубеждать кого то не моя задача, я лишь показал путь выхода из этой ситуации для тех кто понимает.
nin-jin
29.12.2023 11:42Каким образом он её решает? Оставляет последнюю по времени версию?
Меня переубеждать и не надо, я уже почти допилил своё решение этих проблем.
svanichkin Автор
29.12.2023 11:42+1Ну во первых мое уважение, посмотрел ваш проект, это классно. Идея хорошая и видимо уже есть некоторая реализация.
Теперь на счет syncthing, во первых это открытый проект, можно дописать если что то требуется. Конфликты решаются так что если запись ведется одновременно в один файл, то создатся дубликат, который ляжет в папку конфликтов, откуда уже ручками юзер сделает исправления.
Но если что даже в Git конфликты решаются не всегда автоматически. Одновременная запись в один файл в работе с Syncthing вообще редкий кейс. Если например смотреть на мою идею, то достаточно запустить сервис лишь на одном устройстве. И тогда лишь один сервис будет обновлять данные. Остальные устройства будут получать данные из Syncthing.
nin-jin
29.12.2023 11:42Ручками обычный пользователь не сможет адекватно смёржить что-то помимо неструктурированных текстовых файликов. У меня есть прототип бесконфликтной системы контроля версий, которая по задумке будет в реальном времени синхронизировать файлики между девайсами и сайтами.
svanichkin Автор
29.12.2023 11:42Ну если сейчас посмотреть на то как работает iCloud, то при конфликтах он создает дубликат папки... т.е. решение от Syncthing ни сколько не хуже и не лучше чем решение от триллиардной корпорации. Мне кажется кейс когда у нас одновременно меняются данные довольно редкий именно в данном конкретном примере.
В Resilio Sync например, пользователи могут настроить определенные политики для разрешения конфликтов, например, всегда предпочитать более новую версию файла или версию с определенного устройства.
nin-jin
29.12.2023 11:42Выбор из двух версий означает выбор какие свои данные вы готовы потерять. Прекрасное решение от триллиардной корпорации, которая взяла ваши данные в заложники.
Частота конфликтов напрямую зависит от стабильности и скорости соединения и интенсивности работы с данными.
svanichkin Автор
29.12.2023 11:42тут ничем не помогу, что есть то есть, хоть от триллиардной корпорации или хоть от опенсурс сообщества
anonymous
29.12.2023 11:42НЛО прилетело и опубликовало эту надпись здесь
svanichkin Автор
29.12.2023 11:42Сервер поднять и переехать на те продукты что были перечислены это не то о чем я говорю в статье. Я не хотел бы менять мессенджеры или начать заниматься шифрованием. Я не хотел бы поднимать свой почтовый сервер. Я лишь хотел бы что бы мои данные были у меня на моем ноутбуке/телефоне.
На счет opensource решений, да. Вполне возможно что некоторые наработки можно взять, а может быть и готовые решения.
Данные не должны быть спрятаны в программе. Данные должны быть в папках. Доверенный сервис работает с этими данными, а GUI интерфейсы лишь позволяет эти данные просматривать/редактировать и отправлять через сервис.
anonymous
29.12.2023 11:42НЛО прилетело и опубликовало эту надпись здесь
svanichkin Автор
29.12.2023 11:42Приятно спасибо, да действительно у вас есть понимание моей идеи целиком и полностью.
От общего же формата и места хранения данных - лишь глобальная точка отказа и концентрации потенциальных уязвимостей. "апдейт который ломал локальную базу" теперь сломает все и сразу - а преимуществ кроме красоты дизайна мало.
Я хотел бы уточнить, как именно апдейт в этой схеме может сломать все и сразу? Если я правильно понял речь именно про неудачно обновленный сервис? Скажем так, если opensoruce сервис будет обновляться и мы его станем обновлять и он будет сломан. То он просто не сможет загрузить например свежие данные, старые как были в локальной папке там и остались.
С сервером кака раз нет, такой идеи нигде нет в тексте. И сервер в этой схеме воощбе никак не требуется и не нужен. Возможно если речь про бэкапы данных? Ну скорее всего NAS здесь поможет как нельзя лучше. Или пара ноутбуков, для дупликации данных. Я привел в пример приложение "Фото" у Apple, это пример того как наши данные стали не нашими. Они вроде бы и здесь на ноутбуке, но доступ к ним у нас по разрешению от Apple. А хотелось бы что бы фотографии лежали у меня в папке. Пусть это и займет место на диске, но ssd сейчас не такие дорогие как раньше. И лучше я заплачу за ssd чем за Cloud сервисы экосистемы и устройства для этих экосистем.
С фичами полностью согласен, если внедряется фича меняется и сервис, но куда без этого? Телеграм тоже постоянно обновляется... Федеративные протоколы хорошо web3 еще лучше, в том числе и IPC.
Но я например очень хотел бы утром включить свой ноутбук и в одном интерфейсе лентой увидеть все новые сообщения, все новости, все события разложенные по типам, в одной программе, переведенные на мой родной язык. В этой же ленте ответить на почту, или сообщение (не думая на самом деле, откуда это сообщение из почты или ис дискорта или вообще обычная смс).
Это то что реально можно сделать используя этот подход. И это интерфейс который мы могли получить, если бы не скатились в эти проприетарные экосистемы жадные до денег и каждого байта наших данных.
M_AJ
29.12.2023 11:42+2Как вы думаете, почему мы стали хранить данные непосредственно в приложениях вместо использования стандартных папок, таких как 'Документы' или 'Фотографии', в наших операционных системах?
Одна из причин в том, что нет никакого стандартизированного набора папок, для разных ОС, в том числе например мобильных.
Но вот если бы для каждой программы был бы сервис, который бы каждое сообщение клал в виде файла в папку то все бы изменилось.
Стало бы больше проблем с константностью. Не говоря уже о том, что в разных мессенждерах разный набор сущностей. Где-то есть каналы, где-то групповые чаты, где-то голосовые комнаты и так далее.
нет утечек все секъюрно
Это не откуда не следует, более того, то пункт выше прямо противоречит секъюрности. Если у нас все месседжеры имеют доступ ко всем сообщениям, то достаточно дыры в одном приложении, чтобы утек весь массив ваших переписок, и WhatsApp и Telegram и SMS
А вообще, ваша концепция во многом напоминает то, что уже существует, а именно Fediverse. Можно поднять свой сервер и хранить данные у себя, правда далеко не всем это по карману.
svanichkin Автор
29.12.2023 11:42Про мобильные папки я как раз упомянул, особенно уделил внимание айфону.
В разных мессенджерах разный набор сущностей? текст, картинка, видео − наверно основные. Групповы чаты не особо противоречат этой парадигме, ну да, видимо группировка по протоколу будет, никаких сложностей не возникнет и не создает.
Мессенджеры имеют доступы ко всем сообщениям но если внимательно прочитаете статью, то в этой концепции ни один мессенджер не имеет доступа в интернет. Они по сути лишь GUI, вся работа возложена на сервисы, которым мы доверяем и которые имеют доступ только к своему протоколу и только с своим данным в своей папке.
В дополнение, я ни слова не написал про "свой сервер" потому как концепция для обычного пользователя, не для владельца сервера со статическим ip и доменом. Задача лишь вернуть мои данные мне на мой ноутбук. Сделать это секъюрно, сделать это максимально просто а главное что бы было рабочей схемой а не сферическим конем в вакууме.
M_AJ
29.12.2023 11:42Про мобильные папки я как раз упомянул, особенно уделил внимание айфону.
Он упоминается только один раз контексте того, что у него мало памяти и есть ограничения по доступу к файлам, хотя на самом деле это проблема не только iPhone – слота под карту памяти нет и в флагманах Samsung и в Pixel
В разных мессенджерах разный набор сущностей?
Кроме групповых чатов могут быть каналы новостей, где пишет один человек, или такие же каналы с комментариями. Может быть как в Дискорде – сервера с каналами разного вида.
то в этой концепции ни один мессенджер не имеет доступа в интернет.
А как тогда отвечать на сообщения? Читать в общей ленте, а для ответа отправляться в другой месседжер? А если я захочу ответить на сообщение процитировав его, как его нормально передать в месседжер который умеет отправлять данные, просто копипастом? Звучит мягко говоря не очень удобно.
В дополнение, я ни слова не написал про "свой сервер" потому как концепция для обычного пользователя, не для владельца сервера со статическим ip и доменом
Без промежуточных серверов невозможно соединить два устройства, если оба находящиеся за провайдерским NAT, например два мобильника.
а главное что бы было рабочей схемой
Увы, пока ваша схема такой не выглядит, она сырая и с большим количеством возможных подводных камней. Наиболее близок (из реализуемых) к ней как раз федивёрс – можно поднять свой сервер, можно пользоваться готовым, но при этом всегда есть возможность забрать свои данные и переехать на другой сервер.
svanichkin Автор
29.12.2023 11:42Самсунг, или Гугл, Айфон, это вобщем то девайсы которые загоняют людей в ту самую закрытую экосистему из которой есть выход.
Дискорт или не дискор, идея в том что с любым источником данных работает только сервис, работает ли он с группами или с каналами или с личными сообщениями никакой разницы нет.
Отвечать на сообщения просто, так же через сервис. Т.е. GUI хоть командная строка хоть некая оболочка с красивым интерфейсом может только отображать данные из папки и через сервис делать отправку.
Два устройства можно соединить если это нужно простой пример Syncthing, но можно и не соединять, иметь сервисы на каждом устройстве.
И еще раз повторюсь, это решение для простых юзеров.
M_AJ
29.12.2023 11:42работает ли он с группами или с каналами или с личными сообщениями никакой разницы нет.
Вообще-то есть, потому что он должен понимать, как правильно отображать данные, и понимать все возможные типы данных и как их правильно отображать.
Отвечать на сообщения просто, так же через сервис
Я не понимаю, что именно вы имеете в виду под словосочетанием "отвечать через сервис". Мне пришло сообщение в Телеграмм, я увидел его в централизованном GUI, теперь мне нужно на него ответить, как именно это должно происходить?
Два устройства можно соединить если это нужно простой пример Syncthing
Который использует релеи, если оба устройства находятся за NAT
но можно и не соединять, иметь сервисы на каждом устройстве.
И получить неконсистентное состояние, когда на одном устройстве нужный файл есть, а на другом его нет, или там устаревшая версия.
svanichkin Автор
29.12.2023 11:42Ну я вообще расписал примеры, но ок. Вот например у нас есть некий мессенджер. Он работает с каким то протоколом. Пусть у нас на ноутбуке есть сервис/демон который запущен и он умеет делать несколько вещей. Работать с протоколом (подсоединиться к серверу, скачать сообщения, сохранить их в папку, умеет отправлять сообщения в нужные группы или нужным людям).
Пусть в нем будет встроенный ИИ, который будет каждое загруженное сообщение обрабатывать, понимать, спам это или не спам или код ауентификации, или личное сообщение, или сообщение написанное на другом языке и т.д.
На диске мы имеем папку в которой например есть папки личных сообщений с обычными людьми, например Вася, Петя... в каждой папке лежат личные сообщения переписки с Васей или Петей. Так же есть групповые папки с названием группы, в которых лежат сообщения каждого кто находится в группе и писал что то.
Теперь нем нужен любой GUI который сможет залезть в папку и посмотреть отобразить сообщения. Пускай это вообще будет файловый менеджер. Мы просто заходим в папку Вася и видим все сообщения (каждое сообщения отдельный файл) смотрим последнее сообщение от Васи. Теперь мы хотим Васе ответить. Т.к. у нас простой файловый менеджер а не специально напианный GUI для сообщнией, а нам надо отправить сообщение, мы наверно пойдем в командную строку, возьмем наш сервис, который умеет отправлять сообщения и передадим ему from: to: message: (опять же это прсото пример), псле чего сервис оптравит для нас это сообщение Васе.
После отправки сообщения оно так же появится в папке с Васей. И когда Вася ответит, тка же появится и Васино сообщение.
Т.е. сервис и только сервис работает с сервером и данными. GUI может быть любой хоть командная строка. Или что то красивое от разрабочиков, или что то самописное, или даже что то сделанное в web.
M_AJ
29.12.2023 11:42+3возьмем наш сервис, который умеет отправлять сообщения и передадим ему from: to: message:
И это совсем не выглядит как что-то user friendly. Если же наш viewer имеет какую-либо возможность отправить данные наружу (например через любое API), то если в нем вдруг обнаружится уязвимость, то это грозит сливом всей нашей переписки из всех месседжеров, потому что viewer имеет доступ ко всем нашим сообщениям.
svanichkin Автор
29.12.2023 11:42Трудно что то возразить, пока это не реализовано... но в целом уязвимость может найтись в любом софте, так что это совсем не доказывает что сама идея плохая.
M_AJ
29.12.2023 11:42уязвимость может найтись в любом софте
Может, но уязвимости в софте, который имеет доступ ко всем вашим перепискам наиболее критичны.
svanichkin Автор
29.12.2023 11:42Как по вашему, что более безопасно: доверить логин пароль от почтового ящика программе некого автора почтовой программы ИЛИ доверить только отображение писем из вашей папки с письмами программе стороннего автора?
nin-jin
29.12.2023 11:42Причём для каждой программы должны быт свои права доступа, ограниченные только этой папкой, иначе она переложит все данные из приватной зоны в публичную.
svanichkin Автор
29.12.2023 11:42Да, конечно, ограничение на доступ к определенным папкам только на чтение, и к папке отправки данных на запись. Более того, сервис прежде чем отправить письмо, проверяет адресата, и если адреса не находится в контактах, будет алерт с вопросом, уверены что хотите отправить письмо такого содержания на такой то адрес. Это конечно излишняя защита ???? но в целом можно и так подстраховаться.
nin-jin
29.12.2023 11:42Да-да, и на каждое сообщение в публичном чате должно всплывать системное окно запроса прав. А в список контактов можно добавлять только вручную через конфиг, никаких гуёв.
svanichkin Автор
29.12.2023 11:42Если говорить про Контакты, то идея была такой, для сервиса Контактов, источником данных являются папки других приложений. Например почты, сообщений или фотографий. Т.е. он просматривает все сообщения читает теги где есть записи в тегах о контакте. Далее уже делает запрос у юзера, добавить ли вот эти новые найденные контакты или больше о них не сообщать. Можно контакты и вручную добавить, а можно через GUI, тут дело вкуса.
michael_v89
29.12.2023 11:42передадим ему from: to: message: (опять же это просто пример), после чего сервис отправит для нас это сообщение Васе
Вам верно говорят, GUI с уязвимостью может его отправить таким образом не только Васе, а еще и разработчику-хакеру. А так как у него есть доступ к этой папке, то может еще и стереть второе сообщение.
svanichkin Автор
29.12.2023 11:42Ни стереть ни отправить не сможет... Ограничение на доступ к определенным папкам только на чтение, и к папке отправки данных на запись. Более того, сервис прежде чем отправить письмо, проверяет адресата, и если адресат не находится в контактах, будет алерт с вопросом, уверены что хотите отправить письмо такого содержания на такой то адрес. И конечно GUI не может создать новый контакт, у него только на чтение к папке адресов.
т.е. GUI может только показать, и попросить сервис сделать отправку...
michael_v89
29.12.2023 11:42отправить не сможет
Ограничение к папке отправки данных на записьЭти предложения противоречат друг другу. Если есть некая папка отправки данных, при записи в которую отправляется письмо, и у GUI есть к ней доступ на запись, значит GUI может отправить письмо. Его даже стирать необязательно, большинство пользователей типа знаменитых актрис, которых вы приводите в пример, не будут туда заходить через файловый менеджер.
И это требует более сложной настройки доступа, чем есть по умолчанию в Windows и Linux.
будет алерт с вопросом
Откуда он будет, если в вашем предложении у сервиса нет GUI?
проверяет адресата, и если адресат не находится в контактах
В электронной почте нет списка контактов, письма можно отправлять на любой адрес. То есть вы предлагаете вместо электронной почты использовать какой-то другой продукт с другими стандартами. С хранением в виде файлов это не связано.
Ну ок, пользователю будет показано сообщение "Добавить контакт microsoft-backup-email@hv.com в список контактов?", причем еще при установке приложения с GUI, он возьмет и добавит. А "hv" это сервер хакера Васи.
И конечно GUI не может создать новый контакт
Ну как это не может, если пользователь именно для этого его и поставил. Чтобы отправлять письма разным людям через интерфейс, а не командную строку. А это означает, что в GUI есть кнопка "Добавить контакт".
т.е. GUI может только показать, и попросить сервис сделать отправку
Я именно об этом и написал, и другие тоже. Пользователь хочет иметь кнопку "Отправить письмо" в GUI, значит GUI каким-то образом должен уметь отправлять письмо. Неважно каким именно, сервис попросит или еще как-то. Раз может отправлять на один адрес, значит может отправить и на другой.
svanichkin Автор
29.12.2023 11:42Письма отправляет не GUI, он их только формирует. Отправкой занимается доверенный сервис. И да GUI у него может и нет, но алерт показать он может, здесь никаких сложностей не возникнет ни с одной ОС.
Настраивть доступ к папкам это сейчас вообще не проблема, программа сама спрашивает доступ к папке, система гороит об этом юзеру, юзер соглашается или отклоняет. Уже сейчас такой механизм есть для доступа к папкам документов например и т.д.
Можно конечно не мудрить, сделать что бы GUI действительно делал отправку через сервис например просто подключаясь к сервису на локальный порт. Но это уже не будет особо отличаться от любой почтовой программы которая просто цеплятся к почтовому серверу.
Ну и кстати в такой схеме ничто не мешает ЛЮБОЙ почтовой программе взять все ваши письма и переслать хакеру Васе. Плюс к этому еще и оптравить ему ваш логин/пароль. Собственно так и ломали Apple, когда почтовая программа отправляла логин/пароль хакеру Васе, который потом заходил в iCloud и сливал голые фотки.
michael_v89
29.12.2023 11:42Но это уже не будет особо отличаться от любой почтовой программы которая просто цеплятся к почтовому серверу.
Естественно, вам про это и говорят. Нет принципиальных отличий, через порт она получает данные или через файлы. Сделать так можно уже сейчас, даже одну общую программу, которая подключается к разным сервисам через порты и имитирует файловую систему. Так не делают потому что это ничего не меняет, только добавляет усложнение.
И да GUI у него может и нет, но алерт показать он может
Нет. Нам нужен не просто MessageBox с кнопкой "OK", а полноценная форма добавления контакта с полями "Email", "Имя", "Группа". А раз есть добавление, то нужно и отображение списка. Это означает, что у сервиса есть свой GUI с частью интерфейса, связанного с отправкой email.
Письма отправляет не GUI, он их только формирует. Отправкой занимается доверенный сервис.
Вы похоже не понимаете, ну или делаете вид. Неважно, через скольких посредников GUI отправляет письмо. Если пользователь может нажать кнопку в GUi, и письмо отправится, это означает, что GUI может отправить письмо. GUI от хакера может имитировать нажатие кнопки, положить копию письма в папку отправки на другой адрес, и сервис его отправит.
svanichkin Автор
29.12.2023 11:42Естественно, вам про это и говорят. Нет принципиальных отличий, через порт она получает данные или через файлы. Сделать так можно уже сейчас, даже одну общую программу, которая подключается к разным сервисам через порты и имитирует файловую систему. Так не делают потому что это ничего не меняет, только добавляет усложнение.
Ну так и в чем тогда вопрос? Если так рассуждать то либо вообще не надо польсоваться никакими прогрмамами, либо все таки выбрать то, где утечка будет меньше.
Нет. Нам нужен не просто MessageBox с кнопкой "OK", а полноценная форма добавления контакта с полями "Email", "Имя", "Группа". А раз есть добавление, то нужно и отображение списка. Это означает, что у сервиса есть свой GUI с частью интерфейса, связанного с отправкой email.
Ну вообще достаточно простого алерта "Запрошена отправка письма "Привет хакер" на неизвестный адрес hacker@vasya.com" "Отправить", "Отмена"
Почему нельзя просто в тексте это отобразить?
Вы похоже не понимаете, ну или делаете вид. Неважно, через скольких посредников GUI отправляет письмо. Если пользователь может нажать кнопку в GUi, и письмо отправится, это означает, что GUI может отправить письмо. GUI от хакера может имитировать нажатие кнопки, положить копию письма в папку отправки на другой адрес, и сервис его отправит.
Еще раз повторю, есл итак думать как вы, то здесь вообще ничего не поможет, любую программу напиши и это будет плохо. Вам нужно немного вернуться в реальность и сложить все за и против, если будет программа от хакера Васи, то где ущерба будет больше? Где программе передан логин пароль или где программа не может ничего сделать кроме как сформировать письмо?
michael_v89
29.12.2023 11:42+1Ну так и в чем тогда вопрос?
В том, что тогда дает переход на файлы, который вы предлагаете?
либо все таки выбрать то, где утечка будет меньше
Конечно. И переход на файлы для этого не нужен. Он не делает возможность утечки меньше. А если пользователь не уследит за правами доступа, то делает больше.
Ну вообще достаточно простого алерта "Запрошена отправка письма на неизвестный адрес"
Тогда это не будет список контактов. "Неизвестный" означает, что где-то хранится список известных. Я хочу иметь к нему доступ в интерфейсе. И возможность добавить заранее, а не при отправке email.
Еще раз повторю, есл итак думать как вы, то здесь вообще ничего не поможет, любую программу напиши и это будет плохо.
Еще раз повторю, именно это вам и пытаются объяснить. Ваше предложение ничего не меняет.
где ущерба будет больше? Где программе передан логин пароль или где программа не может ничего сделать кроме как сформировать письмо?
В обоих одинаково. Если у программы от хакера уже есть доступ ко всем письмам, то ему логин-пароль и не нужен.
программа не может ничего сделать кроме как сформировать письмо
Зачем я буду ставить такой GUI, который ничего не может сделать? Мне нужен GUI с кнопками "Отправить письмо", "Добавить контакт", и т.д. Как он будет это делать, через папки или сервисы, мне неважно.
svanichkin Автор
29.12.2023 11:42Значит видимо вина то не во мне, а в том что вы таки не прочитали статью... в ней вроде говорится как раз о контактах
michael_v89
29.12.2023 11:42То, что я написал, никак не противоречит тому, что вы написали в статье. Если какой-то сервис у меня спрашивает про неизвестные контакты, я хочу иметь контроль над тем, какие контакты известные, а не полагаться на какой-то непонятный ИИ. Значит мне нужен интерфейс со списком этих контактов.
С ИИ вообще интересно получается. Хакер Вася разослал спам миллиону пользователей с адреса "hacker@vasya.com", ИИ заботливо автоматически добавил его в контакты всех этих пользователей, потом некоторые поставили GUI от Васи, и теперь Вася может отправлять себе копии их писем без всяких уведомлений от сервисов.
svanichkin Автор
29.12.2023 11:42Что бы рассказать как именно можно сделать связку с контактами например, да и не только... с СМС, с календарем, с лентой rss, фотографиями и шарингом в папках, придется писать еще одну статью. И она пока еще не дописана.
Суть в том что контакты точно так же сами не появятся, и "полагаться на какой то там ИИ" не нужно, юзер главный.
И да я вижу что понимания у вас по прежнему нет. Сервисы разные. Сервис контактов это не тот же самый сервис Email. В статье помоему список был.
Предлагаю вам прям сесть и прочитать статью от и до, а потом вернуться к дискуссии.
svanichkin Автор
29.12.2023 11:42ну и советую на счет логина пароля еще раз перечитать... это было у Apple и ущерб был не соизмерим с обынчой пересылкой пары писем
michael_v89
29.12.2023 11:42И да я вижу что понимания у вас по прежнему нет.
советую на счет логина пароля еще раз перечитатьНе надо прикрывать собственное непонимание обвинением собеседников в непонимании. Неважно, 1 у вас сервис или 10, это все равно полноценный GUI, а не "просто alert" как вы утверждали сначала.
Я прекрасно понимаю, что происходило с Apple, и ущерб был не соизмерим с обычной пересылкой пары писем, но ваше предложение перейти на файлы никак эту проблему не решает.
Кстати, можете дать ссылку на источник информации, что "Это дало сторонним почтовым приложениям возможность доступа ко всему содержимому iCloud пользователей"? Насколько я знаю, дело было совсем не в этом.
qw1
29.12.2023 11:42+1Зачем я буду ставить такой GUI, который ничего не может сделать? Мне нужен GUI с кнопками "Отправить письмо", "Добавить контакт", и т.д. Как он будет это делать, через папки или сервисы, мне неважно.
Я так понял идею автора, что в первой программе он читает/пишет письма, жмёт "Отправить". Первая программа создаёт файл в папке "Исходящие". А вторая программа, изолированная от первой отдельной песочницей, или даже виртуальной машиной, проверяет белый список получателей, выводит алерт, предлагает добавить нового получателя в список.
Я с такими схемами наигрался ещё в 2000-х, когда при подключении к интернету ставил firewall и каждый коннект утверждал вручную, потом настраивал правила, потом мне это всё надоело и я смирился с тем, что любой софт может сливать в сеть что угодно. Тут автор публикации тешит свою параною и готов заниматься настройками взаимодействий между программами в целях "безопасности". Ну нравится ему, пусть развлекается. Идея точно не пойдёт в массы.
В те годы был целый класс программ "персональный файрвол", популярный и неплохо продающийся. А сейчас где они все?
michael_v89
29.12.2023 11:42+1Я понял, я говорю, что таким образом тоже можно отправить копию письма куда нужно. Белый список это ок, но если в алерте будет какой-нибудь "microsoft-backup@some-domain.com", большинство не будут разбираться что это за адрес, а нажмут "ОК".
qw1
29.12.2023 11:42Кстати, интересный момент. В алерте нужно показать, что за письмо кому отправляется ("сабжа" недостаточно, он может быть поддельным). А это значит, в сервисе-отправщике должны быть функции хотя бы предпросмотра (делегировать программе просмотра мы не можем, мы же ей не доверяем).
svanichkin Автор
29.12.2023 11:42ну вы поставили почтовый клиент от хакера Васи, ввели логин пароль, и он отправит любые письма от вашего имени вообще не задавая никаких вопросов... вас это конечно лучше устроит, я все верно понимаю?
qw1
29.12.2023 11:42Вы поставили вьювер от хакера Васи, а сервис синхронизации почты от хакера Ивана. Что поменялось?
svanichkin Автор
29.12.2023 11:42Всё верно, вы сказали.
Но есть еще что то кроме безопасности, поэтому для меня это по прежнему имеет значение. Например мои данные находятся у меня в оригинальном формате, если автор прогаммы перестанет поддерживать ее мне наплевать, т.к. данные при мне, не надо будет просить его экспортировать их в каком то виде и т.д.
Я смогу работать с моими данными двумя или тремя программами. Сейчас в каждую программу нужно эти данные импортировать или использовать какой то API или писать плагин для работы с данными. Например обработка фоток в программе Фото.
Также появляется возможность обработки данных ИИ, например для того что бы не заморачиваться с GUI, а просто сказать "составь индивидуальное пригласительное письмо для каждого моего близкого друга и моих родных, кроме моей двоюродной сестры, что бы пришли на мой ДР в 19:00 в клуб" и отправь завтра. ИИ пробежиться по всем контактам что бы посмотреть кто мой близкий друг, просмотрит родственные связи, пройдется по списку сообщений чт обы понять как написать индивидуальный текст письма. И сгенерирует письма. При чем отправит не просто почтой, а в наиболее подходящие сервисы, кому то на почту, кому то в телеграм, кому то в вотсап. И это сделать не сложно когда данные у нас свободны.
Другой пример обновление карточек контактов, здесь это можно так же переложить на ИИ, и карты контактов будут обновлять информацию, новый номер телефона например или фотка.
Работа с фотографиями так же будет лучше во много раз, по мимо редактирования о котором я выше написал, появится например нормальный поиск. Если ты напишешь красная машина, то поиск найдет все фотографии на которых красная машина. Сейчас с этим большие проблемы, которые вообще никто не понимает как решать. Эпл интегрирует свой говно ИИ для фотографий, который еле еле просто "красный цвет" понимает. А как дать доступ сторонним ИИ они не знают, потому что данные в БД закрыты.
Дальше можно продолжить если данные все открыты, можно например взять все источники и с утра составить лентой все свежие поступления за ночь. В одном визуальном формате, письма, сообщения, новости и т.д. В одном интерфейсе можно их прочитать, можно их переслать, можно на них ответить. Такое вы вообще сейчас никак не сделаете. Для этого надо будет писать прогрмаму "комбайн" которая будет подклаться к почте, к rss, к остлаьным протоколам. И доверить данные такой программе, это просто открыть ворота в свою личную жизнь. А в моем подходе такая программа не получит ровным счетом ничего, но при этом будет легкой и красиво выполнит свою функцию.
qw1
29.12.2023 11:42Например мои данные находятся у меня в оригинальном формате, если автор прогаммы перестанет поддерживать ее мне наплевать, т.к. данные при мне, не надо будет просить его экспортировать
Я смогу работать с моими данными двумя или тремя программами
Утопия. Кто будет согласовывать форматы? Комитет при Президенте, а отступившихся от формата расстреливать?
Если нет, то каждый разработчик будет добавлять в формат свои фичи, и в итоге всё равно придётся писать конверторы, или выбирать, какой одной программой пользоваться. Потому что одна программа поддерживает фичу X, а другая программа про неё не знает, и при пересохранении документа теряет эту информацию
qw1
29.12.2023 11:42Это очень частные случаи простых документов (картинок), которые уже достигли максимума и не развиваются. Даже здесь, где тут webp, jxl, jp2?
Или остановим прогресс, и кроме png/jpg все картинки запрещены?А что насчёт формата библиотеки фотографий, чтобы тэги, сортировки, коллекции были понятны разным программам?
А где электронные таблицы?
svanichkin Автор
29.12.2023 11:42мне привести все форматы файлов что ли не пойму? есть универсальные форматы для таблиц csv например и т.д. в чем вообще вопрос?
qw1
29.12.2023 11:42csv меня категорически не устроит, потому что теряет любое форматирование (в csv вообще ничего нет - ни листов, ни формул, ни форматирования).
Всё равно, что предлагать для любых документов формат txt в блокноте. А что? Мне нормально, значит и другим должно быть нормально.
qw1
29.12.2023 11:42Заставим сайты публиковать новости в формате ODS, чтобы без проблем переслать их на e-mail или сохранить в свой архив? Или всё же понадобятся конверторы?
qw1
29.12.2023 11:42Потому что
Дальше можно продолжить если данные все открыты, можно например взять все источники и с утра составить лентой все свежие поступления за ночь. В одном визуальном формате, письма, сообщения, новости и т.д. В одном интерфейсе можно их прочитать, можно их переслать, можно на них ответить. Такое вы вообще сейчас никак не сделаете. Для этого надо будет писать прогрмаму "комбайн" которая будет подклаться к почте, к rss, к остлаьным протоколам
svanichkin Автор
29.12.2023 11:42ну и? все равно не понимаю
GUI работает с папками, при чем тут сайты?
qw1
29.12.2023 11:42Аггрегатор собрал новости и положил их в папку в каком формате?
EML? HTML? PDF?
Нужно чтобы эти новости (с картинками и разметкой) можно было и в мессенджер отправить, и вставить в программу вёрстки своей стенгазеты, если я делаю недельный дайджест новостей.
svanichkin Автор
29.12.2023 11:42Ну я сейчас пишу сервис для RSS, т.к. они в оригинальном виде представляют из себя html страницы, то ясное дело ханиться это будет в каком то фромате с html, например .mht или .epub. Можно и .pdf, но он не имеет резиновой верстки, поэтому наврядли подойдет.
Программа агрегатор, да, будет уметь посмотреть любой из этих форматов, а как по другому? Но это не сверсложная задача, не полет на марс, тем более когда есть WebView, когда формат файл известен всем.
Пытаетесь придумать сложноти там где их давно нет.
В чем сложность переслать такую новость? Можно переслать как ссылку на новость, можно переслать прямо файлом .epub например. Можно переслать через email, можно переслать прямо в мессенджер.
qw1
29.12.2023 11:42Вы под какую платформу пишете? Вряд ли это iOS, а на Windows вы хотите что с чем интегрировать?
svanichkin Автор
29.12.2023 11:42Под iOS даже привычный софт сложно пилить, не говорю уже про сервисы, слишком закрытая. Вообще вот эти сервисы это для меня работа по отказу от iOS в том числе. Виндовс я пользовался с 95 по XP, дальше перешел на macOS. Сейчас я в дополнение использую OpenBSD и Fedora.
qw1
29.12.2023 11:42Ну понятно, откуда уши растут.
В Windows всё и так в файлах. Читай-не хочу.
В Android хотя бы медиа-библиотека открыта и часть проблем (например, с ИИ-поиском красной машины) не релевантна.
qw1
29.12.2023 11:42XLSX? ODS? тоже не подходят?
И кстати да, не подходят.
Топим же за унификацию.
А значит, простенький блокнот должен будет уметь открывать ODS, а IoT-счётчик расхода электроэнергии должен будет выгружать показания не в csv, а в xlsx, иначе придётся иметь зоопарк форматов и не любая программа прочтёт другую.
qw1
29.12.2023 11:42Потому что нет чёткой границы между Word и Notepad.
Если вы хотитеЯ смогу работать с моими данными двумя или тремя программами. Сейчас в каждую программу нужно эти данные импортировать или использовать какой то API или писать плагин для работы с данными
Придётся каждую программу учить всем трюкам, которые умеет любая другая программа. Иначе нет речи о взаимозаменяемости.
svanichkin Автор
29.12.2023 11:42Почему? Я уже не улавливаю сути. Полно программ под разные форматы файлов, используйте. Важно что бы эти программы не хранили файлы внутри себя.
qw1
29.12.2023 11:42Место хранения это только половина дела. А ещё нужно, чтобы файл был прочитан другой программой. Непонятный бинарник без спецификации вас вряд ли устроит.
svanichkin Автор
29.12.2023 11:42Не надо использовать не понятный бинарник... почему и зачем вас тянет использовать непонятный бинарник или изобретать новый формат файла?
qw1
29.12.2023 11:42Потому что у моей программы есть внутренний формат, и я просто скидываю объекты в файл "как есть". Изучать чей-то чужой формат и под него подстраиваться - должно быть серьёзное основание.
svanichkin Автор
29.12.2023 11:42Об этом и речь, что понятие "моей программы" и привело к тому что разработчику проще хранить данные внутри в БД. Если программа лишь GUI то ей ничего внутри хранить не придется и ей буквально требуется в 10 раз меньше работы чем было раньше. Вся запбора по работе с данными и серверами уходит в прошлое и ложится на плечи сервисов.
Никто при этом не мешает вам по прежнему использовать вашу программу, правда зачем она нужна будет не понятно, если она не умет не экспортировать данные ни импортировать.
qw1
29.12.2023 11:42Так БД для интеграции на порядок надёжнее файлов.
По краней мере, не будет фантомных данных, когда статья скачалась, а картинки к ней ещё нет. Всё чётко, в транзакциях.
michael_v89
29.12.2023 11:42XLSX? ODS? тоже не подходят?
Чем это отличается от хранения в MDB или любом другом формате баз данных?
svanichkin Автор
29.12.2023 11:42ничем, храните в любом формате... я писал в статье, что чем ближе данные к оригиналу тем лучше
michael_v89
29.12.2023 11:42+1Так они сейчас так и хранятся, в базе данных, только на сервере. Если вы будете хранить их локально в формате базы данных, вам все равно будет нужна программа (или сервис), которая умеет их открывать, а все GUI будут подключаться к ней и работать через нее. А подключение означает логин и пароль, или какой-то другой способ ограничения доступа, чтобы не любые GUI могли подключиться. Никаких отличий от того, что есть сейчас.
svanichkin Автор
29.12.2023 11:42Я не предлагал хранить их локально в виде базы данных. Я предлагаю хранить все данные в виде файлов. Работает с сервером и данными доверенный сервис. Работают с данными GUI которые не имеют доступа в интернет.
qw1
29.12.2023 11:42Ещё раз. Какие это даст преимущества?
Безопасность вы так не продадите. Потому что нужно следить за друмя программами, и за общей средой обмена. Да и взлом локальных программ - редкий зверёк, в дикой природе почти не встречающийся.
svanichkin Автор
29.12.2023 11:42Неужели преимущества до сих пор не очевидны, после столь плотной беседы?
Резюмирую самые очевидные преимущества:
Мои данные свободны, нет зависимости от вендоров или авторов программ
Возможность работы ИИ с моими данными
С чувствительными данными работают лишь доверенные сервисы, программы авторов или вендоров лишь реализуют GUI
qw1
29.12.2023 11:42Хорошо. А теперь, внимание, вопрос.
Для кого вы писали статью?
Преимущества только для пользователей, и уж никак не для разработчиков. Пользователи никак не могут повлиять на внедрение идей из данной статьи, для них это всё равно, что статья "почему все программы должны быть бесплатными" или "почему тех. поддержка должна решать любой вопрос за 10 минут". Да, было бы неплохо. Но, помечтали и разошлись.
svanichkin Автор
29.12.2023 11:42Я же это в первом абзаце написал. Я уже писал что я очень долго пытался понять как сделать так, что бы у людей был шанс разорвать зависимость.
Это манифест или инструкция или ответ или идея, можно назвать как угодно. Важно что это продуманный документ доступный людям.
qw1
29.12.2023 11:42Я же это в первом абзаце написал
Прямого ответа нет, а додумывать я не рискну, а то что-нибудь предположишь, и получишь обвинение "я этого не говорил".
статья ... расскажет о методах, позволяющих вновь контролировать личную информацию, обезопасить её от утечек и избежать ограничений, налагаемых поставщиками услуг
В чём метод-то? Взять и переписать весь софт самому для себя? Коммерческому производителю ПО следовать идеям статьи не выгодно.
svanichkin Автор
29.12.2023 11:42Во первых, с новым годом!
Во вторых, коммерция здесь не страдает. Сервисы по хорошему должны были писаться производителями ОС. А к ним уже коммерческие GUI со своими плюшками.
Но раз уж не сложилось, надо с чего то начать. Вот началом может стать эта статья.
michael_v89
29.12.2023 11:42+1Я не предлагал хранить их локально в виде базы данных.
Как это нет, вы только что сказали "храните в любом формате". Вот у меня есть файл в формате PostgreSQL. Как GUI для почты должен его читать? Встраивать половину PostgreSQL в свой исполняемый файл?
Работают с данными GUI которые не имеют доступа в интернет.
Я вам уже объяснял, GUI необязательно иметь доступ в интернет напрямую, он может отправлять данные через сервис.
Более того, для почты это вообще невозможно. Потому что в почте есть картинки, которые GUI должен показывать, и разрешено делать ссылки на них на сайты в интернете. На этом основан механизм tracking pixel для отслеживания прочтения писем.
Даже если вы предложите, чтобы сервис скачивал все картинки для GUI, это тоже можно обойти. По условиям у нас есть GUI от хакера без доступа в интернет, в котором есть кнопки "Отправить письмо" и "Удалить письмо". Как он это делает, нам неважно.
Хакер хочет передать какое-то письмо пользователя себе на сервер.
GUI отправляет письмо самому себе, то есть с адреса пользователя на него же. Адрес пользователя конечно же находится в доверенном списке. В письме есть картинка с адресомhttp://server-vasi.com/images/test.jpg?data=<текст письма>. Сервис делает запрос на скачивание картинки, сервер хакера Васи отдает картинку и сохраняет текст письма себе в базу. Потом GUI удаляет это письмо. Алерта от сервиса на удаление конечно же нет, так как для таких алертов мы и ставим GUI, и второй алерт от сервиса нам не нужен.
svanichkin Автор
29.12.2023 11:42Я второй раз не буду все повторять, я вроде бы по отдельности уже ответил на все эти вопросы.
michael_v89
29.12.2023 11:42В том и дело, что нет, вам лишь кажется, что ответили. Вам это несколько человек пытаются объяснить.
michael_v89
29.12.2023 11:42Это уже явная ложь. Я нажал "ctrl+f", поискал слово "картин", нашлось 11 совпадений, и ни в одном месте вы не описываете, как вы будете обходить скачивание картинки с произвольным URL для письма, которое сформировал GUI. Его даже отправлять необязательно, достаточно положить в черновики.
qw1
29.12.2023 11:42Эпл интегрирует свой говно ИИ для фотографий, который еле еле просто "красный цвет" понимает. А как дать доступ сторонним ИИ они не знают, потому что данные в БД закрыты.
А зачем вы сидите на iOS? Идите в Android, там проблемы конкретно с фото/видео нет, любой программе можно дать доступ к локальной папке с медиа.
Соответственно, вопрос: на Android уже есть качественный ИИ-поиск? Или всё же дело не в закрытости? Может, это никому из разработчиков не надо (не придумали, как монетизировать?)
qw1
29.12.2023 11:42На игле Google у меня есть root, и я не чувствую себя привязанным. Потому что могу и приватность контролировать (файрволами и расширениями типа XPrivacy, которые позволяют приложениям думать, что они имеют доступ к контактам, интернету и т.п., а на самом деле, я их фильтрую), и бекапы делать, и браузером любым пользоваться, а не только одобренным свыше.
qw1
29.12.2023 11:42Я на гугл-сервисы вообще никак не завязан. У меня на каждом Android-устройстве отдельный аккаунт, не подтверждённый номером телефона. Ничего ценного на этих аккаунтах нет, поэтому и потерять не жалко.
Batalmv
29.12.2023 11:42+5Господи, ну почему ...
Первое: когда вы что-то хотите поменять - поймите как работает то, что вы хотите поменять.
Возьмем почту. Ваш контрагент написал письмо и отправил его вам. Чуть более технически:
* Ваш контрагент написал вам письмо и оно сохранено в file-based хранилище почтового клиента. Как именно - не важно. Важно то, что доступ к нему доступен через почтового клиента.
* Клиент синхронизировался с почтовым сервером и в том числе отправил письмо по Инету на сервер
* Сервер "почтовыми" тропами в открытом Интернете через кучу промежуточных хостов дослал письмо до вашего почтового сервера
* Ваш почтовый клиент в какой-то момент "проснулся", синхронизировался со своим сервером и скачал письмо вам локально и ... поместил его в file-based хранилище почтового клиента.
Теперь, что вы предлагаете
Я найду эту цитату:
Для начала я предлагаю освободить данные, точнее освободиться от тех программ, которые хранят данные внутри себя. Данные должны храниться в папках.
На самом деле они не хранятся внутри программы. Это база, которую проходят еще ... я на самом деле затрудняюсь сказать, когда именно в силу возраста и большого стажа. Но код программы и ее данные уже очень-очень давно лежат отдельно друг от друга. Просто ну очень давно. Они хранятся в файле, или во многих файлах. Но самом деле в одном "файле" банально удобнее силу наличия требования полнотекстового поиска, тегов и еще туевой хучи функциональных требований к клиенту. В реальности это скорее БД, которая хранит свои данные на файловой системе.
Отмечу, что многие почтовые клиенты, особенно корпоративные, обладают чудесными возможностями на конфигурации "где хранить", "как синхронизировать" и т.д.
Но можно пожелать большой удачи реализовать функциональный почтовый клиент + жесткое требований хранить каждое письмо в виде отдельного файла. Большой-большой удачи и не менее большого бюджета
Интересный момент заключается в том, что как бы вы не "оптимизировали" последний шаг хранения, ваше письмо (даже если вы этого не хотите) проехало кучу совершенно неизвестных вам серверов. Которые управляются компаниями и людьми, которые вам НИЧЕГО не обязаны от слова совсем. Конечно, о них можно узнать, открыв технические заголовки письма - но дальше все претензии к ним можете смело написать на шершавой бумаге и свернув в трубочку, использовать по назначению.
Также интересным моментом является почтовый сервер и связанное с ним требование иметь возможность получать почту с разных устройств. Это требований + осознание того факта, что одно из такх устройств может быть выключено в момент получения письма, делает необходимость хранения писем на сервере почти неизбежной. Не, конечно по приколу можно придумать почтовый протокол, который объединит все ваши почтовые устройства как торрент-клиенты (не в чистом виде конечно, а идеологически), а сам сервер выступит торрент-сервером. Письмо в таком случае будет "раздачей". Все это не следует воспринимать серьезно, так как все таки люди пришли к пониманию, что такой жесткий "секс" им не нужен и позволяют почтовому серверу хранить письма.
В целом, уже этих двух моментов, а именно функциональных требований к почтовому клиенту и необходимости доступа к почте з разных девайсов безальтернативно приводит "молодых" революционеров к текущей архитектуре.
Второе: безопасность - это системность и классификация
Все довольно таки просто. Вы начинаете с классификации информации по степени важности + выделяете особые категории, например персональная инфа. Тем кто работает в доменах типа healthcare это важно (но в реальности во всех, просто не везде есть дополнительные отраслевые стандарты).
Далее в зависимости от классификации вы определяете требования к:
* идентификация - кто к нам стучится за данными
* авторизация - подтверди, что это ты
* авторизация - проверка права на запрошенное действие
* целостность - проверка на то, что действие при его передаче от актора не изменилось
* конфиденциальность - проверка на то, что не прознали сторонние лица
* ...
И определив их (тут уже явно есть матрица), вы их реализовываете. При этом есть еще стандартное изменение: "данные в движении" и "данные в покое". Просто сильно все отличается
Если вы чего-то боитесь относительно своих данных — вот выпишите себе и потом реализовывайте. Кстати, полученная матрица очень сильно облегчает жизнь QA
Третье: почитайте, что такое файловая система
Я очень вкратце расскажу, а то по ходу тут у вас замешана какая-то "магия".
Операционная система - это софт, который в очень упрощенном понимании находится между "железом" и остальными программами. На самом деле, в эпоху виртуализации, за которой наступила эпоха клауда там до железа еще много прослоек, но это не есть то, о чем я хочу вам написать. Операционная система имеет свое API (довольно таки низкого уровня - вы даже себе не представляете, насколько более низкого уровня, чем "Проводник"), которое собственно и декларирует всем остальным, что такое файл и как с ним можно работать. Так было не всегда, но когда пришел в мир Uniх и сказал: "все есть файл" - эта концепция захватила мир (но не полностью). Т.е. файл это не что-то в проводнике (он работает на куда более высоком уровне), а абстракция на уровне API операционной системы со списком методов и свойств.
Далее, чтобы это все работать (API - это только декларация) операционная система имеет в составе (тоже условно в виду модульной организации) драйверы, который реализуют API (целиком или не очень). Т.е. "под капотом" у драйвера своя реализация, а снаружи - унифицированное API. И уже используя это API было написано 100500 программ, которые работают с файлами. Проводник - просто одна из них. Она не обладает никакими уникальными свойствами, кроме возможно, ну я даже не знаю - может просто "девочки из бухгалтерии" о другом ничего не знают.
В общем то все. Идея пользоваться Проводник, вашу разработки - это банальные "яйца в профиль", которые ничего не меняют по сути. Вообще ничего.
Вывод:
Вы очень долго писали, то реально "родили" просто тот же почтовый клиент. Все. Точнее это я вам польстил, тут пока клиентом не пахнет, но если вы продолжите, то в конце вы его просто получите и все :) Это просто реально эпично, вы столько писали, что давайте не будем использовать "колесо", что в итоге все равно пришли к нему (только недоделанному)
nin-jin
29.12.2023 11:42+1Данные на сервере можно хранить в зашифрованном виде и не бояться слива базы.
svanichkin Автор
29.12.2023 11:42Моя вина, вижу что мысль я не донес...
Batalmv
29.12.2023 11:42Бюось, если судить по ваше у ответу чуть ниже
Я надеюсь вы же понимаете что в БД внутри программы эти данные хранятся? А файловая система это уже БД, но доступная к просмотру без специального ПО.
так и не донесете :)
Вам реально надо начать с истоков, чтобы понять "что такое файловая система" и как она реализована. А потом что-то проектировать :)
svanichkin Автор
29.12.2023 11:42У меня есть понимание о некоторых ФС... я не вижу никаких проблем назвать некоторые файловые системы базой данных
Файловую систему можно рассматривать как базу данных в следующих случаях:
Иерархическая структура: Файловая система хранит данные в иерархическом порядке (папки, подпапки, файлы), что напоминает структуру некоторых типов баз данных, например иерархических БД.
Метаданные: Файловая система обеспечивает хранение метаданных о файлах (размер, дата создания, права доступа), что также является характеристикой баз данных.
Поиск: В некоторых файловых системах есть возможности индексации и поиска, схожие с теми, что предлагают базы данных.
Batalmv
29.12.2023 11:42Тогда поясните что вы имели в виду, когда написали "А файловая система это уже БД, но доступная к просмотру без специального ПО." :)
На самом деле база данных, файловая система, "сырой" диск и (добавшееся в последнее время) объектные хранилища - это все ХРАНИЛИЩЕ ДАННЫХ. И доступ к лубому из низ требует СПЕЦИАЛЬНОГО ПО :)
---------------
По большому счету, нет принципиальной разницы между "Проводником" и Dbeaver. И то, и другое - пользовательский софт для работы с данными :) Просто первый базируется на API, которое дает операционка, а второй - на нотации SQL, которая реализуется через драйвер, который вы прописываете как параметр подключения
Самое смешное, файловая система по сути имеет такую же идеологию, которая более наглядно видна в Unix-системах (которые собственно и пошли от концеции "все есть файл"). Команда mount обеспечивает подключение "сырого" устройства, а к примеру mc - работу с файлами в привичном "для девочек из бухгалтерии виде".
Ваши попытки найти "филосовский камень" в файловой системе, которая волшебно чего-то там дает с точки зрения безопасности (ответ "нет") в общем-то ничем не отличается от реальных алхимиков, которые банально не знают химии :)
svanichkin Автор
29.12.2023 11:42не файловая система даст безопасность
специальное по для просмотра файлов в фс основа на которой зиждется любая ОС, а вот MSQL или любая БД это набор таблиц и записей
файл можно перекинуть здесь и сейчас как угодно, попробуйте перекинуть запись из БД или табличку, а я посмотрю
никакой алхимии нет, если внимательно почитать статью будет понятно что я вообе пытаюсь донести
"всё есть файл" (c) Plan9
Batalmv
29.12.2023 11:42Так дает или не дает? И что дает? А что не дает?
А можно пример этого "специального ПО"? Только не говорите "проводник", а то меня порвет :)
Вы так и не поняли. Файл вы перекидываете не сами по себе, а используя прилождение, которое использует API. С базой все тоже самое - работа с записями осуществляется через ПО. К примеру, вот описание банального системного вызова для открытия файла: open(2) - Linux manual page (man7.org) . А теперь представьте себе сколько еще тон кода написано, чтобі ві могли "перекинуть" файл :)
Алхимики тоже так думали. Им было неплозо, лишние знания не мешали :)
-------------------
Я вам кину сорцы того, что "просто" перекидывает файл: coreutils/src/cp.c at master · coreutils/coreutils (github.com) . Вот прям реально просто :) Но это только если в командной строке. А вот сорцы "проводника" боюсь такой лаконичностью не порадуют
svanichkin Автор
29.12.2023 11:42Ну, если бы я смог донести своей статьей свою мсысль, у вас бы не возникло такой простой связки что ФС добаляет или не добавляет безопасности
Пример специального ПО для просмотра БД можно посмотреть здесь: https://uchet-jkh.ru/i/programmy-dlya-raboty-s-bazami-dannyx-kakuyu-vybrat/
Нет это наверно вы не поняли, файл я могу перекинуть в любой ОС, т.к. это то начем основаны принципы работы ОС, а вот поделиться с другом записью из БД значительно сложнее, придется использовать специальный софт из пункта выше. И наверно другу тоже придется эту экспортную запись к себе в БД добавлять таким же софтом.
Начнем с того что я прекрасно понимаю как все устроено под капотом, в свое время я пилил свой 9p сервер.
БД к тому же умеют ломаться, а вот современные ФС уже этим болезням не подвержены.
Batalmv
29.12.2023 11:42+1Нет это наверно вы не поняли, файл я могу перекинуть в любой ОС, т.к. это то начем основаны принципы работы ОС, а вот поделиться с другом записью из БД значительно сложнее, придется использовать специальный софт из пункта выше
Зачем, если вам надо перекинуть email? Или СМС? Там уже давно устоявщиеся стандарты хранения данных, равно как и способы их передачи. Ту же почту проще почтовыми протоколами передать
А тот же файл? Как вы пререкидывать собрались условно с телефона на ноут? Конечно вы можете, но только или шнурок тащить, или через сетевую шару (и два "проводника")
База - те же яйца, уже давно решений, которые позволяют переносить данные, или синхронизировать - немеряно. Можно даже элементарно поднять синхронизацию между разными движками с задержкой в доли секунды по транзакционно
БД к тому же умеют ломаться, а вот современные ФС уже этим болезням не подвержены
Опять мимо, почти все современные СУБД имеют решения из коробки active-standby, а многие и мультикластер. ФС же как правило ничего этого не умеет, а резервирование данных вы строите ниже уровнями.
AVX
29.12.2023 11:42+2Прочитал всё, и комментарии тоже. Сразу для меня описанное в статье выглядит как "наив" - ну как бы слишком наивное понимание всего этого. Софт сейчас для того и пишут, чтобы именно через него и использовали, и при этом у каждого автора (соавторов) софта своë виденье, как правильно обращаться с данными - если вначале это были файлы, и типа данных были "сообщения, файлы, адреса", и т.п., то далее дополняются " координаты, статусы (в конкретном мессенджере!), цитирование сообщений (или частей сообщений, в т.ч. из других мессенджеров, и надо ещë отобразить автора цитаты (или не отобразить - смотря какие настройки этого клиента, настройки автора цитаты и т.д.)), и ещë кучу можно поидумать (в дискорде например показывает в какую игру сейчас человек играет), а я например захочу транслировать температуру воздуха у себя на балконе. Где, как, в каком формате это должно храниться и передаваться? Вот каждый сервис и делает своë, в силу своего понимания и каких-то своих убеждений (чаще всего через призму коммерциализации в будущем или сейчас).
svanichkin Автор
29.12.2023 11:42-1Я надеюсь вы же понимаете что в БД внутри программы эти данные хранятся? А файловая система это уже БД, но доступная к просмотру без специального ПО.
fransua
29.12.2023 11:42+1На Solid похоже (https://solidproject.org)
Файловая система может быть виртуальной и реализована поверх БД, что дает какую-то отказоустойчивость, или быть "умной" вроде ZFS, тогда даже дедупликация будет.svanichkin Автор
29.12.2023 11:42Да идея у solidproject это, хранение данных вне приложений и действительно совпадает с моей. А дальше начинаются отличия в том, что я предлагаю свои данные всегда иметь при себе, в solid же хранение данных децентрализованно разнесено, но находится в online хранилищах. Это может быть даже лучше, но поверх такой системы сложно будет запустить приложние и работать с этими данными, особенно если у нас проблемы с интерентом.
ФС zfs чудесна и в целом перекрывает возможности многих БД, как и APFS например. Кстати если есть интерес могу порекомедовать почитать как работает Fossil и Venti на plan9. И, кстати если бы все современные приложения строились по идеологии "всё есть файл" предоставляя из своей внутренней БД данные наружу в виде файлов, то хотя бы проблем с импортом/экспортом не возникало.
Спасибо за то что поняли идею, мне показалось я не смог донести ее многим читателям.
fransua
29.12.2023 11:42В принципе никто не мешает развернуть pod локально.
А у оффлайн-онли хранилища есть вполне очевидный минус - нет доступа с других устройств.svanichkin Автор
29.12.2023 11:42ну почему, например synthing, можно расшарить папки с друзьями и просто кидать в эти папки нужные для шаринга файлы
svanichkin Автор
29.12.2023 11:42Кстати в Solid хранение данных остается в формате файла, а к нему добавляется мета инфромация в виде RDF записи. Я тоже долго думал над фроматом хранения данных и пришел к выводу, что лучше хранить данные в максимально оригинальном виде, а метаинформацию добавить в виде xattr тегов.
fransua
29.12.2023 11:42А в чем принципиальная разница между xattr и RDF?
svanichkin Автор
29.12.2023 11:42RDF это метаинформация которая должна храниться либо в какой то БД, либо в отдельном файле...
xattr поддерживается ФС, хранится тоже по сути в БД, но это все рулится именно файловой системой
Плюс если передать файл из одной ФС с поддержкой xattr в другую, теги должны передаться без проблем, а вот с RDF так не получится
fransua
29.12.2023 11:42Согласен с этим, когда поддержка xattr есть это удобно.
Но если их поддержки нет, или она по-другому работает, то все ломается) Ну вот не получается в linux на ntfs права выставить. А с rdf как раз удобно - права на файл прописаны в файле, все есть файл, аминь) И этот файл существовал бы и в linux и в windows одинаково, на любой ФС.svanichkin Автор
29.12.2023 11:42Я вообще искал хоть один формат файла который бы включал в себя наборы файлов и папок... что то вроде bundle, что бы был указан основной файл и бли дополнительные файлы (метаинформация), вложения может какие то и т.д.
В итоге нашел только epub, который более менее может текст + вложения хранить, pdf который так же может, но имеет жесткое форматирование и на этом все...
У эпла есть rtfd, который тоже по суть папка с файлами, но эта магия происходит только в macOS
Дальше уже только файловые контейнеры вроде dmg, но увы они не могут дать простой доступ к данным для индексации например или предпросмотра
Поэтому принял решение что лушче хранить в оригинальном формате файла + xattr, тут пока просто ничего лучше не придумали
nin-jin
29.12.2023 11:42tar? zip? rar?
svanichkin Автор
29.12.2023 11:42Что бы ос индексировала их содержание, придется сделать распаковку?
nin-jin
29.12.2023 11:42svanichkin Автор
29.12.2023 11:42увы, вопрос индексации остается открытым, есть и линукс и макос, и на обеих таких фич из коробки нет
svanichkin Автор
29.12.2023 11:42ну... зачем так, кое что есть уже готовое например OfflineIMAP, это прям один из видов сервиса для почты, вполне себе годный
nin-jin
29.12.2023 11:42Он поставляется в коробке со всеми ОС? Похоже вы совсем в демагогию ударились. Печально.
svanichkin Автор
29.12.2023 11:42-2нет, а ваша ос поставляется с rrs ридером? странные вопросы вообще то... любой софт можно установить или принципиально что бы он поставлялся с ОС? бред...
Kirikekeks
29.12.2023 11:42"Папа был прав, Папа был прав!" как в песне поётся. Возвращение Unixway, страны отцов. Сначала ее разрушили интеллектуалы БД, теперь добили портовые грузчики. А это было первым принципом, фундаментом.
MANAB
29.12.2023 11:42Каким образом сохранение данных локально мешает сервисам их тоже себе на серверах корпораций сохранять? Получается просто избыточное сохранение.
svanichkin Автор
29.12.2023 11:42не совсем понял вопроса... сервис это программа работающая с источником данных, которая может забрать данные из источника, сохранить локально и уметь сделать отправку в источник
MANAB
29.12.2023 11:42Кто производит сервисы (и по сути их контролирует, как и то, куда и какие данные сервис отправляет и сохраняет)?
svanichkin Автор
29.12.2023 11:42Кто производит, кто контролирует? Никто, пока это идея... но вообще есть вот например реализация для почты OfflineIMAP. Почти то что нужно, opensource проект.
MANAB
29.12.2023 11:42+1Можете тогда придумать выгоду для производителей сервисов? Иначе идея умрет в зачатке...
svanichkin Автор
29.12.2023 11:42Вообще сервисы по хорошему должны были написать поизводители ОС, а вот GUI к ним могли бы написать разработчики. Сейчас по сути разработчики пишус сразу и сервис и GUI в одной программе.
MANAB
29.12.2023 11:42+1Понятное дело разработчики. Но смысл делать, если это денег не приносит? Максимум на энтузиазме и для портфолио, но тогда вся текущая it экономика разваливается, потому что умения писать сервис такой не нужны в корпоративном секторе. Ну а производители ОС не должны писать аналоги телеграма, почты и проч если это не принесет доп денег. Или я чего то не понимаю.
qw1
29.12.2023 11:42Те, кому действительно это надо, уже хранят свои данные локально. Пилят свои велосипеды, собирают решения из говна и палок (я сам такой).
Массовому пользователю это нафиг не нужно. Не в такой степени, чтобы он был готов всё это финансировать из своего кармана. Ведь сейчас он платит своими данными, своим вниманием, своей зависимостью от сервисов. Переубедить его, чтобы он платил деньгами - нереально. А без денег нет никаких шансов конкурировать с гигантами, у которых миллиардные бюджеты на рекламу, на сервера, на отделы разработки.
Ну, могут энтузиасты собраться и написать 2.5 программы, построенных на этих принципах. И худо-бедно поддерживать их лет 5, пока интерес не переключится на что-то другое. Но массового успеха эти программы не получат.
svanichkin Автор
29.12.2023 11:42Ну, пусть у человечества будет хотя бы одна внятная инструкция как можно сделать по другому, и так что бы это действительно работало. И кстати, я уже сейчас вижу, насколько внедрение ИИ упрется в работу с данными в сегодняшнем подходе.
Вот смотрите, если например сделать то о чем я написал, то интеграции ИИ вообще не будет проблемой, без сторонних API.
А будет, так − завтра корпорации начнут вбухивать бабки в это, Apple выкатит какой ниудь очередной фреймворк с кривым API, который так же коряво будет поддерживать. Причем выкатит для двух с половиной стран как раньше было с Сири. Для других ОС вообще никто ничего не напишет. И все будут сидеть страдать и думать, как же дать доступ к данным для ИИ, у нас ведь все данные зашиты внутри программ!?
qw1
29.12.2023 11:42Корпорации уже ведут войны за данные. Вспомните, как Twitter, Reddit, StackOverflow выступали против, чтобы на "их" данных обучали ИИ (на самом деле, данные пользователей, но пользователей уже никто и не спрашивает, их данные присвоили).
Apple выкатит какой ниудь очередной фреймворк с кривым API, который так же коряво будет поддерживать
Так это её бизнес-модель, она за это получит деньги. Если же всё будет лежать открыто и доступно настоящему владельцу данных, то, во первых - за что, спрашивается, платить покупателю данных? Во-вторых - как себе присвоить данные пользователей и заработать на этом?
Корпорациям - чем запутаннее и закрытее, тем лучше.
svanichkin Автор
29.12.2023 11:42Да все так! Наши данные уже не наши... сейчас например уже двухфакторка это смс/токен/приложение пароль, код и т.д. столько слоев проверок что отвались хотя бы один, к своим данным доступ получить становится очень сложно, а если два из них похерятся то всё... пиши пропало
Я недавно обновлял телефон, так вот проблемы начались начиная с симок и заканчивая всеми банковскими приложениями... Под эгидой упрощения и секъюрности, нагородили заборов и сложностей.
Даже просто перекинуть видео друзьям, ты заходишь в Фото, оно начинает тупо выкачивать данные из облака (даже если локально хранить, эта зараза что то там выгружает). Дальше куда, в Телегу если, то оно начинает конвертировать, если по airdrop, то оно вообще работает через раз. А можно было просто взять файл из локальной папки и скопировать в папку друга которая расшарена через Syncthing.
Поэтому я и начал искать варианты как можно было бы нормально сделать всё без потери удобства. Я ведь продумывал это не один день, почти год... пытался найти варианты и подходы, перелопатил все операционные системы, посмотрел реализации различные. И в итоге более менее разработал концепцию как это действительно могло бы работать, к тому же безопаснее чем сейчас.
dartraiden
Это решается мультипротокольными мессенджерами.
Собственно, даже у нас в Миранде используется SQLite, потому что на более-менее приличной истории с сотней тысяч сообщений ваша схема с текстовыми файлами встанет раком. На сколько-нибудь серьёзных историях вам не обойтись без БД.
svanichkin Автор
Если сейчас зайти в папку с 100К файлами и скроллить в файловом менджере проблем не возникает... подгрузка данных проходит моментально налету, точно так же не будет никаких тормозов и проблем с любым гуи, если конечно его не написать так что бы он специально тормозил. Плюс никто не мешает сделать кеширование в самом приложении, например для предпросмотра картинок. Например когда то была такая программа как Picasa от google она является прекрасным примером.
Ну и как бы хотелось бы напомнить что ФС это уже и так БД.
dartraiden
Вам не файлы скроллить нужно, а по истории бегать. По содержимому.
Причём, даже SQLite поначалу для нас была слишком медленной, пока мы не реализовали поддержку курсоров и прочие оптимизации.
svanichkin Автор
Я наверно не совсем понимаю что значит "бегать по истории". Речь про поиск по данным? Для этого есть процессы индексации например. Если речь про скроллинг сообщений, то об этом я уже написал, никаких проблем с этим быть не может если у нас не старенький HDD.
jackcrane
был такой протокол NNTP и его сервер INN (и сейчас есть), он почему-то раком не вставал.