-
Notifications
You must be signed in to change notification settings - Fork 0
Target
- Придумать альтернативу скайпу
- Сделать то, чего недостаёт
Новая статья тут
Это на самом деле не такая простая тема, как кажется и как она сделана во многих мессенджерах и даже в самом скайпе мне во многом не нравится. Я вообще не видел ни одной полностью устраивающей реализации чатов. У нас в конторе очень много программистов работает на удалёнке, делается это так: на каждую задачу создаётся отдельный чат, в котором общаются все участники проекта, возможно несколько тематических разных чатов, когда, например, дизайн обсуждается отдельно. При таком использовании становится очень важным вопросом работа с историей чатов, чтобы все кто нужно мог прочитать и получить всё что было написано, а так же, желательно каким-то образом новым участникам давать возможность читать избранные места из предыдущей истории. Так же важен поиск по истории, нужны хеш-теги и ещё какие-то отметки.
Если смотреть не только на проблему разговоров в чате, но и общих данных по проектам, то необходимо иметь механизм публикации данных, совместных файлов, документов, картинок. Даже в отрыве от проектов, применительно к простым пользователям, вполне разумно уметь публиковать, например, фотографии для круга родственников, например, чтобы они всегда могли посмотреть что-то новое. Способ хранения не обязательно на компьютере, например можно каким-либо образом через облако сделать. Так же клиенты не обязательно могут грузить документы всегда из облака, можно настроить на автоматическую скачку документов локально.
по-моему лучше не "опубликованное" в отрыве от чата, а прямо в одном потоке: идёт череда сообщений, дальше например картинка (отправитель-дата-время-миниатюра), дальше ещё сообщения, потом файл и т.п. Таким образом сохраняется контекст, при котором видно, к чему данная картинка и файл. Безусловно, должна быть возможность скачать их в любой момент, включая все оптом за период времени.
Возможно и так, возможно что должна быть гдето отдельная панель с метками, файлами и пр. Т.е. ресурсы могут "принадлежать" какому-то чату, например, а могут быть просто опубликованы по типу файловой системы, чтобы любой, с достаточным количеством прав, мог их увидеть.
Все инстансы одного аккаунта должны всегда уметь синхронизироваться до актуального состояния. Типа пришёл с работы домой, включил тот же аккаунт, увидел ровно те же чаты, ресурсы и прочее. Если чего-то сделал из дома, оно автоматически отразилось на рабочем компьютере.
Если человек пропустил очень много, за какой период он скачивает историю?
Для простоты за весь. Хотя, конечно, можно придумать какие-то ограничители.
Передача файлов может рассматриваться как относительно медленный процесс и возможна реализация через протокол типа торрента.
Передача голоса и видео критичные к латенси процессы, под них необходимо иметь выделенные каналы возможно с выделенными серверами. В качестве протокола можно использовать IAX2 -- протокол из asterisk, можно через него же сделать и головосую связь, собственно, сразу и со шлюзами куда угодно.
то бишь IAX без собственно Астериска? Не слишком ли дофига велосипедов придется сделать?
IAX2 по сути контенер, нам важна его только клиентская сторона, это можно, наверняка, разобрать прямо из астериска, сервер можно поди совместно с астериском сделать. А что, думаешь с сипом меньше проблем? Его разделённость протоколов на сигнальный и данных -- это конкретный гемор, по опыту говорю, IAX2 именно этим отличается, что умеет в одном потоке мульиплексировать всё что нужно.
(cds)
будет ли это входить в некоторый стандарт (напр. XMPP - расширение XEP) или собственный протокол? Если да, то можно ли в XMPP реализовать некоторые фичи (напр. скачивание предыдущей истории, редактирование отправленного сообщения и т.п.)? Если нет, то как мы собираемся реализовывать клиентов для всех платформ (Windows, Unix/Linux, IOS, Android)? И серверов для первых двух?
Я мельком смотрел на xmpp. Даже если делать через него, то потребуются нетривиальные расширения, а значит придётся всё равно клиентов им учить. Я в этом плане хотел бы больше положиться на мультиплатформенность куте. Понимаю про "ещё один протокол" и пр, хотелось бы избежать -- но как? XMPP вообще расстраивает своей "разобранностью". В общем, на текущий момент, я бы рассматривал свой протокол и открытую реализацию клиента на чём-то довольно переносимом, типа куте.
а есть ли QT под Иос?
http://www.digia.com/ru/Digia/1/News/Qt-for-iOS/
http://habrahabr.ru/post/171739/
Да, необходим центральный сервер так или иначе, который будет заниматься авторизацией, распределением прав, передачей файлов голосом-видео и пр.
В таком случае, если мы выпускаем это в опенсурс, и позволяем открывать свои сервера, то как будет реализовано общение юзеров между разными серверами?
Как минимум открываем клиента, открывать ли сервер -- хороший вопрос, я бы не торопился. Общение между серверами не думал, это очень далёко ещё. Пока только думал, что для идентификации подлинности вполне сгодился бы механизм аналогичный DKIM.
Как будут выглядеть идентификаторы? Джаберовский user@example.com?
Ну как внешний вполне адекватный формат, внутренний я бы сделал что то типа SHA3('user@example.com'), с возможностью выключения видеть другим какой был "имейл" при идентификации.
Как будет обеспечиваться голос и видео, если юзеры за NAT и на разных серверах?
Тут два пути. Возможно, надо предусмотреть оба: 1) клиент-сервер-клиент; 2) клиент-сервер-сервер-клиент. Возможно, на этапе соединения надо протестировать канал и выбрать вариант с лучшим качеством. В случае 1 можно выбрать один из двух серверов, т.е. получается надо протестировать три варианта построения канала.
Как будет обеспечиваться безопасность (в свете последних событий со Сноуденом)? Шифрование всего на клиенте, хранение в облаке только шифрованных файлов? Как будет храниться не дошедший контент (пока получатель офлайн)?
Да, шифрование и ещё раз шифрование. Недошедший контент обрабатывается так: сервер помнит кто его уже получил и кому ещё надо отдать, соотно координирует. Если ты пытаешься отослать сообщение и никого в онлайне нет, то тут два варианта: 1) сообщение у тебя в очереди на отправку висит пока не удастся отправить; 2) принять на сервер и ждать появления в онлайне получателей, возможно одного первого, после чего сразу удалять с сервера, а раздаст остальным тот кто получил.
Что будет, если в чат 2-х человек, придёт третий? Кто ему отдаёт контент, и за какой период?
Тот, кто пригласил, ответственность на нём, в рамках того, что видит сам.
На тему офлайн хранения, 2 юзкейса:
-
приходишь с работы домой, на работе комп выключен - сообщения не получаешь, т.к. контент хранится на клиенте.
-
отправляешь сообщение собеседнику, который в офлайне, у тебя нестабильное соединение, ты отключаешься, и всё - он твоё сообщение не получит.
Выход: хранить все сообщения на сервере, но чтобы сервер не лопнул от контента, хранить можно только некоторый последний период (Garbage collector). N.B. сделать защиту "я это уже получил". У меня несколько раз было, что одни и те же сообщения приходили несколько раз.
Но если хранить на сервере, то сразу вопрос: каким ключом будет зашифрован контент на сервере? Например: чат из 5 человек, у каждого свой ключ, офлайн контент должен быть доступен для каждого. И вдруг в чат входит 6-й участник. Получается, что должно храниться 5 копий контента, и когда заходит 6-й, то приглашающий шифрует весь контент ключом 6-го, и выкладывает на сервер. На сервере 6 копий контента.
В случае 1 достаточно чтобы в какой-то момент времени был включен кто-то ещё, чтобы через третье лицо прошла синхронизация, точно как в скайп-чатах. В случае 2 у тебя сообщение будет в очереди отправки пока не отправится, точно как в скайп-чате. Хранение на сервере может быть допустимо, но только если сервер готов принять сообщение, например, можно разрешить 5 (обсуждаемо) оффлайн сообщений на посылающего клиента, последующие не принимать, клиент должен видеть, что сообщения не приняты и будут висеть у него во внутренней очереди на отправку.
Даже в случае 1 будут неудобства:
юзкейс: я общался с заказчиком, он пошёл спать, я уехал на дачу, достаю телефон, а там истории нет - и заказчик офлайн, и мой домашний бук выключен. GTalk в этом смысле просто офигенен - там хранится вся история чатов в Gmail. Предлагаю хранить некое множество сообщений на сервере, ограниченное либо к-вом¸ либо размером данных.
На тему передачи изображений: есть очень интересная задача - взять изображение (в т.ч. скриншот), и нанести сверху слой с комментариями (типа провёл стрелочку, и написал текст в блоке). Этих слоёв может быть несколько, и каждый из участников чата может нанести свой слой, и отключить у себя в просмотре любой из предыдущих слоёв. За такую фичу дадут миллион :)
Это какой то PSD получается :) Почему бы и нет.
Это даже больше чем PSD. В PSD нет мультиюзерности :) Там из инструментов достаточно линии, стелочки и текста, разными цветами.
Знаю, что многими такая фича востребована, вполен возможна к реализации.
Например, при добавлении в контакт-лист, стороны обмениваются открытыми ключами. Далее шифрование может идти по симметричному ключу, как это сделано в HTTPS (для скорости и ресурсо-экономии).
Как защититься от компрометации ключа одной из сторон? Генерить ключи периодически?
Как защититься от man-in-the-middle? Создать свой центр сертификации?
По этому поводу я помнится думал, что сервер должен хранить все публичные ключи всех клиентов что через него работают. А вот дальнейшие мысли не помню, уже больше года прошло как я эту тему думал.