/it/ - xmpp клиент

xmpp клиент Anonymous 21/09/19 10:37:32 No.1185

if-programmers-[...].png (85 KB, 500x303)

Подумываю ебашить вообще адовый суп, вариаций масса, но в целом схема примерно такая:
Главный процесс - авторизируется перед сервером, запускает все другие, в stdin им пишет соответсвующие станзы полученные от сервера (с префиксами длины, предварительно очищая от всякой возможной уязвимой хуйни, которая энивей недопустима в хмпп типа dtd, т.о. в этих програмулечках можно будет использовать любую хмл либу, а не ебаться со всякими sax), с их stdout читает станзы и шлёт серверу. Причём этот же главный процесс заботится о том чтобы каждая станза была доставлена, причём один раз, т.е. имплементирует ХЕР0198 и ХЕР0359.
Станзы "iq" идут к условному iqd, "message" к условному messaged, "presence" аналогично. Нонзы не имеет смысла выносить в отдельный процесс, я думаю, потому что насколько я знаю они всегда делают что-то непосредственно связанное с соединением.
iqd открывает UDS сервер. Подключившись к UDS серверу, клиент (т.е. любая другая программулечка), может послать один iq и получить ответ тут же, аналогично с префиксом длины, чтобы не ебаться с парсингом хмл, а просто скормить любой хмл либе всю станзу.
messaged открывает какой-нибудь простой локальный интерфейс для гуя или консосьного фронтенда, где у входящего сообщения например указывается тупо (расшифрованный) текст, дата, зашифровано ли, всякая такая хуйня - фронтенду подаётся на блюдечке, а гуй опять же шлёт текст, говорить зашифровать ли и если да то чем, ну и т.д. хуйня. Так же открывается UDS сервер, клиенты которого шлют интересующие namespaces, и получают все сообщения, их содержащие (через это будет работать условный pubsubd(ХЕР0330), который в свою очередь поднимет аналогичный сервер-два, которые предоставят простой интерфейс (им сможет пользоваться условный discod (ХЕР0030), который в свою очередь сделат подобное)).
Через pubsubd в т.ч. главный процесс сможет аннаунсить поддержку ХЕР0359.
Во всём этом блядском цирке например omemo будет организовать как-то так: подписываемся на pubsub сообщения о ключах, предоставляем UDS-сервер на который можно будет послать станзу <encrypted> хуйню и получить расшированный текст, этим сервером будет пользоваться messaged.
Отдельно будет жить хуйнюшка реализующая вот эту хуйню, например https://xmpp.org/extensions/inbox/omemo-media-sharing.html#aesgcm. Т.е. будет отдельный демон у которого фронтенд будет запрашивать файлы, а он уже будет решать - тупо curl'ом их надо качать, или по вот по этой хуйне.

Т.о. компоненты можно будет пилить разным людям, на разных языках, общаясь с простейшим апи. Я ебан? Где я проебался?

Anonymous 21/09/19 10:43:06 No.1186

tl;dr: подводные хуячить клиент в виде кучи мелких програм одна из которых - гуй

Anonymous 22/11/19 11:05:36 No.1521

>>1185 (OP)
Взгляни на jj, там одна программа и не раздуто.

Anonymous 01/12/19 16:01:17 No.1575

Крч такая вещь: надо запускать "плагины" лениво, т.е. пока юзер не получил мессаджа омемо, то нехуй плагин омемо запускать, потому что способы шифрования ведь и другие есть - пгп и отр, ну и хули процессы просто так держать в памяти. Поэтому можно вообще не uds использовать, а тупо stdin/stdout, ну и iqd выносить отдельно нет смысла.
Вместо length-prefixes стоит заебенить просто либу чисто под хмл-потоки (без нетворкинга) с биндингами под разные языки.

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

А сделано это чтобы простые аноны в свободное от РАБоты время точно ничего запилить не смогли. Разработка ПО должна быть привелегией властьимущих.

>>1521
Там вообще другое, не расширяемо нифига

Anonymous 06/12/19 09:23:30 No.1650

>>1575
>не расширяемо нифига
Там пайп, хоть обрасширяйся. Или расширяешь внутри, нехуй плодить много мелких сущностей, ты не гугля.

>пгп и отр, ну и хули процессы просто так держать в памяти
Я думаю, пгп и отр — совсем малое, что будет держаться у тебя в памяти. Сравни жор какого-нибудь консольного клиента и десктопного/мобильного говнища.

Anonymous 06/12/19 09:25:30 No.1651

