Спасибо тебе, Санта из Швейцарии ❤️ сверху слева крышка от коробки 🤗

ГруппировОЧКА на БД или на клиенте?

Описание: имеется три таблицы (пользователь, приложение, ключ) в psql. Пользователь может иметь приложения, а ключи связывают приложения и пользователей.

User:
- id
- name
- email

Application:
- id
- title

Key:
- id
- User
- Application

Задача: получить список ключей для отправки писем на почту. Один пользователь должен получить одно письмо на приложение вне зависимости от количества ключей. Какой именно ключ из множества для конкретного пользователя и приложения мы получим не важно

Решение 1: получаем все ключи, заводим словарик, проходясь по каждому ключу генерируем уникальный ключ для словаря состоящий из ID пользователя и ID приложения, пихаем значения по ключу не заботясь было ли до этого какое-то или нет.
Результат: список значений словаря.

Решение 2: вспоминаем (в моем случае узнаём) про DISTINCT ON и скармливаем ему два поля: пользователь, приложение.
Результат: ответ от БД.

Можете не вдаваться в детали так как вопрос общий. А на чём бы вы основали своё решение в подобных задачах? На БД или на клиенте? Где бы вы предпочли группировать данные и почему? Вот это всякое про лёгкое масштабирование приложений и т.д.

P.S. Пересмотрев своё старое решение другой задачи я ужаснулся словарю в словаре, в котором список, а подумав о количестве данных и насчитав ~900 итераций в пике остался довольным, что написал это за минуту, а не колупался с SQL.

Дело сделано

Знаете принцип Парето? Тот, который про 80% результата за 20% усилий, а дальше что-то тяжко. Оставшиеся 80% усилий на 20% результата. Дык вот живой пример – разработка библиотеки.

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

Несмотря на отсутствие стабильной версии за всё время люди создали много прекрасных проектов. Некоторые использовали библиотеку (50 штук с открытым кодом на GitHub), некоторые брали за пример и работали с API на других ЯП. Так, например, был создан альтернативный клиент для android авто.

GitHub - yandex-music-api наконец-то достигла версии 1.0.0 с более чем 300 звездами 🎉

Развиваться есть куда!
- Асинхронная версия библиотеки.
- Модели с использованием pydantic.
- Интеграционные тесты.

Ваш вклад максимально приветствуется ✨

https://github.com/gvanrossum/patma. Там в readme ещё ссылка на форк CPython (Python 3.10) с полной реализацией

Cloud Firestore

Примитивная NoSQL база. Единственное её преимущество – это отсутствие надобности в разворачивании, масштабировании.

Она отстаёт во всём не давая ничего революционного. Просто живёт в экосистеме Google. Так, например, можно повесить Cloud Function-trigger, который будет обрабатывать какое-то действие в базе (удаление, добавление, изменение). И это жизненно необходимо!

Не стану вспоминать уж всё, с чем я столкнулся при работе с этой базой, но вот основные пункты, которые помню хорошо:
- отсутствуют агрегации. Приходится реализовывать подсчёт данных самостоятельно на триггерах. Так и советуют делать в официальной документации;
- до недавнего времени отсутствовал даже оператор != в where. Были доступны следующие базовые операторы: < <= == >= > array-contains array-contains-any;
- баги, из-за которых невозможны некоторые запросы (issues открыты на GitHab’e);
- локальный эмулятор базы спокойно живёт без индексов, когда после деплоя вдруг оказывается что нужно было завести индекс. Оно тебе сгенерирует ссылку для создания и поймет по каким полям, но это уже после того, как задеплоил. Без создания индекса запросы нельзя делать 🤷

Аннотаций там всего несколько. Из основных это DocumentId и ServerTimestamp. Остальные ~4 мне не пригодились. Там какой-то Exclude и PropertyName ещё есть…

Про Security Rules отдельная история. Там можно такое вытворять, что клиенты без backend’a могут общаться с базой для реализации какой-нибудь онлайн игры в шахматы. Самое интересное, что первый клиент не сможет читать/изменять данные (хода игрока, например) второго.

Надо отдать должное разработчикам. Проект развивается. Так, относительно недавно, завезли оператор !=, not-in (только вот они убили обратную совместимость. Чтобы обновиться, нужно перелопатить проект или сидите без новых операторов). Представляете какого жить без них?

Спасибо хоть за WriteBatch ✨

