XMPP/Matrix/Tox

[taked0wn]

Сегодня планирую обсудить насущный вопрос мессенджеров немного с другой точки зрения.
Я полагаю на постоянку исползовать что-то из вышеописанного и сейчас я объясню свою позицию.
Почему не SimpleX/Briar/Signal/Нужное вставить/etc... ответ очень прост. Под другие мессенджеры нет альтернативных клиентов, только оффициальные. Очень забавно наблюдать как пользователи форума дрочат на SimpleX который невозможно аудитить из-за сурцов на хаскеле, который так же не предоставляет альтернативных клиентов. Что по сути сводит вектор атаки до поставщика ПО. 3-ех буквенные приходят к разработчику и делают персональное обновление, что по сути самый вероятный и простой способ атаки на такое ПО. Что допустим сложно сделать с Matrix/XMPP/Tox потому что клиентов там множество, что уже снижает вектор атаки на пользователя.
Из списка я бы сразу выкинул Tox как морально устаревший, вопрос вашей анонимности при использовании мессенджера, должен решать не мессенджер, а вы. Хотите использовать vpn/proxy/tor ваше дело, мессенджер не должен вам навязывать способ связи. Как и отсутсвие нормального аудита + sdk для ботов.

Теперь поговорим за Matrix. Тут все тоже не очень однозначно.
1. Матрикс рекомендует использование https, хотя де-факто его использование в клиентах просто обязательно, что вынуждает делать форк клиентов для использования их в альтернативых сетях: i2p/onion. https://spec.matrix.org/v1.13/client-server-api/#api-standards

2. Множество метаданных передаются на сервер без шифрования: уведомления о печати/стикеры/реакции. Эти проблемы не исправляют годами, остается только догадываться чем это вызвано. https://github.com/matrix-org/matrix-spec/issues/660
3. Использование https для мессенджера впринципе не лучшая затея. Очевидно что это вызывает огромные задержки при его использовании.

4. Конкретно у меня не грузит вложения с matrix.org, ну и вот тоже интересное чтиво https://github.com/matrix-org/matrix.org/issues/2483

Касательно XMPP у меня вопрос к знатокам
1. Насколько мне известно XMPP использует udp + XML для передачи данных. Что куда быстрее чем реализация в matrix
2. Шифрования вложений по умолчению нет в клиентах (тут могу быть не прав, поправьте). Но это может быть поправимо.

Так например если решить проблему шифрования вложений то XMPP должен быть лучшим решением, на текущий момент, верно?

 

[Raskolnikov43]

Сегодня планирую обсудить насущный вопрос мессенджеров немного с другой точки зрения.
Я полагаю на постоянку исползовать что-то из вышеописанного и сейчас я объясню свою позицию.
Почему не SimpleX/Briar/Signal/Нужное вставить/etc... ответ очень прост. Под другие мессенджеры нет альтернативных клиентов, только оффициальные. Очень забавно наблюдать как пользователи форума дрочат на SimpleX который невозможно аудитить из-за сурцов на хаскеле, который так же не предоставляет альтернативных клиентов. Что по сути сводит вектор атаки до поставщика ПО. 3-ех буквенные приходят к разработчику и делают персональное обновление, что по сути самый вероятный и простой способ атаки на такое ПО. Что допустим сложно сделать с Matrix/XMPP/Tox потому что клиентов там множество, что уже снижает вектор атаки на пользователя.
Из списка я бы сразу выкинул Tox как морально устаревший, вопрос вашей анонимности при использовании мессенджера, должен решать не мессенджер, а вы. Хотите использовать vpn/proxy/tor ваше дело, мессенджер не должен вам навязывать способ связи. Как и отсутсвие нормального аудита + sdk для ботов.

Теперь поговорим за Matrix. Тут все тоже не очень однозначно.
1. Матрикс рекомендует использование https, хотя де-факто его использование в клиентах просто обязательно, что вынуждает делать форк клиентов для использования их в альтернативых сетях: i2p/onion. https://spec.matrix.org/v1.13/client-server-api/#api-standards
Посмотреть вложение 101554
2. Множество метаданных передаются на сервер без шифрования: уведомления о печати/стикеры/реакции. Эти проблемы не исправляют годами, остается только догадываться чем это вызвано. https://github.com/matrix-org/matrix-spec/issues/660
3. Использование https для мессенджера впринципе не лучшая затея. Очевидно что это вызывает огромные задержки при его использовании.
Посмотреть вложение 101552
4. Конкретно у меня не грузит вложения с matrix.org, ну и вот тоже интересное чтиво https://github.com/matrix-org/matrix.org/issues/2483

