Спасибо, статью посмотрел. Итого имеем 3 недели от идеи до релиза. И что интересно, в конце статьи проявились примерно те же проблемы в работе push-уведомлений, что описаны и в моём более раннем комментарии на данной странице. До этого статью не заметил, поэтому честно не подглядывал)
А не взлетело скорее всего из-за сомнительного нейминга. Добавить бы в заголовок слова "мессенджер" и "альтернатива" - и результат потенциально мог быть совсем иным)
Список функций впечатляет. Даже с учетом того, что половина из них скорее всего не нативные, а из внешних библиотек. Жаль только не указано, сколько по времени такое пишется. Я так понял, что репозиторий был создан 2 месяца назад под заливку уже готового продукта?
О, я ждал этого вопроса джва года!)) Расскажу свой пользовательский опыт. Если коротко - целый зоопарк разных клиентов вместо одного нормального. Под Android: в одном клиенте нет кнопки для удаления сообщений. В другом она есть (хоть и работает как-то странно, не всегда корректно передает команду удаления сообщений на клиенты, которые в данный момент офлайн), но не прикручен FCM. Из-за чего, поскольку на Android 14+ постоянное соединение с сервером просто рвется системой принудительно по таймауту даже при наличии у приложения foreground service, сообщение не увидишь до тех пор, пока сам специально не откроешь клиент. Знакомая ситуация, правда? Тут недавно по новостям один известный мессенджер дал такого же МАХу (типа каламбур), когда его вынесли из Гугл маркета, видимо с отзывом FCM-токена. Точно не скажу, поскольку сам лично пользуюсь опен-сорсными решениями.
По итогу скажу, что проблемы бы решила версия Android, которая позволила бы менять адрес сервера push-уведомлений по умолчанию. Как-то грустно осознавать, что работа вообще всех уведомлений системы зависит от доступности всего лишь одного поддомена третьего уровня. К имеющейся системе можно прикрутить сбоку свой сторонний сервер уведомлений, но и это уже проверено на практике. Не говоря даже про необходимость интеграции с другими приложениями через какие-то костыли, которые еще могут и отсутствовать, получается настолько энергозатратно, что телефон буквально вынужден жить у розетки.
P.S. Десктопный jabber тоже удалось потестировать, но совсем немного. Из обнаруженных проблем - клиент может отказаться соединяться с сервером, если используется неправильный (точнее сказать, незаполненный в некоторых полях) сертификат. Решается использованием правильно настроенных серверов, поэтому как будто бы не проблема. Но это только то, что само проявилось за короткое время тестов, возможно дальше удалось бы выявить и другие грабли.
Команда на загрузку отправлялась тоже по почте, то есть со стороны клиента используется легитимный SMTP
Сработает, если будет доступ к почте во внешнем контуре.
Можно через поисковик
Туда попадут только ссылки, не закрытые от индексирования. Да и скорость индексирования некоторых страниц оставляет желать лучшего.
В любом случае это не актуально
Нельзя зарекаться) Будет спрос - будет предложение. Были бесплатные - станут так или иначе платными, даже в self-hosted варианте. Тут вот в чем дело: глобально мы слишком привыкли в нулевые к тому, что если нужен какой-то сервис, то его почти наверняка уже сделал какой-нибудь умный бородатый дядька-админ. Сейчас нужно просто осознать, что если нужно создать или возродить какой-либо сервис, то в настоящее время эти бородатые админы - это уже мы сами. И нет никаких других, более настоящих инженеров)
Проблема всех таких сервисов в основном сводится к следующему:
1. Нецелесообразность. Если можно протолкнуть текстовую команду на сервер, то мб реально отправить и поток данных напрямую? И вот уже нам нужен не mail-сервер, а обычная реверс-прокся. На крайний случай - прикрутить качалку с веб-мордой, там тоже есть свои плюсы.
2. Оплата. Если первая проблема может показаться надуманной (например, по причине асимметричности скоростей приема и передачи потока данных или просто из-за сильного урезания этой самой скорости и крайней затрудненности получения потока в реальном времени), то это проблема уже более чем реальная. Купить местной кредиткой можно только местный сервер, оно нам не надо. Оплата криптой - сомнительно, но окэй, есть риск попасть под 115 сами-знаете-что, поскольку там от децентрализации и приватности остался только дух прошлого. Зарубежная кредитка - неплохой вариант, если решить проблему с ее пополнением и недешевым обслуживанием. Пока жаба все-таки перевешивает.
P.S. Еще интересный вопрос: а как получать ссылки на файлы с недоступного сервиса? Получается, что должен работать какой-то парсер, который будет условно говоря по таймеру делать рассылку содержимого страницы? В целом как-то так.
Если таки соберетесь создавать, да еще и под Android, сразу для решения проблемы белых списков рекомендуется прикрутить возможность использования своего сервера для push уведомлений. Имеющиеся решения работают в формате отдельного приложения и крайне не энергоэффективны по отношению к батарее телефона. Подозреваю, что из-за особенностей реализации doze mode в android версий 14 и выше по второму пункту вряд-ли можно что-то сделать, таковы особенности платформы, придется телефон поселить у розетки. Но по крайней мере держать два разных приложения для сообщений-звонков и уведомлений о них кажется чересчур. Приложение, которое сумеет совместить в себе обе функции, сразу будет выгодно отличаться от тех же Matrix и Conversations. Либо как вариант можно написать модуль интеграции своего push сервера в любое из имеющихся решений, если это проще. В общем, если есть желание - творите.
Вот видите, вы уже задаетесь вопросами. Это означает наличие интереса. А раз так, то "подпишись..." ну и далее по тексту. /s
P.S. А по факту на канале наверняка будут опубликованы прохладные лайфстори вроде этой. Ну и еще новости о том, как "наша замечательная Вердепешевая модель" обогнала "их мерзкую Накаратовую" на целых полтора попугая в бенчмарках.
Это если смотреть в разрезе LLM и прочих нейросеток. А вот криптовалюта Chia и ~полдесятка других Proof-of-Space токенов с этим утверждением явно не согласны.
С опозданием, но всё-таки я попробую немного раскрыть мысль предыдущего комментатора. Ключевой момент: вы оба по-своему правы) Есть два разных взгляда на вопрос:
1. Связка "список сетевых интерфейсов с наличием в нём tun0 + отлуп при попытке использования этого tun0" однозначно дают понять, что тут дело нечисто, возможно кто-то пытается противодействовать телеметрии.
2. Пункт 1 неактуален, поскольку на интерфейсе tun0 может также висеть условный Adguard или какой-нибудь firewall при отсутствии root доступа.
Решение: в качестве компромиссного варианта предлагаю отправленный в tun0 пакет из "неправильного" приложения не дропать, а перенаправлять на _случайный_ ip (возможно ip + порт) или какой-нибудь публичный пул прокси. Такое поведение с одной стороны отменит фактор риска из п.1 с недоступностью tun0 для приложения, а с другой - равномерно "размоет" ответы от левых адресов до уровня шума, на который нейросеть заинтересованных лиц никогда не сработает по чисто статистическим причинам.
Решение было придумано за 2 минуты буквально на коленке, поэтому требуется дополнительная проверка его эффективности и не является какой бы то ни было технической или любой иной рекомендацией (на всякий случай). Ну и да, сразу извиняюсь за длиннотекст и некрокомментарий.
А почему их вообще пытаются ловить на уровне хостинга и ip адресов? Вот если бы им регистратор не просто разделегировал, а отозвал регистрацию всех 179 доменов разом, тогда и все ссылки вида clk1.me/rD7P5E автоматически бы протухли. Рассылка спама в итоге сработала бы вхолостую с необходимостью начинать всё заново. Иначе эти кошки-мышки можно продолжать бесконечно.
Почему? За данным портом не закреплено никакой широко используемой сетевой службы или программы. Или просто само сочетание цифр выглядит сомнительно?) По такой логике и порт 1917 можно запретить тогда.
А какую проблему решает CachyOS, которую не может решить Windows?
Это совсем простой вопрос - проблема лицензионной чистоты адекватными средствами.
А у меня почти такой же вопрос, но другой: какую проблему решает CachyOS, которую не могут решить классические Debian-based и RHEL-based дистрибутивы? Иначе говоря, есть ли объективный смысл ставить ортодоксальный Arch и с головой нырять в неизвестность или это лишь веяние моды?
При этом не забываем, что у NextCloud Talk всё довольно грустно с шифрованием. На сервере вся пользовательская (текстовая) болтовня лежит в открытом виде. С аудио- и видео-вызовами дело обстоит лучше, по крайней мере так обещает документация. NextCloud неплох как файловое облако, но это не мессенджер в его классическом смысле.
Так сам кот и взломал))) Нужно боооольше вкусняшек)
Ахаха это буквально новости, которые мы заслужили) За Юлию Якубеню отдельное спасибо) Надеюсь, что в кормушке у кота были отварные сосиски)
У новости еще такая интересная авторская подача, что читать это хочется только вслух и непременно голосом сонного и задолбавшегося диджея ночного эфира с радиостанции "Шепот Подмосковья", не иначе.
К ответному комментарию выше: или можно залить листинг конфига в какой-нибудь публичный репозиторий/блокнот/etc... А возможно, весь конфиг целиком писать и не нужно. Те, кто в теме, смогут восстановить недостающее и по довольно мелким артефактам.
Сейчас еще раз попробовал на свежие мозги, и всё внезапно завелось. Кусок конфига Haproxy тривиальнейший, гуглится по ключевым словам if { req.payload(0,7) -m sub SSH-2.0 }. Важное напоминание себе в первую очередь, ну и для современников/потомков: внимательно проверять порядок, в котором в конфигурационном файле идут бэкенды, иначе (как и в случае с location в nginx, и в любых regexp-выражениях) отрабатывать будет стоящее выше более общее правило. Также внимательно читаем сообщение об ошибке, чтобы понять в каком состоянии у нас коннект. Если таймаут соединения, то на данном ip или порту вообще нет ssh, либо фаервол балуется. Если refused, вероятна ошибка в паттерне (искомой подстроке в payload) или дописаны лишние заголовки при проксировании или шифровании, если применяется. А если ssh соединение выдает ошибку remote side unexpectedly closed network connection, это повод проверить как раз порядок применения правил. Ошибки с другими сообщениями в процессе настройки лично мне не встретились, поэтому считаем список пусть если не полным, то условно достаточным.
В любом случае спасибо за внимание к вопросу и за то, что помогли найти мотивацию снова заняться допиливанием этой штуковины. Кто минусует не знаю, воткнул заслуженный плюс.
Раз уж подняли тему Haproxy. Коллеги, кому-нибудь удалось в нем разделить порт для доступа еще и для подключения по ssh?
Я пытался заняться некоторое время назад, но соединение так и не прошло. Есть подозрение, что пока не удалось подобрать правильный паттерн старта ssh-подключения. Хотя в этой части вроде инструкция как раз подробная, так что не факт что я вообще копаю в нужную сторону. Техническая деталь: настраивал всю эту радость на голом ip, без делегированных доменов на сервере. Некоторые побочные сервисы даже в таком виде удавалось конфигурировать с использованием SNI. Но, разумеется, не ssh. Неужели из-за него одного придется теперь разбираться с sslh, компилировать это дело и вручную закатывать в docker? Лень как-то) В итоге скорее всего так и так придется разбираться с sslh, уж больно много там интересных функций реализовано "из каропки". Однако то, что Haproxy не заводится как следует никак не дает покоя.
Там есть нюанс) Фактчекинг нам подсказывает, что Карно != Карно. А именно, Сади Карно жил во Франции 18-го века и описал термодинамический цикл имени себя. А Морис Карно, сотрудник IBM и современник абсолютного большинства (на данный момент - всех?) комментаторов этой статьи, описал способ работы с диаграммами Вейча для минимизации логических функций. И нет никаких подтверждений их родственной связи, по крайней мере прямой.
Роутер с авито - это всегда кот в мешке с непонятным пробегом, непонятными условиями эксплуатации и непонятными перспективами дальнейших поставок. Сегодня Билайн продает свое оборудование, а завтра вдруг возьмет и передумает, либо начнет выпускать нечто без поддержки OpenWRT. Вот если бы можно было найти что-нибудь подобное, но не бывшее в эксплуатации, пусть даже и чуть дороже - было бы просто шикарно.
Тоже заметил эту цепочку, поэтому до последнего не хотел комментировать эту типа статью. Ну принесли и принесли, завтра принесут еще. Но вообще, конечно, я бы предпочел такие новости узнавать непосредственно от разработчиков и их официальных тг каналов.
Спасибо, статью посмотрел. Итого имеем 3 недели от идеи до релиза. И что интересно, в конце статьи проявились примерно те же проблемы в работе push-уведомлений, что описаны и в моём более раннем комментарии на данной странице. До этого статью не заметил, поэтому честно не подглядывал)
А не взлетело скорее всего из-за сомнительного нейминга. Добавить бы в заголовок слова "мессенджер" и "альтернатива" - и результат потенциально мог быть совсем иным)
Список функций впечатляет. Даже с учетом того, что половина из них скорее всего не нативные, а из внешних библиотек. Жаль только не указано, сколько по времени такое пишется. Я так понял, что репозиторий был создан 2 месяца назад под заливку уже готового продукта?
О, я ждал этого вопроса джва года!)) Расскажу свой пользовательский опыт. Если коротко - целый зоопарк разных клиентов вместо одного нормального. Под Android: в одном клиенте нет кнопки для удаления сообщений. В другом она есть (хоть и работает как-то странно, не всегда корректно передает команду удаления сообщений на клиенты, которые в данный момент офлайн), но не прикручен FCM. Из-за чего, поскольку на Android 14+ постоянное соединение с сервером просто рвется системой принудительно по таймауту даже при наличии у приложения foreground service, сообщение не увидишь до тех пор, пока сам специально не откроешь клиент. Знакомая ситуация, правда? Тут недавно по новостям один известный мессенджер дал такого же МАХу (типа каламбур), когда его вынесли из Гугл маркета, видимо с отзывом FCM-токена. Точно не скажу, поскольку сам лично пользуюсь опен-сорсными решениями.
По итогу скажу, что проблемы бы решила версия Android, которая позволила бы менять адрес сервера push-уведомлений по умолчанию. Как-то грустно осознавать, что работа вообще всех уведомлений системы зависит от доступности всего лишь одного поддомена третьего уровня. К имеющейся системе можно прикрутить сбоку свой сторонний сервер уведомлений, но и это уже проверено на практике. Не говоря даже про необходимость интеграции с другими приложениями через какие-то костыли, которые еще могут и отсутствовать, получается настолько энергозатратно, что телефон буквально вынужден жить у розетки.
P.S. Десктопный jabber тоже удалось потестировать, но совсем немного. Из обнаруженных проблем - клиент может отказаться соединяться с сервером, если используется неправильный (точнее сказать, незаполненный в некоторых полях) сертификат. Решается использованием правильно настроенных серверов, поэтому как будто бы не проблема. Но это только то, что само проявилось за короткое время тестов, возможно дальше удалось бы выявить и другие грабли.
Сработает, если будет доступ к почте во внешнем контуре.
Туда попадут только ссылки, не закрытые от индексирования. Да и скорость индексирования некоторых страниц оставляет желать лучшего.
Нельзя зарекаться) Будет спрос - будет предложение. Были бесплатные - станут так или иначе платными, даже в self-hosted варианте. Тут вот в чем дело: глобально мы слишком привыкли в нулевые к тому, что если нужен какой-то сервис, то его почти наверняка уже сделал какой-нибудь умный бородатый дядька-админ. Сейчас нужно просто осознать, что если нужно создать или возродить какой-либо сервис, то в настоящее время эти бородатые админы - это уже мы сами. И нет никаких других, более настоящих инженеров)
Проблема всех таких сервисов в основном сводится к следующему:
1. Нецелесообразность. Если можно протолкнуть текстовую команду на сервер, то мб реально отправить и поток данных напрямую? И вот уже нам нужен не mail-сервер, а обычная реверс-прокся. На крайний случай - прикрутить качалку с веб-мордой, там тоже есть свои плюсы.
2. Оплата. Если первая проблема может показаться надуманной (например, по причине асимметричности скоростей приема и передачи потока данных или просто из-за сильного урезания этой самой скорости и крайней затрудненности получения потока в реальном времени), то это проблема уже более чем реальная. Купить местной кредиткой можно только местный сервер, оно нам не надо. Оплата криптой - сомнительно, но окэй, есть риск попасть под 115 сами-знаете-что, поскольку там от децентрализации и приватности остался только дух прошлого. Зарубежная кредитка - неплохой вариант, если решить проблему с ее пополнением и недешевым обслуживанием. Пока жаба все-таки перевешивает.
P.S. Еще интересный вопрос: а как получать ссылки на файлы с недоступного сервиса? Получается, что должен работать какой-то парсер, который будет условно говоря по таймеру делать рассылку содержимого страницы? В целом как-то так.
Если таки соберетесь создавать, да еще и под Android, сразу для решения проблемы белых списков рекомендуется прикрутить возможность использования своего сервера для push уведомлений. Имеющиеся решения работают в формате отдельного приложения и крайне не энергоэффективны по отношению к батарее телефона. Подозреваю, что из-за особенностей реализации doze mode в android версий 14 и выше по второму пункту вряд-ли можно что-то сделать, таковы особенности платформы, придется телефон поселить у розетки. Но по крайней мере держать два разных приложения для сообщений-звонков и уведомлений о них кажется чересчур. Приложение, которое сумеет совместить в себе обе функции, сразу будет выгодно отличаться от тех же Matrix и Conversations. Либо как вариант можно написать модуль интеграции своего push сервера в любое из имеющихся решений, если это проще. В общем, если есть желание - творите.
Вот видите, вы уже задаетесь вопросами. Это означает наличие интереса. А раз так, то "подпишись..." ну и далее по тексту. /s
P.S. А по факту на канале наверняка будут опубликованы прохладные лайфстори вроде этой. Ну и еще новости о том, как "наша замечательная Вердепешевая модель" обогнала "их мерзкую Накаратовую" на целых полтора попугая в бенчмарках.
Это если смотреть в разрезе LLM и прочих нейросеток. А вот криптовалюта Chia и ~полдесятка других Proof-of-Space токенов с этим утверждением явно не согласны.
С опозданием, но всё-таки я попробую немного раскрыть мысль предыдущего комментатора. Ключевой момент: вы оба по-своему правы) Есть два разных взгляда на вопрос:
1. Связка "список сетевых интерфейсов с наличием в нём tun0 + отлуп при попытке использования этого tun0" однозначно дают понять, что тут дело нечисто, возможно кто-то пытается противодействовать телеметрии.
2. Пункт 1 неактуален, поскольку на интерфейсе tun0 может также висеть условный Adguard или какой-нибудь firewall при отсутствии root доступа.
Решение: в качестве компромиссного варианта предлагаю отправленный в tun0 пакет из "неправильного" приложения не дропать, а перенаправлять на _случайный_ ip (возможно ip + порт) или какой-нибудь публичный пул прокси. Такое поведение с одной стороны отменит фактор риска из п.1 с недоступностью tun0 для приложения, а с другой - равномерно "размоет" ответы от левых адресов до уровня шума, на который нейросеть заинтересованных лиц никогда не сработает по чисто статистическим причинам.
Решение было придумано за 2 минуты буквально на коленке, поэтому требуется дополнительная проверка его эффективности и не является какой бы то ни было технической или любой иной рекомендацией (на всякий случай). Ну и да, сразу извиняюсь за длиннотекст и некрокомментарий.
А почему их вообще пытаются ловить на уровне хостинга и ip адресов? Вот если бы им регистратор не просто разделегировал, а отозвал регистрацию всех 179 доменов разом, тогда и все ссылки вида
clk1.me/rD7P5Eавтоматически бы протухли. Рассылка спама в итоге сработала бы вхолостую с необходимостью начинать всё заново. Иначе эти кошки-мышки можно продолжать бесконечно.Почему? За данным портом не закреплено никакой широко используемой сетевой службы или программы. Или просто само сочетание цифр выглядит сомнительно?) По такой логике и порт 1917 можно запретить тогда.
Это совсем простой вопрос - проблема лицензионной чистоты адекватными средствами.
А у меня почти такой же вопрос, но другой: какую проблему решает CachyOS, которую не могут решить классические Debian-based и RHEL-based дистрибутивы? Иначе говоря, есть ли объективный смысл ставить ортодоксальный Arch и с головой нырять в неизвестность или это лишь веяние моды?
При этом не забываем, что у NextCloud Talk всё довольно грустно с шифрованием. На сервере вся пользовательская (текстовая) болтовня лежит в открытом виде. С аудио- и видео-вызовами дело обстоит лучше, по крайней мере так обещает документация. NextCloud неплох как файловое облако, но это не мессенджер в его классическом смысле.
Так сам кот и взломал))) Нужно боооольше вкусняшек)
Ахаха это буквально новости, которые мы заслужили) За Юлию Якубеню отдельное спасибо) Надеюсь, что в кормушке у кота были отварные сосиски)
У новости еще такая интересная авторская подача, что читать это хочется только вслух и непременно голосом сонного и задолбавшегося диджея ночного эфира с радиостанции "Шепот Подмосковья", не иначе.
К ответному комментарию выше: или можно залить листинг конфига в какой-нибудь публичный репозиторий/блокнот/etc... А возможно, весь конфиг целиком писать и не нужно. Те, кто в теме, смогут восстановить недостающее и по довольно мелким артефактам.
Сейчас еще раз попробовал на свежие мозги, и всё внезапно завелось. Кусок конфига Haproxy тривиальнейший, гуглится по ключевым словам
if { req.payload(0,7) -m sub SSH-2.0 }. Важное напоминание себе в первую очередь, ну и для современников/потомков: внимательно проверять порядок, в котором в конфигурационном файле идут бэкенды, иначе (как и в случае с location в nginx, и в любых regexp-выражениях) отрабатывать будет стоящее выше более общее правило. Также внимательно читаем сообщение об ошибке, чтобы понять в каком состоянии у нас коннект. Если таймаут соединения, то на данном ip или порту вообще нет ssh, либо фаервол балуется. Если refused, вероятна ошибка в паттерне (искомой подстроке в payload) или дописаны лишние заголовки при проксировании или шифровании, если применяется. А если ssh соединение выдает ошибку remote side unexpectedly closed network connection, это повод проверить как раз порядок применения правил. Ошибки с другими сообщениями в процессе настройки лично мне не встретились, поэтому считаем список пусть если не полным, то условно достаточным.В любом случае спасибо за внимание к вопросу и за то, что помогли найти мотивацию снова заняться допиливанием этой штуковины. Кто минусует не знаю, воткнул заслуженный плюс.
Раз уж подняли тему Haproxy. Коллеги, кому-нибудь удалось в нем разделить порт для доступа еще и для подключения по ssh?
Я пытался заняться некоторое время назад, но соединение так и не прошло. Есть подозрение, что пока не удалось подобрать правильный паттерн старта ssh-подключения. Хотя в этой части вроде инструкция как раз подробная, так что не факт что я вообще копаю в нужную сторону. Техническая деталь: настраивал всю эту радость на голом ip, без делегированных доменов на сервере. Некоторые побочные сервисы даже в таком виде удавалось конфигурировать с использованием SNI. Но, разумеется, не ssh. Неужели из-за него одного придется теперь разбираться с sslh, компилировать это дело и вручную закатывать в docker? Лень как-то) В итоге скорее всего так и так придется разбираться с sslh, уж больно много там интересных функций реализовано "из каропки". Однако то, что Haproxy не заводится как следует никак не дает покоя.
Там есть нюанс) Фактчекинг нам подсказывает, что Карно != Карно. А именно, Сади Карно жил во Франции 18-го века и описал термодинамический цикл имени себя. А Морис Карно, сотрудник IBM и современник абсолютного большинства (на данный момент - всех?) комментаторов этой статьи, описал способ работы с диаграммами Вейча для минимизации логических функций. И нет никаких подтверждений их родственной связи, по крайней мере прямой.
Не забываем, что это работает только для целых чисел. Тогда как -gt более универсален.
P.S. В данном скрипте применимо, поскольку там идет деление с отбрасыванием дробной части. Подходит для расчетов, где +-1% не является критичным.
Роутер с авито - это всегда кот в мешке с непонятным пробегом, непонятными условиями эксплуатации и непонятными перспективами дальнейших поставок. Сегодня Билайн продает свое оборудование, а завтра вдруг возьмет и передумает, либо начнет выпускать нечто без поддержки OpenWRT. Вот если бы можно было найти что-нибудь подобное, но не бывшее в эксплуатации, пусть даже и чуть дороже - было бы просто шикарно.
Тоже заметил эту цепочку, поэтому до последнего не хотел комментировать эту типа статью. Ну принесли и принесли, завтра принесут еще. Но вообще, конечно, я бы предпочел такие новости узнавать непосредственно от разработчиков и их официальных тг каналов.