>>1185 (OP)
>"message" к условному messaged
И тут ты такой захотел прикрутить к своему клиенту несколько хэндлеров на месседжи. Или ебануть бота, который вместе с месседжами полезет обрабатывать и другие станзы.

Anonymous 06/12/19 09:29:30 No.1652

>>1185 (OP)
>Где я проебался?
Никто не полезет играть с кучей маленьких серверков, где у каждого свой api, проще выставить наружу ipc с одним большим api на все возможности клиента и как-нибудь возвращать назад ответы. Но никто это не полезет особо делать, потому что проще написать кучку кода на си, а потом привязать к хэндлерам на нужном тебе языке через ffi.

Anonymous 06/12/19 11:03:47 No.1653

>>1652
> потому что проще написать кучку кода
>проще
>на си

Anonymous 09/12/19 07:52:41 No.1695

>>1653
Да, проще, учитывая то, что иначе ты на нём же полезешь заниматься сериализаций в кастомный формат.

Anonymous 09/12/19 07:53:49 No.1696

Если не сериализацией, то просто мультиплексом соединений.

Anonymous 09/12/19 11:44:48 No.1698

>>1652
>Никто не полезет играть с кучей маленьких серверков, где у каждого свой api,
Unix так и живёт хули
Ну а вообще имхо можно сделать не апи а "фильтры" - допустим фильтр омемо будет обрабатывать все сообщения зашифрованные омемой, и просто в боди вставлять текст, а это далее будет передаваться отрисовщику гуя.
"Апишность" при этом можно будет свести до минимума - скажем, для отправки сообщения зашифрованного омемо с использованием такого фильтра достаточно будет добавить какой-нибудь "флаг" в станзу на этапе формирования её из юзер инпута, а там уже фильтр омемо её зашифрует нужными ключами и всей хуйнёй.

Anonymous 14/12/19 17:27:10 No.1718

>>1698
>Unix так и живёт хули
Вот именно, что так не живёт. Unix -way в минимальном дизайне. Если можно сделать фильтра или генератор, делается именно так.
>допустим фильтр омемо
Не легче ли впилить фильтр омемы вообще как функцию, которая будет прозрачно обрабатывать входящие сообщения? Зачем процесс?

Anonymous 15/12/19 03:17:40 No.1724

>>1718
Так затем, что функция она зависима от языка и таки устройства самого клиента, хотя это можно минимизировать . Поэтому у нас куча клиентов с разным количеством и качеством поддерживаемых ХЕРов - потому что для каждого клиента надо всё заново перепиливать.

Если так как я описываю, то можно запилить одну часть клиента на одном языке, другую на другом, потом ту первую перепилить на третий не изменяя ничего в другом, не ебясь с биндингами.
Можно к одной базе запилить несколько фронтендов - кому-то нрафки гтк, кому-то fltk лол, может кто-то обпердолится и под андроид запилит даже, приэтом понятно что часть кода занимающуюся преставлением надо перепиливать, но не надо каждый раз пилить заново самые основные херы.

Anonymous 17/12/19 08:19:54 No.1728

>>1724
>Так затем, что функция она зависима от языка
А зачем тебе независимая от языка омема, если ты её запилишь в том же самом процессе в виде условно-прозрачного фильтра, через который будут проходить все станзы и, судя по твом же словам,
>достаточно будет добавить какой-нибудь "флаг"
>будет обрабатывать все сообщения зашифрованные омемой
? Вошло XML от сети — там же обработалось. Без лишних сущностей и пересериализации.

>Поэтому у нас куча клиентов с разным количеством и качеством поддерживаемых ХЕРов - потому что для каждого клиента надо всё заново перепиливать.
Так другие люди не будут пилить из кучки программ свои клиенты, максимум свой GUI прилепят, ведь им придётся начать серьёзно понимать за посылку сообщений у тебя в системе. И делать точно так же, как делаешь ты. Универсальной сериализации нет.
>Если так как я описываю, то можно запилить одну часть клиента на одном языке, другую на другом, потом ту первую перепилить на третий не изменяя ничего в другом, не ебясь с биндингами.
Тебе придётся вместо биндингов ебаться с сериализацией, разрабатывать свой формат для (мета)данных, к XMPP и даже к XML собственно относящихся боком. В особо радикальном случае пилить кросс-платформенную систему посылки сообщений, что вообще никто особо не сделал. Ну есть сообщения с акторами в эрланге, есть Binder в android, а ничего, что было бы везде, нет. Не забудь ещё, что засериализовать-развернуть данные уже тебе не захочется и ты полезешь писать свой IDL, собирающийся во все эти языки.
К слову, про Binder. Вроде как всё в том же Android работает через этот полумёртвый отросток беоси. IDL свой для жабки есть. На том же Android GUI (surfaceflinger, как кажется, намертво к этому binder и привинчен) массово пишут либо на той же жабке, либо рисуют на попенжле. Где масса широко гуёвых фреймворков на си и всякой скриптухе? Я бы хотел увидеть там тот же GTK, но он собирается с помощью какой-то магии и официально не поддерживается. Всего-то с сериализацией разобраться.