Касательно XMPP у меня вопрос к знатокам
1. Насколько мне известно XMPP использует udp + XML для передачи данных. Что куда быстрее чем реализация в matrix
2. Шифрования вложений по умолчению нет в клиентах (тут могу быть не прав, поправьте). Но это может быть поправимо.

Так например если решить проблему шифрования вложений то XMPP должен быть лучшим решением, на текущий момент, верно?

xmpp не использует udp!!
именно поэтому в скорости у хмрр нету поеимущетсва над матрикс.орг.
а вот про шифрование вложений ты верно подметил, можно использовать E2EE, через расширения OMEMO и OpenPGP (например)

 

[taked0wn]

xmpp не использует udp!!

Да, перепроверил использует TCP

именно поэтому в скорости у хмрр нету поеимущетсва над матрикс.орг.

А вот тут я не знаю основываясь на чем вы это говорите, насколько я вижу XMPP переиспользует TCP socket в отличии от Matrix https://xmpp.org/rfcs/rfc6120.html#streams. И вероятно производит обмен ключами лишь единожды при открытии сокета, что убирает необходимость использования TLS для каждого запроса, и позволяет обернуть сразу сокет. Так что тут как не крути работает оно быстрее чем HTTPS. Как будет время проверю это фактически, поснифаю клиент

а вот про шифрование вложений ты верно подметил, можно использовать E2EE, через расширения OMEMO и OpenPGP (например)

Они не шифруют вложения насколько я знаю, только ссылки на них. Сами вложения доступны на сервере в открытом виде по ссылке. Даже с включенным OMEMO/PGP

 

[Raskolnikov43]

Да, перепроверил использует TCP


А вот тут я не знаю основываясь на чем вы это говорите, насколько я вижу XMPP переиспользует TCP socket в отличии от Matrix https://xmpp.org/rfcs/rfc6120.html#streams. И вероятно производит обмен ключами лишь единожды при открытии сокета, что убирает необходимость использования TLS для каждого запроса, и позволяет обернуть сразу сокет. Так что тут как не крути работает оно быстрее чем HTTPS. Как будет время проверю это фактически, поснифаю клиент


Они не шифруют вложения насколько я знаю, только ссылки на них. Сами вложения доступны на сервере в открытом виде по ссылке. Даже с включенным OMEMO/PGP

Да, перепроверил использует TCP


А вот тут я не знаю основываясь на чем вы это говорите, насколько я вижу XMPP переиспользует TCP socket в отличии от Matrix https://xmpp.org/rfcs/rfc6120.html#streams. И вероятно производит обмен ключами лишь единожды при открытии сокета, что убирает необходимость использования TLS для каждого запроса, и позволяет обернуть сразу сокет. Так что тут как не крути работает оно быстрее чем HTTPS. Как будет время проверю это фактически, поснифаю клиент


Они не шифруют вложения насколько я знаю, только ссылки на них. Сами вложения доступны на сервере в открытом виде по ссылке. Даже с включенным OMEMO/PGP

matrix тоже использует tcp
например, для работы сервиса тебе требуется разрешить использование порта 8448/tcp
и если уже досконально, скорость зависит от сервера и клиента(их реализации)
я упомянул скорость к вопросу о использовании udp

ты прав

Они не шифруют вложения насколько я знаю, только ссылки на них. Сами вложения доступны на сервере в открытом виде по ссылке. Даже с включенным OMEMO/PGP

потому что шифруется metadata

если говорить о вложениях, про которых ты имеешь ввиду
в таком случае я придумал лишь одно решение, это шифровать их на уровне клиента(клиент шифрует вложение и передает на сервер)
но это уже расширения шифрования на стороне клиента

либо использовать сторонние методы.

 

[taked0wn]

