Должен запускаться в любом современном браузере. Можно просто во вкладке открыть попробовать. По идее на большинстве устройств примерно после 2018 года должно работать. Трафик - практически как в обычном современном мессенджере.
Да, возможно из за гео это. Но несколько минут конечно это слишком. Подумаю что можно сделать. Напишите мне в Plumb или TG - если что придумаю чтобы мы могли протестировать на практике сразу)
Это конечно круто. Мое почтение. Крутой мощный язык, особенно для реалтайм систем.
Я пробовал на erlang писать, сначала как модули для ejabberd - что-то даже написал, но надолго меня не хватило, особенно когда бизнес-логику всех моих хотелок попытался реализовать. Конечно легаси ejabberd и xmpp сыграло роль. Но тем не менее - erlang есть erlang!
Видимо основное приложение почему-то не прогрузилось у вас. Попробуйте закрыть вкладку, проверить что интернет есть и достаточной скорости (чтобы приложение скачало в разумное время все ассеты для запуска), и открыть заново желательно в новой вкладке перейдя по ссылке. Если будут проблемы - напишите детали мне в TG (найти меня можете в нашей группе Plumb Early Birds)
Спасибо за такие добрые слова. Честно, очень приятно читать. Идея про «университетский курс» — это, конечно, красиво. Но боюсь, что после моего опыта такой курс будет больше похож на дневник выжившего в окопах борьбы с хаосом, чем на академический учебник.
Глава про протоколы будет называться «Почему XMPP прекрасен в теории и почему я больше никогда его не трону на практике». Раздел про криптографию сведется к одной фразе: «Не трогай, убьет. Начиная бери готовый TLS 1.3 и не выпендривайся». А лекция про инфраструктуру будет состоять из матерных логов упавшего сервера в 3 часа ночи и рассказа о том, как я пытался заставить два контейнера видеть друг друга. Это больше тянет на сборник баек у костра для уставших инженеров, чем на учебное пособие)
А вот «Превосходный Национальный Мессенджер»… боюсь, после такого «партизанского» курса получится только то, что обычно и получается, когда за дело берутся комитеты. Но за идею и поддержку — огромное спасибо. Значит, всё это не зря.
Справедливое замечание. И ответ на него — это как раз тот компромисс, на котором держится любой независимый проект хоть как-то касающийся людей.
Сразу оговорюсь: перлюстрации (автоматического или ручного чтения личных сообщений) - я буду стараться избегать как смогу, сколько смогу. Это мне и не интересно, ввиду преимущественно инженерных целей в проекте, да и в здоровом сообществе лучше когда этого нет. А вот модерация, в перспективе со строгим аудитом действий модераторов если они будут, — планируется. Архитектурно уже есть наброски, надеюсь смогу вскоре реализовать это. В целом планируется работать по классической схеме, как в старом добром интернете. Например, пользователь видит дичь (спам в публичном чате, угрозы, откровенная запрещенка) -> жмет кнопку «пожаловаться» -> я получаю алерт с ID нарушителя, ID чата и контекстом жалобы (например, несколько сообщений, на которые пожаловались). И предпочтительно ручной вердикт по этим нарушениям.
Конечно это не попытка построить «безопасное пространство» в корпоративном смысле. Это скорее цель сохранить в баре порядок, чтобы можно было спокойно поговорить, не опасаясь, что кто-то начнет кидаться стульями. Если кто-то кидается стульями — то вышибала (то есть на начальных этапах я) выводит разгорячившегося на улицу. Все просто.
А если кратко - то микросервисы, и использую все что попалось под руку. От Python для некритичных компонентов и быстрых прототипов, до Rust для небольших но критичных к производительности точек, если появляется bottleneck.
Если интересно конкретнее - первая версия была на Python FastAPI, еще пол года назад. Хорошая конкурентность, достаточная для IO-задач, простой и понятный язык. Потом с добавлением кучи функций я начал упираться в недостаточный RPS для моих целей, сложности с отладкой. В итоге где мог начал постепенно переходить на более серьезные языки.
А вообще если у меня будут силы и время - я планировал как нибудь написать на Хабр статью с чем именно я столкнулся, сила и слабости языков и подходов, компромиссы на какие пришлось идти, что сначала дает головную боль а что лишь потом потом но выносит голову совсем. Но это лишь в перспективе, пока еще даже не начинал писать это
Это пока заглушка для любых неизвестных данных. Но арзитектурно уже частино готовы механизмы по показу времени последнего посещения, с настраиваемым фильтрами приватности, но еще не отлажены и не стабильны. Как будут отшлифованны - будут более полноценно интегрированы
А gmail – это как дополнительный фильтр против ботов и абьюза. Гугл достаточно неплох в фильтрации ботов, и при этом у большинства живых людей скорее всего найдется хотя бы один gmail.
В теории - да, любое сообщение может быть прочитано. Как и в почти любом интернет-сервисе или мессенджере, где есть серверный поиск по сообщениям или пользовательскому контенту
На практике – лишь частично так. Читать чужие сообщения у меня нет ни времени, ни желания, ни сил; интересы у меня в проекте преимущественно в области инженерии и предпочтительно highload. А имею доступ к сообщениям только я, третьи лица не подпускаются. В расшифрованном виде они только на сервере, при покидании сервера сообщения шифруются - шифруются и при транспорте (пока они летят до вас они зашифрованы скучным и надежным TLS1.3), как и при бекапе БД. И я стараюсь как могу защищать сервер от атак и разных любопытных ботов. Относительно надежности сервера, чтобы не я в статье почти прямо прошу Хабровчан, технически подкованных людей, которые порой XSS/SQL-инъекциями перекусываю за завтраком, сломать мой сервер – чтобы на раннем этапе, пока почти нет пользователей, набить шишки и заткнуть все щели. Но пока взломать, как я понял, никому не удалось; а если кому-то и удастся, то я надеюсь этот Хабровчанин расскажет, как он это сделал, чтобы я мог усилить мой сервер. К тому же этот проект мой личный инженерный эксперимент, моя личная песочница; мы слишком малы и экспериментальны чтобы представлять для кого-то интерес по наблюдению.
Поэтому с большой долей вероятностью ваши сообщения никто никогда и не прочитает. Если будут жалобы явные - тут другой разговор, нужно будет разбираться. Но без этого - ваши любовные переписки особо никому и не нужны. Но как и писал в статье - я пока не рекомендую передавать тут особо чувствительные данные (например, банковской карты или паролей от чего-то важного);
Так или иначе, тут вам придется довериться мне. Или не довериться, и продолжать пользоваться тем, чему уже доверяете.
В будущем я надеюсь найти на уровне архитектуры баланс между модерируемостью и частной жизнью всех участников. Но пока как есть.
На самом деле xmpp (например, на ejabberd) как и например Matrix - замечательные современные решения
Matrix (на Synapse) - отличное полуготовое решение с настоящим (а не просто заявленным) E2E для самохостинга. Пробовал его. К сожалению Synapse написан в основном на Python (как я понял), и не самый шустрый - федеративность тут не только идеолоическая но но чисто техническая необходимость. Помимо Synapse есть альтернативные решения (например есть эксперименты на Rust) но они не поддерживают многого. Есть некоторые неудобства для меня как пользователя (например настоящий E2E жестко привязывается к конкретному устройству и использование аккаунта с нескольких устройств практически невозможно) И если на ПК клиенты для Matrix более менее адекватно работают, то на мобильных устройствах почему-то все печально с этим - тормознутость их мобильных клиентов я уж и не знаю чем объяснить.
xmpp (ejabberd) - отличное проверенное временем решение. Даже более того скажу - в первых версиях прототипа я и собирался сделать просто симпатичный клиент для ejabberd, просто обогатив его парой современных функций. Но попробовав это, протестировав - увидев что многие функции не отвечают современным паттернам мессенджеров (например слишком шумные MUC-комнаты, где расход на трафик и процессор растет в геометрической прогрессии с ростом количеством пользователей там), и вкусив всю сложность работы с Legacy системой при попытках хоть немного расширить функционал и понял что все это в итоге легче будет написать с нуля.
Да, интересно, спасибо. На самом деле парень @Mhessel красавчик. Выбрал хороший современный стек, который к тому же любят нейросети. React популярный, куча готовых компонентов, и достаточно хорош для фронтенда (особенно когда уже есть опыт работы с ним). Красивый дизайн для ПК. node.js который он выбрал для бекенда - также достаточно неплохой для бекенда (само собой когда на TypeScript, и хорош например в nest.js). Тут и единый язык с фронтендом, и хорошая конкурентность, и достаточная производительность для маленького проекта. Проблемы могут быть в нюансах, которыми в начале можно пренебречь - ошибки 5xx в главном потоке могут затронуть всех пользователей, может непредсказуемо вести себя под нагрузкой.
Но в целом, на самом деле хороший, современный проект, хоть какая-то альтернатива для связи.
Льстит, конечно, что мою гаражную поделку в коментариях к первой же публикации сравнивают с империей Дурова. Спасибо. Но давайте спустимся на землю. У Павла миллиарды, лучшие инженеры и статус глобального игрока. У меня — кофе, энтузиазм и Docker-контейнер. Я не ОРИ. И я не делаю коммерческий продукт на миллионы людей.
А если уж мой сервер внезапно начнет превращаться в даркнет и рассадник запрещенки — я сам выпилю этих юзеров без суда и следствия. Этот проект - мой личный инженерный эксперимент, и альтернативный канал связи для тех кто хочет хоть как-то связаться с близкими. Уж извините, без обид.
Конечно мне есть что скрывать) Там местами такой слой изоленты и хардкода, что от моего репозитория заплачет даже самый суровый сеньор, а мне придется краснеть за это.
Статья не о том, «как писать идеальный код», а о том, что живая система уже крутится и ее можно потрогать руками (и попытаться поломать, если получится). Кстати логи на фронтенде (см. DevTools) сейчас открыты очень богатые, можно отлично посмотреть что происходит и как это работает на практике. А исходники выложу когда мне самому перестанет быть за них стыдно. Сейчас моя цель — краш-тест архитектуры и приложения под нагрузкой и хаосом пользовательского поведения, а не код-ревью моего личного франкенштейна. Кому без гитхаба не читается — ваше право. Остальным — велкам на прод развлекаться и пробовать ломать транспорт.
За найденные баги с логином — спасибо. Логи вижу, буду фиксить. А с приходом кода на почту - код должен приходить достаточно быстро (по крайней мере достаточно быстро для того чтобы поймать добытый UIN) - проверь пожалуйста, не было ли первого сообщения с кодом в спаме? Детали можно писать в TG мне или непосредственно в моем мессенджере какой тестируем.
Ребят, я понимаю вашу боль, но давайте честно: я строю мобильный мессенджер для связи на ходу, а не корпоративный Slack для 27-дюймовых мониторов. Заглушка на десктопе и жесткая привязка к вертикали — это не палки в колеса, это суровая расстановка приоритетов. У меня две руки и 24 часа в сутках. После работы над бекендом и инфраструктурой, оставшиеся силы я решил направить на PWA, но чтобы оно вело себя почти как натив на телефоне, держало сокет и не жрало батарею. Чтобы мог пользоваться на телефоне я и мои близкие. Десктопный фронтент — отдельная песня, которую я пока не начинал петь.
Спойлер на будущее: когда допилю ядро и если получится создать и выложить SDK/библиотеку, кто угодно сможет написать хоть CLI-клиент для Linux, хоть десктоп на Электроне, хоть клиент для умного холодильника. А пока — эмулируйте мобилку в DevTools или открывайте с телефона.
Должен запускаться в любом современном браузере. Можно просто во вкладке открыть попробовать. По идее на большинстве устройств примерно после 2018 года должно работать.
Трафик - практически как в обычном современном мессенджере.
Да, возможно из за гео это. Но несколько минут конечно это слишком.
Подумаю что можно сделать. Напишите мне в Plumb или TG - если что придумаю чтобы мы могли протестировать на практике сразу)
Это конечно круто. Мое почтение. Крутой мощный язык, особенно для реалтайм систем.
Я пробовал на erlang писать, сначала как модули для ejabberd - что-то даже написал, но надолго меня не хватило, особенно когда бизнес-логику всех моих хотелок попытался реализовать. Конечно легаси ejabberd и xmpp сыграло роль.
Но тем не менее - erlang есть erlang!
Видимо основное приложение почему-то не прогрузилось у вас.
Попробуйте закрыть вкладку, проверить что интернет есть и достаточной скорости (чтобы приложение скачало в разумное время все ассеты для запуска), и открыть заново желательно в новой вкладке перейдя по ссылке. Если будут проблемы - напишите детали мне в TG (найти меня можете в нашей группе Plumb Early Birds)
Спасибо за такие добрые слова. Честно, очень приятно читать.
Идея про «университетский курс» — это, конечно, красиво. Но боюсь, что после моего опыта такой курс будет больше похож на дневник выжившего в окопах борьбы с хаосом, чем на академический учебник.
Глава про протоколы будет называться «Почему XMPP прекрасен в теории и почему я больше никогда его не трону на практике». Раздел про криптографию сведется к одной фразе: «Не трогай, убьет. Начиная бери готовый TLS 1.3 и не выпендривайся». А лекция про инфраструктуру будет состоять из матерных логов упавшего сервера в 3 часа ночи и рассказа о том, как я пытался заставить два контейнера видеть друг друга.
Это больше тянет на сборник баек у костра для уставших инженеров, чем на учебное пособие)
А вот «Превосходный Национальный Мессенджер»… боюсь, после такого «партизанского» курса получится только то, что обычно и получается, когда за дело берутся комитеты.
Но за идею и поддержку — огромное спасибо. Значит, всё это не зря.
Справедливое замечание. И ответ на него — это как раз тот компромисс, на котором держится любой независимый проект хоть как-то касающийся людей.
Сразу оговорюсь: перлюстрации (автоматического или ручного чтения личных сообщений) - я буду стараться избегать как смогу, сколько смогу. Это мне и не интересно, ввиду преимущественно инженерных целей в проекте, да и в здоровом сообществе лучше когда этого нет.
А вот модерация, в перспективе со строгим аудитом действий модераторов если они будут, — планируется. Архитектурно уже есть наброски, надеюсь смогу вскоре реализовать это. В целом планируется работать по классической схеме, как в старом добром интернете. Например, пользователь видит дичь (спам в публичном чате, угрозы, откровенная запрещенка) -> жмет кнопку «пожаловаться» -> я получаю алерт с ID нарушителя, ID чата и контекстом жалобы (например, несколько сообщений, на которые пожаловались). И предпочтительно ручной вердикт по этим нарушениям.
Конечно это не попытка построить «безопасное пространство» в корпоративном смысле. Это скорее цель сохранить в баре порядок, чтобы можно было спокойно поговорить, не опасаясь, что кто-то начнет кидаться стульями. Если кто-то кидается стульями — то вышибала (то есть на начальных этапах я) выводит разгорячившегося на улицу. Все просто.
Оо.. Сервер у меня полный фарш..
А если кратко - то микросервисы, и использую все что попалось под руку. От Python для некритичных компонентов и быстрых прототипов, до Rust для небольших но критичных к производительности точек, если появляется bottleneck.
Если интересно конкретнее - первая версия была на Python FastAPI, еще пол года назад. Хорошая конкурентность, достаточная для IO-задач, простой и понятный язык. Потом с добавлением кучи функций я начал упираться в недостаточный RPS для моих целей, сложности с отладкой. В итоге где мог начал постепенно переходить на более серьезные языки.
А вообще если у меня будут силы и время - я планировал как нибудь написать на Хабр статью с чем именно я столкнулся, сила и слабости языков и подходов, компромиссы на какие пришлось идти, что сначала дает головную боль а что лишь потом потом но выносит голову совсем. Но это лишь в перспективе, пока еще даже не начинал писать это
Просто Давно..)
Это пока заглушка для любых неизвестных данных. Но арзитектурно уже частино готовы механизмы по показу времени последнего посещения, с настраиваемым фильтрами приватности, но еще не отлажены и не стабильны. Как будут отшлифованны - будут более полноценно интегрированы
А gmail – это как дополнительный фильтр против ботов и абьюза. Гугл достаточно неплох в фильтрации ботов, и при этом у большинства живых людей скорее всего найдется хотя бы один gmail.
В теории - да, любое сообщение может быть прочитано. Как и в почти любом интернет-сервисе или мессенджере, где есть серверный поиск по сообщениям или пользовательскому контенту
На практике – лишь частично так. Читать чужие сообщения у меня нет ни времени, ни желания, ни сил; интересы у меня в проекте преимущественно в области инженерии и предпочтительно highload. А имею доступ к сообщениям только я, третьи лица не подпускаются.
В расшифрованном виде они только на сервере, при покидании сервера сообщения шифруются - шифруются и при транспорте (пока они летят до вас они зашифрованы скучным и надежным TLS1.3), как и при бекапе БД. И я стараюсь как могу защищать сервер от атак и разных любопытных ботов.
Относительно надежности сервера, чтобы не я в статье почти прямо прошу Хабровчан, технически подкованных людей, которые порой XSS/SQL-инъекциями перекусываю за завтраком, сломать мой сервер – чтобы на раннем этапе, пока почти нет пользователей, набить шишки и заткнуть все щели. Но пока взломать, как я понял, никому не удалось; а если кому-то и удастся, то я надеюсь этот Хабровчанин расскажет, как он это сделал, чтобы я мог усилить мой сервер.
К тому же этот проект мой личный инженерный эксперимент, моя личная песочница; мы слишком малы и экспериментальны чтобы представлять для кого-то интерес по наблюдению.
Поэтому с большой долей вероятностью ваши сообщения никто никогда и не прочитает. Если будут жалобы явные - тут другой разговор, нужно будет разбираться. Но без этого - ваши любовные переписки особо никому и не нужны. Но как и писал в статье - я пока не рекомендую передавать тут особо чувствительные данные (например, банковской карты или паролей от чего-то важного);
Так или иначе, тут вам придется довериться мне. Или не довериться, и продолжать пользоваться тем, чему уже доверяете.
В будущем я надеюсь найти на уровне архитектуры баланс между модерируемостью и частной жизнью всех участников. Но пока как есть.
На самом деле xmpp (например, на ejabberd) как и например Matrix - замечательные современные решения
Matrix (на Synapse) - отличное полуготовое решение с настоящим (а не просто заявленным) E2E для самохостинга. Пробовал его. К сожалению Synapse написан в основном на Python (как я понял), и не самый шустрый - федеративность тут не только идеолоическая но но чисто техническая необходимость. Помимо Synapse есть альтернативные решения (например есть эксперименты на Rust) но они не поддерживают многого. Есть некоторые неудобства для меня как пользователя (например настоящий E2E жестко привязывается к конкретному устройству и использование аккаунта с нескольких устройств практически невозможно) И если на ПК клиенты для Matrix более менее адекватно работают, то на мобильных устройствах почему-то все печально с этим - тормознутость их мобильных клиентов я уж и не знаю чем объяснить.
xmpp (ejabberd) - отличное проверенное временем решение. Даже более того скажу - в первых версиях прототипа я и собирался сделать просто симпатичный клиент для ejabberd, просто обогатив его парой современных функций. Но попробовав это, протестировав - увидев что многие функции не отвечают современным паттернам мессенджеров (например слишком шумные MUC-комнаты, где расход на трафик и процессор растет в геометрической прогрессии с ростом количеством пользователей там), и вкусив всю сложность работы с Legacy системой при попытках хоть немного расширить функционал и понял что все это в итоге легче будет написать с нуля.
Да, интересно, спасибо.
На самом деле парень @Mhessel красавчик. Выбрал хороший современный стек, который к тому же любят нейросети.
React популярный, куча готовых компонентов, и достаточно хорош для фронтенда (особенно когда уже есть опыт работы с ним). Красивый дизайн для ПК.
node.js который он выбрал для бекенда - также достаточно неплохой для бекенда (само собой когда на TypeScript, и хорош например в nest.js). Тут и единый язык с фронтендом, и хорошая конкурентность, и достаточная производительность для маленького проекта. Проблемы могут быть в нюансах, которыми в начале можно пренебречь - ошибки 5xx в главном потоке могут затронуть всех пользователей, может непредсказуемо вести себя под нагрузкой.
Но в целом, на самом деле хороший, современный проект, хоть какая-то альтернатива для связи.
Льстит, конечно, что мою гаражную поделку в коментариях к первой же публикации сравнивают с империей Дурова. Спасибо. Но давайте спустимся на землю. У Павла миллиарды, лучшие инженеры и статус глобального игрока. У меня — кофе, энтузиазм и Docker-контейнер.
Я не ОРИ. И я не делаю коммерческий продукт на миллионы людей.
А если уж мой сервер внезапно начнет превращаться в даркнет и рассадник запрещенки — я сам выпилю этих юзеров без суда и следствия. Этот проект - мой личный инженерный эксперимент, и альтернативный канал связи для тех кто хочет хоть как-то связаться с близкими. Уж извините, без обид.
Конечно мне есть что скрывать) Там местами такой слой изоленты и хардкода, что от моего репозитория заплачет даже самый суровый сеньор, а мне придется краснеть за это.
Статья не о том, «как писать идеальный код», а о том, что живая система уже крутится и ее можно потрогать руками (и попытаться поломать, если получится). Кстати логи на фронтенде (см. DevTools) сейчас открыты очень богатые, можно отлично посмотреть что происходит и как это работает на практике.
А исходники выложу когда мне самому перестанет быть за них стыдно. Сейчас моя цель — краш-тест архитектуры и приложения под нагрузкой и хаосом пользовательского поведения, а не код-ревью моего личного франкенштейна. Кому без гитхаба не читается — ваше право. Остальным — велкам на прод развлекаться и пробовать ломать транспорт.
За найденные баги с логином — спасибо. Логи вижу, буду фиксить.
А с приходом кода на почту - код должен приходить достаточно быстро (по крайней мере достаточно быстро для того чтобы поймать добытый UIN) - проверь пожалуйста, не было ли первого сообщения с кодом в спаме? Детали можно писать в TG мне или непосредственно в моем мессенджере какой тестируем.
Ребят, я понимаю вашу боль, но давайте честно: я строю мобильный мессенджер для связи на ходу, а не корпоративный Slack для 27-дюймовых мониторов.
Заглушка на десктопе и жесткая привязка к вертикали — это не палки в колеса, это суровая расстановка приоритетов. У меня две руки и 24 часа в сутках. После работы над бекендом и инфраструктурой, оставшиеся силы я решил направить на PWA, но чтобы оно вело себя почти как натив на телефоне, держало сокет и не жрало батарею. Чтобы мог пользоваться на телефоне я и мои близкие. Десктопный фронтент — отдельная песня, которую я пока не начинал петь.
Спойлер на будущее: когда допилю ядро и если получится создать и выложить SDK/библиотеку, кто угодно сможет написать хоть CLI-клиент для Linux, хоть десктоп на Электроне, хоть клиент для умного холодильника. А пока — эмулируйте мобилку в DevTools или открывайте с телефона.