CVE-2021-3177 Python 3.x through 3.9.1 has a buffer overflow in PyCArg_repr in _ctypes/callproc.c, which may lead to remote code execution in certain Python applications that accept floating-point numbers as untrusted input, as demonstrated by a 1e300 argument to c_double.from_param. This occurs because sprintf is used unsafely

>>> import ctypes
>>> x = ctypes.c_double.from_param(1e300)
>>> repr(x)
Segmentation fault

Clubhouse – разбор внутрянки

Популярный сервис для голосового общения в отдельных комнатах. Невероятно простое во всём. По своей реализации уступает даже войс чатам Telegram. Если вы думали, что приложение выглядит “бедно” и написали бы такое за пару недель, то сейчас ваша временна́я оценка упадет. Под капотом ещё всё проще!

Сервис состоит из 4 компонентов:
- приложение на iOS
- REST API
- сервер Agora
- сервер PubNub

Первые два пункта интуитивно понятны. Всё за Cloudflare, внутри API больше 100 методов от обновления имени аккаунта, до получения клуба и поиска пользователей.

Чего я правда не ожидал – это использование Agora. Я был в шоке от того, как хорошо Clubhouse держит нагрузку и в целом сделал такой стабильный RTC. Как оказалось, они просо использовали готовый PaaS. Подключили SDK и интегрировались со своим API.

Для интеграции с Agora генерируется RTC Token для каждого захода в комнату. Роли (спикер, слушатель) вшиты в токены. Поэтому при выдаче вам разрешения на высказаться у вас произойдет переподключение к комнате с новым токеном.

PubHub – платформа для realtime коммуникации. Взяли IaaS, заинтегрировались и работает на ура. Используется в комнатах для быстрого обновления новых участников, статусов микрофонов, перехода пользователей из одной роли в другую, поднятие рук и так далее.

Вот и всё приложение. Из интересного ещё можно добавить, что шифрование контролируется удалённо и включено далеко не всегда. MITM работает на ура. Любой аккаунт можно угнать перебрав четырехзначный код.

Библиотека на Python для работы с API: https://github.com/stypr/clubhouse-py (запросы через requests, отдаёт словарь из JSON’a). Есть интеграция с Agora. Можно передавать звук.

Аудит провёл специалист из Кореи: https://theori.io/research/korean/analyzing-clubhouse/

❗️Клиент Clubhouse для Android

https://github.com/grishka/Houseclub

Гришка ✨

pytgcalls currently in public beta test!

I would like to draw your attention to the fact that at the moment testing is possible only on Linux with x86_64 platform!

Please read the full readme of the repository!

https://github.com/MarshalX/tgcalls-beta

Happy testing ❤️

Dear testers, let's update!

Added visualization of sound inside a voice chat! Added sending status to users outside the VC! Fixed joining voice chat. Now the sound plays right away!

A demo of visualization is available in the chat: @tgcallschat

CMD for update: pip install --upgrade --pre pytgcalls

Full back support. Just upgrade ❤️

I'm starting to prepare a private repository to open for joint development with you!

Видеозвонки в групповых чатах уже скоро 👀 Делаются по аналогии и переиспользованию захвата видео с камеры из приватных звонков

Новая система авторизации Яндекс

Разработали себе Auth SDK с помощью которого теперь происходит менеджмент аккаунтов на устройствах. Для однократного входа в аккаунт и генерации токенов для других приложений. Вот уже как полгода (больше) аккуратно всех переводят на неё отключая старую для определённых аккаунтов и версий.

Система состоит из трёх шагов.

Первым шагом отправляется логин пользователя. Происходит проверка на существование аккаунта, возможность входа (есть ли ограничение), возможность регистрации нового аккаунта с таким логином при его отсутствии. Результатом первого шага является так называемый track id — это некий идентификатор сессии авторизации.

Вторым шагом происходит проверка аутентификатора. Отправляется запрос содержащий в себе пароль пользователя, который может быть OTP при включённой 2FA и непосредственно сам идентификатор с прошлого шага. На данном этапе, помимо банальной проверки пароля, происходит работа с капчей. Её запрос и отправка. Получение капчи элементарное — сервер возвращает ссылку с картиной. Для прохождения достаточно добавить заголовок с ответом и повторить запрос. Из интересностей можно отметить две вещи:
1. Капча привязана к сессии авторизации.
2. Если попытаться ответить на капчу не сделав запрос на изображение (не посмотреть на капчу), то нас пошлют со следующей ошибкой: «капча не была показана». При успешном выполнении запроса получаем большой объект с информацией об аккаунте (имя, логин, дата рождения, аватарка и прочее) и очень важный атрибут — X-Token.