matrix тоже использует tcp

HTTP. У вас технических знаний хватает, чтобы понять что HTTP на TCP основан или нет? Вы бы хоть почитали сначала спецификацию, чтобы не писать подобные глупости.

например, для работы сервиса тебе требуется разрешить использование порта 8448/tcp

Для S2S, тоже HTTP

и если уже досконально, скорость зависит от сервера и клиента(их реализации)

Только от части, клиенты обязаны реализовывать спецификацию, если протокол в ней выбран дебильный то как клиент не крути быстрее работать не сможет

в таком случае я придумал лишь одно решение, это шифровать их на уровне клиента(клиент шифрует вложение и передает на сервер)

Так например если решить проблему шифрования вложений то XMPP должен быть лучшим решением, на текущий момент, верно?

Уже говорил об этом в ОП посте, видел на форуме ребята писали о таких плагинах, но как я понимаю только часть клиентов таки поддерживает. Хотел бы узнать какие конкретно.

 

[Raskolnikov43]

HTTP. У вас технических знаний хватает, чтобы понять что HTTP на TCP основан или нет? Вы бы хоть почитали сначала спецификацию, чтобы не писать подобные глупости.
Посмотреть вложение 101606


Для S2S, тоже HTTP
Посмотреть вложение 101607


Только от части, клиенты обязаны реализовывать спецификацию, если протокол в ней выбран дебильный то как клиент не крути быстрее работать не сможет



Уже говорил об этом в ОП посте, видел на форуме ребята писали о таких плагинах, но как я понимаю только часть клиентов таки поддерживает. Хотел бы узнать какие конкретно.

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

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

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

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

то есть логическая цепочка:
протокол using http -> http using tcp -> протокол using tcp.
упомянул в контексте обмена вложениями.
это уместно
так тебе проще понять?

 

[taked0wn]

то есть логическая цепочка:
протокол using http -> http using tcp -> протокол using tcp.
упомянул в контексте обмена вложениями.
это уместно
так тебе проще понять?

Это технически 2 разных протокола и они работают по разному, матрикс использует именно HTTP/S, XMPP использует TCP это 2 абсолютно разных протокола, вы же говорите что разницы в скорости их работы нет, что является ошибкой. По вашей логике можно спуститься еще ниже и сказать что Matrix использует ARP для передачи данных, что только добавляет путаницы.

именно поэтому в скорости у хмрр нету поеимущетсва над матрикс.орг.

Это ложь. Так тебе проще понять? И matrix.org это вообще сервер. Кратко, вы не компетентны, удивительно что при этом вы имеете наглось выкладывать статьи о том что SimpleX это "убийца matrix"

 

[admin]

Есть у XMPP свои узкие места и проблемы. Я сейчас не о глобальных вещах, а о насущном. Спам (его до 90% в общем потоке трафа). Отсутствие шифрования вложений и оффлайн сообщений. HTTP File Upload - это ерунда (субъективное мнение). Ошибки конфигурирования серверов ваших собеседников. Но всё это решаемые задачи. Есть и фундаментальные проблемы. Моменты с кривизной реализации видео-голоса-стикеров-котиков (для нашей сферы неактуально). Отсутствие шифрования из коробки. Мало мобильных клиентов. Огромное количество XEP-ов, которые по сей день никто нормально не может реализовать и унифицировать. По сути ни в одном клиенте все функции протокола по сей день не реализованы, XMPP - это недооцененный монстр. Можно очень долго рассуждать, в т.ч. по каждому тезису. XMPP устаревший, но точно жизнеспособен.

 

[Gorg]

Есть у XMPP свои узкие места и проблемы.

А что думаете на счёт https://wiremin.org

Потенциал у проекта огромный - это конфиденциальный децентрализованный мессенджер и социальная сеть на протоколе Nostr⁠⁠, лучше чем SimpleX Chat, нет ограничений на размер файлов, есть звонки, что нет у других мессенджеров на протоколе Nostr.

 

[Raskolnikov43]

Это технически 2 разных протокола и они работают по разному, матрикс использует именно HTTP/S, XMPP использует TCP это 2 абсолютно разных протокола, вы же говорите что разницы в скорости их работы нет, что является ошибкой. По вашей логике можно спуститься еще ниже и сказать что Matrix использует ARP для передачи данных, что только добавляет путаницы.