Ну и заново линкну свой пост >>1652. Написать один сервер проще десятков других. Обслуживать тоже проще. Это пусть гугли с амазонами ебошат по микросервису в секунду, у них больше денег и kloc/час несоизмеримо выше, чем у тебя.

>Можно к одной базе запилить несколько фронтендов
Это можно сделать и превратив клиент в огромную библиотеку с коллбеками, делая ffi там, где надо. И можно сделать один сервер, который будет общаться с нашим гуем по строго определённому протоколу, выкидывая в процессе весь XML по максимуму.

Anonymous 09/03/20 09:28:37 No.2075

>>1728
>Так другие люди не будут пилить из кучки программ свои клиенты, максимум свой GUI прилепят, ведь им придётся начать серьёзно понимать за посылку сообщений у тебя в системе. И делать точно так же, как делаешь ты. Универсальной сериализации нет.
Также про сам хмпп можно сказать, лол. Надо серьёзно понимать за посылку сообщений и делать точно так же как существующие клиенты.
>Я бы хотел увидеть там тот же GTK, но он собирается с помощью какой-то магии и официально не поддерживается.
Хз к чему ты это сказал вообще, Андроид специально сделан чтобы не поддерживать существующий софт, чтобы на него разработка была сложной, и проблема при портировании гтк ну никак не сводится к какому-то там binder'у. А вот у Dbus число библиотек наверное не сильно меньше числа програм его использующих.

Anonymous 09/03/20 09:34:15 No.2076

>>1728
>Это можно сделать и превратив клиент в огромную библиотеку с коллбеками, делая ffi там, где надо.
Можно. Так весь клиент и все плагины сделать можно. Но
1) ffi сложнее чем какой-нибудь минималистичный текстовый rpc
2) Для какого-нибудь python с asyncio или tcl с его event loop надо будет писать какие-то прослойки чтобы оно работало в одном евент лупе со всем клиентом
3) Клиент будет менее отзывчивым. Если какой-нибудь плагин занимающийся архивами работает в своём процессе - то он вполне может работать с каким-нибудь sqlite синхронно, его подвисания затормозят только работу с архивами но не повесят вообще весь гуй, и процесс можно будет в крайнем случае убить и запустить заново

Anonymous 09/03/20 10:08:00 No.2077

Кстати по-моему таки нужен RPC.
Нужно отдельное представление сообщений для клиента. Просто фильтрами можно реализовать омемо, да, но что делать например с отправкой файлов? Нужно представление информации о загрузке и отправке независимое от языка. Поэтому нужен rpc. Таким образом порой совершенно разные по принципу действия и степени уродства существующие способы передачи файлов типа
https://xmpp.org/extensions/xep-0066.html#example-1
https://xmpp.org/extensions/xep-0234.html#example-1
https://xmpp.org/extensions/xep-0363.html
https://xmpp.org/extensions/inbox/omemo-media-sharing.html
Можно загнать под какой-нибудь один минималистичный протокол (всм между гуём и самим клиентом), который можно свести к трём фразам:
от гуя клиенту: "отправь файл по такому-то пути" и "прерви загрузку"
от клиента гую: "файл загружен настолько-то процентов"

В общем, по сути, RPC должен поддерживать request-response, ну и события.
Можно его вообще свести к трём типам станз:
<stream> <request id="XX" method="XXXX"></request> <response id="XX"></response> <event></event> </stream>
Но желательно добавить бы ещё разбиение событий на группы, т.е. чтобы событие могло ассоциироваться с какой-то транзакцией.
Тогда разговор гуя с клиентом мог бы происходить как-то так:
<stream>  <request id="1" method="upload.start"> <chat id="juliet@capulet.lit/balcony"/> <file path="/home/romeo/dickpic.jpg"/> </request>  <response id="1"> <ok/> </response> <event id="1"> <download-progress percentage="50"/> </event> <event id="1"> <download-progress percentage="100"/> </event> </stream>

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