Тупо добавить поле вроде replace к самому обычному сообщению, чтобы сделать его сообщением-редактированием. Так сделано в XMPP и (предположительно) Telegram. Ну и просмотр истории сообщений немного пропатчить, чтобы эти replace учитывать, и пару дополнительных индексов в базе прокинуть — версионирование получится само по себе
И группы в ростере не показывает. И OMEMO-сообщение от Conversations расшировать не смог. Отправить зашифрованное сообщение тоже не позволяет, в замочке пункты не выбираются, хотя и OMEMO и PGP ключи есть. Не, на бету не тянет, максимум альфа
Не знаю, о каких B2C речь, мне достаточно того, что SASL работает в джаббере и почте, и работает хорошо. Другие примеры использования вы вполне можете найти самостоятельно, вас же в гугле не заба… а, ну да :(
Сравнивать с TIFF некорректно. Вас никто не заставляет реализовывать и читать абсолютно все алгоритмы — никто не запрещает вам оставить один-единственный PLAIN. Но если вы задумаетесь над комментами других хабраюзеров и захотите прекратить передавать пароль открытым текстом, то с SASL можно было бы просто взять готовый CRAM-MD5, а у вас сейчас, похоже, ничего подобного в протоколе ещё нет. (Здесь ещё можно было бы припомнить совместимость с другими существующими базами данных, но я сам не в теме)
Раз вы не хотите SASL, давайте проверим одну простую вещь — что нужно сделать, чтобы запилить в Tinode аутентификацию с помощью OAuth?
У вас там SASL-подобный велосипед, а если бы вместо SASL-подобного был бы сам SASL, то было бы меньше хаоса, больше совместимости с существующими реализациями SASL и меньше проблем с расширяемостью и безопасностью, потому что разработчики SASL уже продумали всё до вас и десятки страниц RFC посвящены не столько тому, что это такое, сколько тому, почему оно такое. Не ленитесь его почитать, тем более есть перевод на русский.
А Go слишком ересь, чтоб я на нём пулл-реквесты писал. Будущее за Rust!
Давайте я скажу тогда, что у нас реализовано подмножество SASL?
RFC 4422 предъявляет вполне конкретные (и довольно простые, несмотря на длину RFC) требования без всяких там подмножеств. Давайте вы не будете выпендриваться велосипедами и вносить дополнительную неразбериху в и без вас творящийся хаос в мессенджерах?
Стандарт же. SASL используется много где (хоть те же джаббер и почта), уже есть куча готовых реализаций и куча алгоритмов аутентификации на любой вкус (тот же CRAM-MD5). SASL абстрагирует механизм аутентификации от остального протокола (Tinode) и позволяет творить с аутентификацией что угодно, в том числе переиспользовать готовые реализации — а это уже должно быть полезно для разработчиков, которым не придётся городить велосипеды (ну или будет проще адаптировать и переиспользовать существующие велосипеды) (при нормальной архитектуре реализаций, конечно же, хех).
Сильно не вчитывался и могу ошибаться, но, как я понял, сейчас используется обычная PLAIN аутентификация, которая не очень хороша, потому что пароль попадает на сервер в открытом виде. Если очень хочется продолжить использовать PLAIN, то в SASL аналогичный алгоритм тоже есть.
Поменять несложно. Можно поподробнее?
В юзер-агентах всё свалено в одну кучу и каждый пишет что попало, а в jabber:iq:version по-нормальному разделены имя, клиент, версия и ОС — намного удобнее обрабатывать программно.
WhatsApp это не позволяет. Conversations не понимает XHTML-IM, полученный от другого «любого мессенджера». Сообщения без MAM теряются на плохом интернете. Мессенджеры без поддержки шифрования не могут прочитать сообщения с шифрованием. Серверы, требующие шифрование, не позволяют передавать сообщения мессенджерам, не умеющим в шифрование.
Немного мелочей по сабжу: не обнаружил в протоколе использования SASL, это не очень хорошо. CRAM-MD5, в который меня тыкали носом выше в комментах, есть в SASL, и поддержать всё это дело будет правильно.
Немного странно изобретать «random 64-bit number» вместо стандартного UUID.
Тырить юзер-агент из HTTP — плохая идея, это довольно убогая штука. Получение информации в том же XMPP сделана очень хорошо, например.
Лонг-поллинг не нужен. Вебсокет тоже избыточен, но фиг с ним, для веб-клиентов пригодится.
Пляска под чужую дудку — это как раз следование стандарту XMPP. Все по-настоящему независимые разработчики изобрели свои протоколы, не завися ни от кого (фейсбук, ВК, телеграм и т.п.) Один лишь WhatsApp оказался исключением, но много ли кастомных XMPP-клиентов подключаются и работают к WhatsApp-серверам?
А вот тут я уже на самом деле не в теме, как к этому отнесутся сотни серверов моих сотен контактов? Что-то я подозреваю, что presence type=subscribe им всё прилетит и побеспокоит их
Кстати, вот же ещё проблема — «удалится через 2 дня». В тех же телеграмах и ВК файлы хранятся вечно (хотя бы условно). В то время как далеко не каждый любительский джаббер-сервер типа этого вашего 404.city позволит себе вечное хранение файлов.
Я пролистал XEP-0363, но не увидел там никаких настроек про время жизни файла. То есть обычный пользователь даже не может прямо через клиент узнать, сколько его файл проживёт? Только ходить на сайт выглядывать едва заметную надпись «HttpUpload 1Gb & 2 day»?
Тупо добавить поле вроде replace к самому обычному сообщению, чтобы сделать его сообщением-редактированием. Так сделано в XMPP и (предположительно) Telegram. Ну и просмотр истории сообщений немного пропатчить, чтобы эти replace учитывать, и пару дополнительных индексов в базе прокинуть — версионирование получится само по себе
А чуть подробнее? Для OAuth нужны следующие шаги (примерно):
Как это запхнуть в интерфейс по вашей ссылке, я как-то не понял. Не исключаю, что я тупой и/или не выспался, расскажите как, а?
И группы в ростере не показывает. И OMEMO-сообщение от Conversations расшировать не смог. Отправить зашифрованное сообщение тоже не позволяет, в замочке пункты не выбираются, хотя и OMEMO и PGP ключи есть. Не, на бету не тянет, максимум альфа
И почему же?
Не знаю, о каких B2C речь, мне достаточно того, что SASL работает в джаббере и почте, и работает хорошо. Другие примеры использования вы вполне можете найти самостоятельно, вас же в гугле не заба… а, ну да :(
Сравнивать с TIFF некорректно. Вас никто не заставляет реализовывать и читать абсолютно все алгоритмы — никто не запрещает вам оставить один-единственный PLAIN. Но если вы задумаетесь над комментами других хабраюзеров и захотите прекратить передавать пароль открытым текстом, то с SASL можно было бы просто взять готовый CRAM-MD5, а у вас сейчас, похоже, ничего подобного в протоколе ещё нет. (Здесь ещё можно было бы припомнить совместимость с другими существующими базами данных, но я сам не в теме)
Раз вы не хотите SASL, давайте проверим одну простую вещь — что нужно сделать, чтобы запилить в Tinode аутентификацию с помощью OAuth?
А Go слишком ересь, чтоб я на нём пулл-реквесты писал. Будущее за Rust!RFC 4422 предъявляет вполне конкретные (и довольно простые, несмотря на длину RFC) требования без всяких там подмножеств. Давайте вы не будете выпендриваться велосипедами и вносить дополнительную неразбериху в и без вас творящийся хаос в мессенджерах?
Вот поэтому и нужно как можно скорее брать стандартный SASL, а не клепать ни с чем не совместимый велосипед без причины ;)
И в SASL это уже сделано до вас.
Ээ, серьёзно? Тогда не удивительно, чего презенсы на matrix.org вообще отрубали нафиг. Ещё один гвоздь в крышку гроба мертворожденного Matrix
Стандарт же. SASL используется много где (хоть те же джаббер и почта), уже есть куча готовых реализаций и куча алгоритмов аутентификации на любой вкус (тот же CRAM-MD5). SASL абстрагирует механизм аутентификации от остального протокола (Tinode) и позволяет творить с аутентификацией что угодно, в том числе переиспользовать готовые реализации — а это уже должно быть полезно для разработчиков, которым не придётся городить велосипеды (ну или будет проще адаптировать и переиспользовать существующие велосипеды) (при нормальной архитектуре реализаций, конечно же, хех).
Сильно не вчитывался и могу ошибаться, но, как я понял, сейчас используется обычная PLAIN аутентификация, которая не очень хороша, потому что пароль попадает на сервер в открытом виде. Если очень хочется продолжить использовать PLAIN, то в SASL аналогичный алгоритм тоже есть.
В юзер-агентах всё свалено в одну кучу и каждый пишет что попало, а в jabber:iq:version по-нормальному разделены имя, клиент, версия и ОС — намного удобнее обрабатывать программно.
WhatsApp это не позволяет. Conversations не понимает XHTML-IM, полученный от другого «любого мессенджера». Сообщения без MAM теряются на плохом интернете. Мессенджеры без поддержки шифрования не могут прочитать сообщения с шифрованием. Серверы, требующие шифрование, не позволяют передавать сообщения мессенджерам, не умеющим в шифрование.
Вывод: философия ХМПП не работает.
Немного мелочей по сабжу: не обнаружил в протоколе использования SASL, это не очень хорошо. CRAM-MD5, в который меня тыкали носом выше в комментах, есть в SASL, и поддержать всё это дело будет правильно.
Немного странно изобретать «random 64-bit number» вместо стандартного UUID.
Тырить юзер-агент из HTTP — плохая идея, это довольно убогая штука. Получение информации в том же XMPP сделана очень хорошо, например.
Лонг-поллинг не нужен. Вебсокет тоже избыточен, но фиг с ним, для веб-клиентов пригодится.
И это будет уже ни с кем не совместимый ХМПП. От этого нет никакой пользы.
Поэтому он не взлетел и никогда не взлетит.)
Пляска под чужую дудку — это как раз следование стандарту XMPP. Все по-настоящему независимые разработчики изобрели свои протоколы, не завися ни от кого (фейсбук, ВК, телеграм и т.п.) Один лишь WhatsApp оказался исключением, но много ли кастомных XMPP-клиентов подключаются и работают к WhatsApp-серверам?
А вот тут я уже на самом деле не в теме, как к этому отнесутся сотни серверов моих сотен контактов? Что-то я подозреваю, что presence type=subscribe им всё прилетит и побеспокоит их
Умножаем эти тысячи на сотни контактов, которые должны ответить на presence type=subscribe, и получаем сотни тысяч проблем с переносом JID :)
Я даже опущу кучу проблем, связанных с переездом. Но вы упорно игнорируете вторую часть всех моих комментов:
А также старательно забыли про нерабочий XHTML-IM в Conversations.
Я пролистал XEP-0363, но не увидел там никаких настроек про время жизни файла. То есть обычный пользователь даже не может прямо через клиент узнать, сколько его файл проживёт? Только ходить на сайт выглядывать едва заметную надпись «HttpUpload 1Gb & 2 day»?