Это ложь. Так тебе проще понять? И matrix.org это вообще сервер. Кратко, вы не компетентны, удивительно что при этом вы имеете наглось выкладывать статьи о том что SimpleX это "убийца matrix"

Мне кажется тебе стоит набраться опыта, далее не вижу смысла с тобой дискуссию вести.
Еще раз скажу: tcp и http это разные уровни протоколов в модели OSI, HTTP функционирует на основе заранее установленного соединения TCP. Еще раз для тебя переформулировал для тебя. Ваще х#йню лепишь.
А что касается твоего комментария - Matrix это в первую очередь протокол, зачем цепляться? Я упомянул орг. только для того, чтобы не было путаницы с одноименным проектом.

Свой негатив можно выплескивать и в других местах .
Что касается статьи, то я просто не рассматривал XMPP, в статье сравниваются два проекта, на сегодняшний день лидирующие за рубежом. Фавориты.
Убедись сам - https://forum.hackliberty.org/t/why...dark-truth-about-user-security-and-safety/224
Если, конечно, знаешь английский

 

[taked0wn]

HTTP функционирует на основе заранее установленного соединения TCP.

Это верно, но правда HTTP в зависимости от версии HTTP что использует клиент/сервер, скорость работы будет разительно отличаться. В matrix если сервер использует HTTP/1 то tcp сокет будет отдельно открыт на каждое соединение, что по сути приводит к низкой скорости работы и дабы было вам известно HTTP до 3 версии не поддерживает 0-RTT при использовании TLS, что по сути вынуждает выполнять TLS Handshake на каждый запрос для HTTP 1/2. Так же матрикс по умолчанию не поддерживает Server Side Push, что принуждает клиент использовать Long-Polling метод для получения обновлений.

В тоже время XMPP переиспользует сокет, выполняет TLS Handshake лишь единожды для всего соединения и позволяет серверу отправялть уведомления в этот сокет что разительно сокращает время доставки сообщений.

Так что как я и озвучивал выше это 2 разительно разных реализации, и их скорость работы отличается, что ты отрицаешь.

Мне кажется тебе стоит набраться опыта, далее не вижу смысла с тобой дискуссию вести.

Не веди, ты не компетентен.

Свой негатив можно выплескивать и в других местах .

А можно и здесь, это я уж сам разберусь что мне делать.

то я просто не рассматривал XMPP

Твои проблемы.

 

[taked0wn]

Спам (его до 90% в общем потоке трафа)

Это из-за уведомлений о присутствии? Какой траффик вы назваете спамом?

Отсутствие шифрования вложений и оффлайн сообщений

Разве наличие оффлайн сообщений не зависит от клиента? Или я не понял что вы имеете ввиду.

XMPP устаревший, но точно жизнеспособен.

Если допустим перед клиентом вешать прокси и модифицировать запросы которые летят до сервера, так можно наверное будет подправить проблемы спама и такой подход позволит использовать те клиенты что уже работают. Но с вложениями будет сложно, их шифровать в этой проксе будет сложно, потому что нужен обмен ключами с другими клиентами, для PM/групп, что реализовать уже не так просто. Просто у меня идея в голове засела о том чтобы подправить просто проблемы что сейчас есть и релизнуть прокси сервер который можно будет ткнуть по сути перед каждым клиентом что уже работают.

Ошибки конфигурирования серверов ваших собеседников.

Чем это грозит мне как собеседнику?

И еще возможно вы знаете, все запросы к серверу собеседника идут только через мой хомсервер, или нет? Может ли собеседник ликнуть мой IP при допустим подгрузке вложений?

 

[admin]

Это из-за уведомлений о присутствии? Какой траффик вы назваете спамом?