В конце концов мы стучимся за токеном к определённому приложению. Стучимся с помощью нашего универсального X-Token’a , а в запросе указываем данные от необходимого нам приложения. Опционально можем даже версию задать и это влияет на ответ. Токены на новых версиях отвратительно длинные (под 200 символов) и содержат в себе кучу информации вплоть до открытого UID пользователя. Разделана информация в этих токенах точкой (речь про ЯМ токены).

Наблюдать за переездом интересно, стандартизация хороша, шарить аккаунт между приложениями на телефоне очень удобно. Из негативных моментов могу только отметить то, что все сервисы теперь избавляются от самостоятельного управления аватаркой. Отсюда проблемы, что все API использую аватарку из другого места. Получение аватарки происходит очень нечасто, поэтому ещё долго можно наблюдать старую аватарку в приложении Яндекс.Музыка. Перезаход в аккаунт поможет, так как спровоцирует обновление информации в Auth SDK.

Запросы, их параметры, заголовки и ответы: https://github.com/MarshalX/yandex-music-api/issues/414

Моя реализация на Python: https://github.com/MarshalX/yandex-music-api/pull/416/files ✨

Ставь ⭐️ если пупс 👉👈. Хотя бы за изображения в readme 🥺

https://github.com/MarshalX/tgcalls

@vcradio ну на этом мои полномочия всё, окончены. Улучшил качество звука в войс чатах как мог, хотя можно сделать скидку на то, что это стрим и радио вообще, а не локально из файла. Локально из файла играет тут: @tgcallschat

Обновление голосовых чатов Telegram

1. Запись голосовых чатов

- Запись происходит на серверной стороне.
- Все участники видят что происходит запись.
- При окончании записи она отправляется в ваши сохранённые сообщения.
- Записи вынесены в отдельную сущность. Скорее всего будут как-то иначе отображаться в интерфейсе. Не просто аудиофайл.

2. Поднятие руки

- У каждого участника есть возможность поднять руку.
- Кроме статуса поднятия существует приоритет.
- Проритет работает элементарно. Кто первее – тот выше. Поэтому не стоит поднимать-опускать руку для попытки привлечь внимание.
- В реализации tdesktop пользователей с поднятыми руками по приоритету видят только администраторы с правом управления голосовым чатом.

3. Пригласительные ссылки

- Ссылки теперь двух типов: speaker, listener.
- При входе по ссылке типа speaker есть возможность размутить самого себя.
- Система с ссылками работает на хеше у группового звонка. Его можно перегенерировать (сбросить).

4. Другое

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

Порядок списка участников голосового чата:
- говорящие;
- не принудительно замученные (имеющие право говорить);
- с поднятой рукой отсортированные по рейтингу;
- все принудительно замученные (красный микрофон. Нет права говорить).

А ещё некий режим вещания. Выглядит как возможность воспроизводить старые записи голосовых чатов и/или ретрансляции в другой чат. Точнее сказать не могу что это. Возможно просто решение для работы в каналах.

Групповые видеозвонки пока не ало, но их библиотека для звонков готова к этому. Готов захват экрана с и без курсора с разным fps.

MTProto Layer 125. Сборка tdesktop’a падает в который раз. Чинят на ходу ✨

От имени канала можно сидеть только 1 администратору одновременно. При попытке зайти ещё одному в один и тот же голосовой чат – старого отключит без каких-либо ошибок.

64 символа максимум в заголовке. Теперь в нём можно отображать текущий проигрываемый трек ботом)

Отображение bio пользователей в списке участников – это лучшее из всего обновления 🤯 На macOS клиенте отображаются первые 32.

У войс чатов каналов нельзя управлять настройкой могут ли говорить новые участники. Это доступно только для чатов.

Даешь размут по клику на руку участника! Неудобно сейчас раздавать право голоса!

Для изменения хеша для speaker link нужно пересоздавать голосовой чат (полностью останавливать и запускать вновь)... То есть при сливе линка придется всем перезаходить. Хотя для сброса хеша есть MTProto метод...