Это я обобщенно и грубо. Регистрация новых акков: 90 jid из 100 будут спам ботами. Часть из них регают просто (!) вручную. Количество сообщений: 50 из 100 сообщений будет спам рассылками. По-русски говоря, жабу засрали говном. Поскольку это распределенная сеть, невозможно решить проблему локально. Один сервер следит за спамом, а 20 других нет. Один админ устал, закрыл регу новых xmpp, два других установили из коробки и забыли о сервере, еще один следит за спамом ручками. И т.д. Тут нужны принудительные централизованные решения из коробки от разрабов. С принудительным отсечением от сети серверов, которые не обновились до последней версии. Такой себе антиспам манифест. Попытки были (не от разрабов), но потерпели фиаско. Этой проблеме лет 10-15.

Разве наличие оффлайн сообщений не зависит от клиента? Или я не понял что вы имеете ввиду.

Зависит от настроек сервера. Например, offline_msg. XEP-0160 и XEP-0313.

Если допустим перед клиентом вешать прокси и модифицировать запросы которые летят до сервера, так можно наверное будет подправить проблемы спама и такой подход позволит использовать те клиенты что уже работают. Но с вложениями будет сложно, их шифровать в этой проксе будет сложно, потому что нужен обмен ключами с другими клиентами, для PM/групп, что реализовать уже не так просто. Просто у меня идея в голове засела о том чтобы подправить просто проблемы что сейчас есть и релизнуть прокси сервер который можно будет ткнуть по сути перед каждым клиентом что уже работают.

Есть спам входящий, а есть исходящий. Если за исходящим можно как-то следить, то вот за входящим сложно. Или же нужно просто отключить s2s взаимодействие и сделать закрытый сервер. В каком-то условном onion, кстати. Но это полностью лишает смысла использование xmpp, сеть становится ограниченной и уже не распределенной.

Чем это грозит мне как собеседнику?

Например, вы общаетесь с server1.xmpp, у вашего собеседника server2_friend.xmpp. У вас супер секурные настройки, а на сервере server2_friend.xmpp включен XEP-0313 (Message Archive Management) или XEP-0136 (mod_archive). Все ваши сообщения будут аккуратно писаться в лог на серваке server2_friend.xmpp.

 

[stelthon]

XMPP-это открытый протокол(акцентирую), а не программа и не готовый проект из коробки без лишних наворотов, но при этом гибкий и расширяемый, в том числе с большим потенциалом в части безопасности. И отсутствие шифрования в отдельных его реализациях в виде серверов и клиентов "из коробки"-это скорее плюс, чем минус. Он действительно во многом недооценен, а скорее просто публично использован не весь его потенциал, а потому уж точно никак не уставший, и в своей нише как никогда актуальный и даже передовой, и еще долго будет таковым. Готовые решения/проекты(не протоколы соответственно) из коробки, тем более с готовыми сетями, такими как ТГ, с точки зрения безопасности пользоваться вообще нельзя по вполне очевидным и объективным причинам.

 

[reeves]

Если вам нужна безопасность используйте xmpp
не должно быть никаких голосовых, видео, картинок и другой херни, онли текст (который еще и через gpt прогонять нужно), закрыли сделку - удалили акк.

 

[bratva]

Если вам нужна безопасность используйте xmpp
не должно быть никаких голосовых, видео, картинок и другой херни, онли текст (который еще и через gpt прогонять нужно), закрыли сделку - удалили акк.

Слишком много "но" с хмпп, и эти "но" начинаются с сервера (какой ваш сервер? а какой сервер вашего собеседника?) и заканчиваются шифрованием сообщений (обратил бы внимание, КОГДА обновлялись многие плагины шифрования, когда был их аудит, какое количество разработчиков их поддерживают). Где вы договорились обменяться контактами? В идеале - вы должны выдать через безопасный канал связи (НЕ привнот) удаленный сервер - где будет установлен клиент, а потом удалить (иначе никто не гарантирует вам - что у вашего собеседника после сделки аккаунт будет закрыт, не будет хистори этой сделки и вы не будете записаны в его контакт-листе ником с форума).

Но проблемы ведь идут не с одноразовыми сделками - а с регулярными, как и с регулярными контактами. Джабер не соответствует современным требованиям того, что требуется от безопасного протокола и выигрывает только рядом с Телегой. Я тестирую сейчас SimpleX - это куда ближе к тому, как должен выглядеть современный протокол.

 

[Gorg]

Я тестирую сейчас SimpleX - это куда ближе к тому, как должен выглядеть современный протокол.

А почему не смотрите в сторону WireMin ? Ведь это по сути и есть улучшенный SimpleX, он так же на протоколе Nostr, но в нём нет ограничений на размер файлов и есть звонки.

 

[bratva]

А почему не смотрите в сторону WireMin ? Ведь это по сути и есть улучшенный SimpleX, он так же на протоколе Nostr, но в нём нет ограничений на размер файлов и есть звонки.

Не вводи, пожалуйста, людей в заблуждение Это НЕ Simplex и WireMin НЕ использует Nostr, а Bittorrent DHT + UDP. Код клиента закрыт = говорить не о чем + там еще были стремные попытки спамить свой клиент везде в интернетах (1, 2)

 

[g-man-original]

Всем привет, этот пост крик души!) Я давно общаюсь в jabber. И картина меня если честно не очень радует. Мало того что все сидят на старых клиентах. Так и не хотят переходить на новые и безопасные средства шифрования. Для примера взять тот самый популярный PSI+ который при закрытии до сих пор валится раз через раз от переполнения памяти. Я думаю это все потому что в нашей сфере идёт малое освещение новых технологий.

В мире мессенджеров и защищённой передачи данных безопасность и конфиденциальность являются ключевыми аспектами. Два популярных протокола для обеспечения безопасности обмена сообщениями — это OTR (Off-the-Record Messaging) и OMEMO (OMEMO Multi-End Message and Object Encryption). В этой статье мы рассмотрим, чем OMEMO превосходит OTR и почему стоит рассмотреть переход на этот более современный протокол.

Оба протокола open sources:
OTR : https://xmpp.org/extensions/xep-0364.html
OMEMO : https://xmpp.org/extensions/xep-0384.html

И так перейдём к плюсам!

1. Поддержка многопользовательских чатов
Одним из основных преимуществ OMEMO является его способность поддерживать многопользовательские чаты. OTR, в свою очередь, предназначен в первую очередь для одноразового общения между двумя участниками. Это ограничение делает OTR менее гибким в условиях, когда пользователи хотят общаться в группах. OMEMO позволяет шифровать сообщения для всех участников группы, что делает его более подходящим для современных мессенджеров.

2. Устойчивость к атакам "человек посередине"
OMEMO использует протокол Double Ratchet, который обеспечивает постоянное обновление ключей шифрования. Это означает, что даже если злоумышленник перехватит один из ключей, он не сможет расшифровать предыдущие или последующие сообщения. OTR, хотя и обеспечивает высокий уровень безопасности, не имеет такой же устойчивости к атакам "человек посередине", так как ключи не обновляются так часто.

3. Поддержка оффлайн-сообщений
OMEMO позволяет отправлять сообщения, даже если получатель в данный момент не в сети. Сообщения шифруются и сохраняются на сервере до тех пор, пока получатель не станет доступен. OTR, с другой стороны, требует, чтобы оба участника были онлайн одновременно для успешной передачи сообщений. Это делает OMEMO более удобным для пользователей, которые могут не всегда быть в сети.

4. Простота использования
OMEMO интегрирован в многие современные мессенджеры и приложения, такие как Conversations и Gajim, что делает его доступным для широкой аудитории. OTR требует более сложной настройки и может быть менее интуитивно понятным для новых пользователей. Простота использования OMEMO делает его более привлекательным выбором для тех, кто ищет безопасный способ общения без лишних сложностей.

5. Поддержка различных типов данных
OMEMO не ограничивается только текстовыми сообщениями. Он также поддерживает шифрование различных типов данных, включая изображения, видео и другие файлы. Это делает его более универсальным решением для обмена данными в различных форматах. OTR, в свою очередь, в основном ориентирован на текстовые сообщения.

Так же данный протокол использовался в chatSecure, что говорит о доверии к реализации алгоритмов.
И после этого был проведён аудит ; https://conversations.im/omemo/audit.pdf

Ну и собственно к чему это все? Давай те идти в ногу со временем? Я понимаю, что и omemo уже забросили как проект. Но он все же лучше даже в практическом плане. Нужно уметь принимать что-то новое.

 

[MaFio]

Друже, ты из какого года пишешь?