Я зробив український месенджер без номера телефону. P2P, E2E прямий зв’язок між пристроями
Я PHP/FullStack-розробник, а останнім часом багато працюю ще й з Flutter та локальними/хмарними AI-інструментами. У якийсь момент захотілося зробити месенджер не навколо чергової реєстрації за номером телефону, а навколо зовсім іншої моделі.
Так з’явився YaTut’Ye.
Головна ідея проста: номер телефону не повинен бути вашою цифровою особистістю.
При першому запуску користувач отримує власний унікальний YaTut’Ye ID. Не потрібно вводити номер телефону, email чи інші особисті дані. Щоб додати людину, достатньо передати їй свій ID, посилання або QR-код.
Але найбільше мене цікавила не реєстрація, а сама архітектура передачі даних.
У більшості месенджерів схема приблизно така:
телефон → серверна інфраструктура → телефон
У YaTut’Ye я намагаюся максимально використовувати:
телефон ↔ телефон
Тобто якщо мережа дозволяє встановити пряме з’єднання, повідомлення, файли та дзвінки передаються безпосередньо між пристроями.
Зараз для цього використовується WebRTC/ICE/STUN, IPv6 та IPv4 NAT traversal. Якщо прямий маршрут неможливий через CGNAT, symmetric NAT або інші обмеження мережі, є relay/TURN fallback.
Тому я навмисно не пишу «взагалі без серверів». Серверна інфраструктура поки потрібна для signaling, discovery, fallback і доставки повідомлень офлайн-користувачам.
Але принцип такий:
direct first → relay only when necessary.
Контент при цьому захищений наскрізним шифруванням.
Моя наступна велика ціль — поступово винести ще більше функцій із центральної інфраструктури в мережу Super Nodes. Ідея схожа на старий Skype: частина активних клієнтів з хорошою доступністю може допомагати іншим користувачам з маршрутизацією та TURN-relay.
У перспективі хочу дійти до стану, коли центральний сервер буде не обов’язковою точкою роботи мережі, а лише одним із bootstrap/fallback-вузлів.
Що вже є в YaTut’Ye:
- повідомлення, фото та файли;
- аудіо- та відеодзвінки;
- прямий P2P-маршрут там, де він доступний;
- YaTut’Ye ID замість номера телефону;
- додавання за ID, посиланням або QR;
- групи, приватні клуби, публічні форуми та канали;
- налаштування того, хто може писати та телефонувати;
- нагадування про конкретне повідомлення;
- вбудований AI-помічник;
- Android-версія вже дійшла до production у Google Play.
Окрема тема — privacy.

Я не хочу будувати продукт навколо збору максимальної кількості інформації про користувача. YaTut’Ye не потребує номера телефону як основного ID і не створювався для аналізу приватного листування заради рекламного профілювання.
Залишаються питання client security, key management, signaling, metadata, компрометації кінцевого пристрою, relay-вузлів, multi-device та майбутньої децентралізації discovery.
Саме тому мені зараз особливо цікавий фідбек технічної аудиторії DOU.
Що б ви ламали в такій архітектурі в першу чергу?
Які сценарії NAT/CGNAT я недооцінюю?
Наскільки, на вашу думку, життєздатна модель community Super Nodes на мобільних та desktop-пристроях?
І головне — чи бачите ви сенс у месенджері, де прямий зв’язок між пристроями є основним маршрутом, а центральна інфраструктура поступово стає лише fallback-рівнем?
Я не очікую поблажливості — навпаки, якщо бачите слабке місце, напишіть.
Сайт проєкту: yatutye.com/uk
Якщо тема буде цікава, можу окремим постом детально розписати NAT traversal, WebRTC, TURN/Super Nodes і те, як я хочу поступово прибрати залежність від центрального сервера.
56 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівНазва сподобалась)
Цікаво, але назву я б обрав якусь простіше. Все питання в розповсюдженні. Телега є у всіх, тож нею і користуються, не дивлячись на недоліки.
Назва вже є, мені подобається, просто і добре запам’ятовується. А розповсюдження
я згодне це найскладніше, тому потрібні якісь такі холівари, скандали тощо. ось лякати вже хтось намагається навіть тут, мені якраз і треба це, Ya Tut Ye, але навіть я навряд чи зможу чимось допомогти, на відміну від Дурова, комусь чимось, тому що сам не можу навіть за бажання перехопити прямий п2п трафік наприклад, не кажучи про те, щоб розшифрувати щось.
Запропонуйте використовувати цей месенджер в оборонпромі, додати його в Дію, та виділити державне фінансування на розробку.
як тільки через вас продадуть першу дозу наркоти — вас прикриють. і ніяка децентралізованість не допоможе. не живіть утопією
Так IP же виден и так. Тут скорее удобство в передаче данных.
думка цікава хоч і смішна, особливо про утопію... ось умієте ви повеселити, спасибі.
Тобто ви реально вважаєте, що я посередник, раз через мене продавати щось будуть це не утопія?
Ну а про децентралізовану систему, спробуйте прикрити біткойн наприклад? щось не дуже виходить ні в кого прикрити тому що утопія мабуть, та й телеграм там же, звичайно, все ідеально і жодної дози наркоти через Дурова не пройшло ж :)
То Дурова посадили
і тепер телеграм ймовірно перестав бути безпечним, ваші дані з телеграм можуть бути доступні кому буде потрібно, а можливо вже і повністю моніторяться, ніхто не знає що у Дурова на серверах і що він робить з вашими даними.
І ось це показує що моя програма більш захищена від цього, ваші дані тільки ваші, через сервера проходить тільки одиничні повідомлення і файли виключно якщо вам відправили в офлайн щось. Але для безпеки ви самі вибираєте відправляти в офайн щось важливе або почекати кілька секунд, поки користувач з’явиться в онлайні після отримання повідомлення та прочитання першого повідомлення.
І навіть якби мене посадили, я б навіть теоретично не зміг би нічим допомогти ні поліції ні комусь ще й навіть якщо сервера вилучити жодних даних користувачів крім списку контактів і то не аутентифікованих нічого не знайдуть.
Ні, бо ваш сервер завідує:
— тим, який пристрій вважається «моїм» — саме сервер може повідомити або не повідомити мої контакти про зміну пристрою.
— моїми контактами.
— моїми чатами.
І я вважаю, що отримати доступ до вас, чи навіть зламати ваш сервер, набагато простіше, ніж зробити це ж з Дуровим. Бо в нього купа грошей, і він у Франції.
Ну до мене можно доступ отримати без проблем :) «я ж тут є» а от зламати сервер спробуйте, я можу навіть допомогти вам, навіть цікаво, я можу навіть дати вам рут пароль сервера, хочете спробувати?
Ні, я не спеціаліст на цьому. Думаю, вам дебажити телефонію також не було б цікаво.
все, цього достатньо.
відправив один користувач файл з дитячою порнографією іншому користувачу — і він зберігся на сервері.
далі маски-шоу і тебе прикривають за зберігання/розповсюдження дитячої порнографії.
якийсь «товариш майор» навіть сам перед тим «забезпечить», щоб на сервері такі файли опинились.
так вони ж зашифровані на сервері нікто ніколи не зможе відкрити цей файл, навіть я, навіть якщо мене будть катувати, приватні ключі зебрігаються виключно на присторях користувачів і тількі на цьому пристрої можливо побачити, поки файл не скачається на телефон ніхто не зможе його побачити, і тоді він одразу видаляїться з сервера, довести що саме цей файл має такий зміст неможливо.
Можливо, вилучивши чи заразивши пристрій одного з користувачів. Зрештою, так і роблять, коли розслідують злочини.
мова йшла про сервер, коли файл на телефоні його вже немає на сервері:)
Коли файл на телефоні відправника, і цього відправника заарештували?
а якщо зламають, наприклад, телеграм або вотсап і все в публічний доступ викладуть?
У YaTut’Ye навіть злом сервера безглуздий, тому що ніяких даних там немає, а балансувальник переключиться на інший сервер і все буде працювати як працювало
1) Як мінімум можуть підмінити ШІ, котрий фільтрує спам — і фільтруватимуть патріотичні меседжі замість спаму. Або вставлятимуть непатріотичні до публічних груп.
2) Можуть розіслати усім контактам потрібних людей меседж, що змінився пристрій, або деактивувати пристрої потрібних людей одночасно — і таким чином паралізувати роботу спільноти.
3) Можуть отримати ІП адреси усіх контактів, та усіх їх контактів. І подивитися, як вони називають себе в публічних чатах, та що там пишуть.
4) Доволі імовірно, що ваш софт не без дірок, і зламаний сервер спростить отримання віддаленого доступу до клієнтських пристроїв.
не можуть ні підмінити щось ні розіслати, і тим більше список всіх IP адрес, у кращому випадку кеш редіcа за останні 20 хвилин, але там немає ні логінів нічого, і ніхто нічого не зрозуміє навіть, ви просто не знаєте, як влаштовано все всередині. Ну ШІ теоретично можуть підмінити хвилин на 5 не більше, але це теж не просто, база даних знаходиться окремо прямого доступу до неі зовнi нема, сигнальний сервер, роут сервер не один, вони маленькі і прості з автоскалом, вони в хмарі на балансувальнику, як тільки щось не так з сервером одним, переключиться на інший автоматично, поки там хтось розбереться що там і до чого, я видалю сервер i розорну новий чистий сервер, а той який зламали зроблю копію та видалю, на копії ізольовану знайду дірку закрию та задеплою на всі сервери апдейт.
Але ймовірність того, що я дізнаюся про спроби злому і заблокую раніше набагато вище.
Тоді питаннячко: от людина пише меседж до публічного чату на 500 учасників — куди її пристрій надсилає меседж, щоб він відобразився на інших пристроях? На рівні TCP/UDP, будь ласка.
А як ви дізнаєтеся, що щось не так? Просто трафік від певних груп перенаправляється на сторонній ШІ сервер.
Публічні виключно на сервер абсолютнно классична модель кліент-сервер
Ну є певні засоби та запобіжники, мені приде повідомлення як буде невдалі спроби злому, ддос, якщо хтось зайде під рутом, тай і стандартні firewall, fail2ban непогано пряююсть, я закрываю доступ на все крім API додатка, як мені треба щось оновити, то в хмарі відкриваю доступ тільки на свій IP раблю щось і закриваю, тому легко можу дати рут пароль сервера, ніхто нічого не зробить.Непомітно щось змінити на сервері майже не можливо.
До речі навіть цю теоретичну можливість я вже закрив, дякую вам, я додав вже серверний захист, якщо ШІ налаштування відрізняютсься на якомусь сервері то додавання постів та коментів в пабліках блокується а мені повідомлення одразу приде.
А звідки сервер знає куди надалі це повідомлення спрямувати?
ну це вже зовсім дивне питання, у базі даних все зберігається приблизно так само як на цьому сайті, клієнт відкрив паблік, надіслав запит на сервер, отримав контент
Себто, у вас клієнти періодично пуллять паблік, але сервер не знає, хто є в пабліку, і не може відслідкувати, хто його пуллить?
І цей пулл є енергоефективним для клієнтських пристроїв?
Хорошая идея и интересный проект. Вспомнилась Threema сразу, потому что там без телефонов. Я правильно понимаю, что IP собеседника будет виден остальным в случае прямого общения?
IP не виден остальним, и даже сервер не хранит нигде только небольшой техничекскй кеш в redis хранится минут 20, без привязки к пользователю, но IP друг друга можно увидеть приложении и посмотреть полний текущий роут, если включить в настройках.
А в чём разница между «остальных» и «друг друга»?
В целом может быть удобно для обмена файлами.
остальные — другие контакты и группы, сервер тоже по сути не видит, первая попытка прямого соединения например если вы в локальной сети на одном WiFI ничего за пределы вашей WiFi не уходит вообще.P2P это прямая связь между двумя устройствами без внешних серверов и они конечно видят друг друга. Да для обмена файлами удобно и быстр. И не только файлами. Качество связи значительно лучше, и аудио и видео звонки потому что нет никаких посредников. Телерам очень часто качество звука временами плохое, задержки большие даже при иделаьных условиях в одной сети.
А можете пояснити, які у цього проекту переваги перед Jami, *Tox, Session?
Jami та Tox — так, це справді близькі P2P-аналоги. Session — вже ні: там повідомлення onion-routed через мережу Session Nodes і зберігаються у swarm, тобто direct device-to-device між співрозмовниками немає.
З Jami/Tox питання не в тому, що P2P у них немає — воно є. Питання в практичній доставці на мобільних пристроях, коли peer offline, Android/iOS прибив background process або direct connection неможливий. Саме тому в YaTut’Ye я не роблю «pure P2P будь-якою ціною»: direct-first, але є TURN/relay і тимчасовий encrypted mailbox для offline delivery.
Jami/Tox довели, що direct P2P працює. Session/SimpleX довели, що для нормальної доставки потрібен asynchronous fallback. Я намагаюсь поєднати обидва підходи: direct-first, але без жертви надійністю доставки.
YaTut’Ye це гібрид, для користувача все так само як звичайний мессненджер телеграм або вотсап.
Якщо ви користувались цими додатками, то спробуйте YaTut’Ye, буде цікаво почути порівняння.
До того ж я додав фічі яких немає ніде, і яких мені особисто невистачає, це нагадування в один дотик біля кожного повідомлення, ШІ та автовідповідач з відео, а також робота на WiFi без Інету, зараз у нас дуже актуально наприклад війсковим, можна розкинуті WiFi мережу навіть на шарингу на мобильніх телефонах, автовідповідач з відео як система видеонагляду у польвих умовах можна мати якийсь звязок.
Номер телефону не повинен бути вашою цифровою особистістю! Вашою цифровою особистістю має бути АйДі, посилання, або КуАр-код! Я все вірно зрозумів? Ааа, точно! І телефон!
Якщо не хочете зайвої реклами та не хочете щоб ваш номер телефону або email не попав в базы спамерів та різні бази, та і взалгалі довіряти якомусь невідомому мессенджеру свої реальні данні то це погано? треба було зробити с номером телефону чи email ? Так беспечніше? А з ID взалгалі вкрай важко визначити вашу особистість що ви це ви і це ще один рівень безпеки і захисту.
Тобто про те, що саме з АйДі месенджери і починалися, що, до прикладу, в Телезі можна не світити номер телефону, а у закриті групи спам ніхто (крім її членів) не напише — ви не в курсі? Про П2П платформи для комунікацій — також?
Так, звісно, ID і P2P самі по собі не нові — я цього й не стверджую.
Різниця в тому, як саме побудована система за замовчуванням.
У Telegram номер можна приховати від інших користувачів, але сам акаунт усе одно прив’язаний до номера телефону. Telegram прямо пише, що кожен номер телефону — це окремий акаунт. Крім того, звичайні Cloud Chats у Telegram не є end-to-end: E2E використовується окремо в Secret Chats.
У YaTut’Ye інша модель:
• номер телефону й email взагалі не потрібні для створення identity;
• ID генерується автоматично;
• звичайне особисте спілкування одразу будується як захищене;
• трафік іде напряму між пристроями;
• relay server використовується як fallback, а не як обов’язковий маршрут;
• у перспективі discovery/relay теж хочу максимально винести в Super Nodes.
Це не мій «винахід ID» чи «винахід P2P». Ідея саме в поєднанні no-phone identity + direct-first transport + E2E + поступової децентралізації.
Якщо знаєте живий масовий месенджер, де саме така модель є основною за замовчуванням — дайте посилання, реально цікаво порівняти архітектуру.
Останній аргумент — хріновий, бо так можна і до мишей, ну, самі знаєте. Фіча-сет обумовлений або потребами користувачів або баченням автора, це очевидно. А як плануєте відновлювати доступ, якщо ідентифікатор створюється платформою, та не привʼязаний ні до чого? Я зовсім не мав на меті критикувати, і не вважаю «винахід велосипеду» зовсім безглуздою ідеєю, особливо якщо це робиться заради задоволення, але мені здалося, що ви описуєте свій продукт ледь не як революцію.
я не намагаюся подати це як «революцію» в сенсі винаходу нових фундаментальних технологій. Майже всі складові окремо давно існують. Мені цікава саме їх комбінація і те, щоб вона була default-поведінкою, а не опцією десь у налаштуваннях.
Відновлення тут навмисно обмежене. Є пароль: знаєте його — можете увійти з нового пристрою, при цьому старі дані видаляються, а ключ шифрування автоматично змінюється.
А можно взагалі без паролю створити акаунт, ну чим вам не революція:) ... тільки логин потрібен і все, пароль можно дадати потім. Це вже є і працює, можете встановити додаток та переконатісь в цьому.
Забули пароль + втратили телефон — акаунт втрачено назавжди. Ніяких recovery key, email чи номера телефону для «чарівного відновлення» немає і не планується.
Це свідомий компроміс: краще втратити акаунт, ніж залишити механізм, через який хтось інший потенційно зможе відновити доступ до ваших даних.
en.wikipedia.org/wiki/Jingle_(protocol
Threema?
Ні, головна відміність це P2P first, а Threema централизований все йде через сервера, тому данні можуть бути збережені та використані і разшифровані хочаб теоретично, а P2P це прямий звязок телефо-телефон без серверів сторонніх. Якщо ви в офісі на одном WiFI розмовляєте то якщо зникне Інтернет то будь який мессенджер одразу перестане працювати, а з YaTut’Ye навіть не помітите що Інтернету нема, тому же прямий коннетк без зайвих серверів та хопів роута
Ви перевигадуєте SIP/RTP
не зовсім, я не перевигадую а використовую тільки RTP але це P2P а не SIP сервер, я скоріше перевигадую старий доМайкрософтний Skype, якщо буде багато користувачів онлайн то взагалі можно без сервера працювати за рахунок SuperNod-ів, такий собі мікс торента з блокчейном роскиданий на всіх телефонах які в онлайні
В оригіналі, SIP — це протокол управління, і він йде через сервер. RTP/RTCP йде напряму між клієнтами після того, як сервер узгодив їх порти та кодеки.
Ви все одно не можете обійтися без сервера, бо клієнти сидять за DHCP чи NAT — себто, один клієнт не знає адресу іншого. А коли з’єднання встановлене — то ви так само викидаєте сервер із ланцюжка обміну даними, як це робить SIP.
Але SIP відлагоджений десятиріччями, і має купу готового софту, а ви наразі робите своє — котре, імовірно, матиме проблеми з реальними сетапами (скільки там типів NAT існує?) та не буде баг-фрі доволі довгий проміжок часу.
Частково згоден, але тут є кілька важливих відмінностей.
По-перше, я не пишу власний NAT traversal і не намагаюся заново вирішити десятиліття мережевих проблем. У YaTut’Ye використовується стандартний стек WebRTC / ICE / STUN / TURN. ICE сам збирає кандидати, перевіряє реальну досяжність між ними і, якщо direct не проходить через CGNAT, symmetric NAT або firewall, переходить на relay.
Тобто проблема «скільки існує типів NAT» не вирішується моїм самописним кодом — цим займається давно обкатаний WebRTC/ICE стек.
По-друге, SIP — це signaling. RTP може йти напряму, тут ви праві. Але це лише медіа. У YaTut’Ye direct-first стосується не тільки дзвінка, а й повідомлень, фото, файлів та іншого трафіку через WebRTC DataChannel.
І в реальних SIP/PBX системах RTP далеко не завжди залишається direct: SBC, PBX, RTP-proxy, запис дзвінків, transcoding, NAT traversal дуже часто залишають сервер у media path. Direct RTP — можливість SIP-архітектури, а не гарантія.
По-третє, сервер для rendezvous/signaling зараз справді є — я цього не заперечую. Але це зовсім не означає, що він фундаментально потрібен як центральна точка мережі.
Сьогодні:
A → signaling → B
A ↔ B — дані напряму, якщо маршрут доступний.
У перспективі:
DHT / Super Nodes → discovery + signaling + relay
Тобто центральний сервер можна залишити лише bootstrap/fallback-вузлом або взагалі зробити необов’язковим. Саме таку модель я й маю на увазі, коли згадую старий Skype.
До речі, DHCP тут майже ні до чого. Проблема — NAT, CGNAT, firewall та endpoint mapping/filtering.
І ще цікавий практичний момент: якщо прямий канал вже встановлений, зникнення зовнішнього інтернету саме по собі його не руйнує. А в одній LAN можна взагалі працювати через локальний direct route без виходу трафіку в інтернет.
Тому я б сказав, що я не «перевигадую SIP». Я використовую вже готові механізми WebRTC, але будую на них іншу модель:
no-identity + E2E + direct-first для всіх типів даних + distributed relay/discovery у перспективі.
Усе перераховане і є медіа — себто, data plane.
А у вас ці функції не залишать сервер на шляху, бо вони будуть відсутні?
DHCP до того, що IP адреса клієнта змінюється. Відповідно, без сервера зі статичною адресою клієнти не знають як законектитися один до одного.
Як і з SIP. Коли ми робили телефонію на базі pjsip, то в налаштуваннях була опція прямого конекту до співрозмовника за IP адресою, без сервера взагалі.
Так, data plane тут точніше, з терміном погоджуюсь.
Щодо SBC/PBX/transcoding/recording — саме так: у YaTut’Ye я свідомо не хочу таких server-side функцій у direct path. Якщо direct можливий — дані йдуть device↔device. Якщо ні — TURN/relay як fallback. Тобто сервер з’являється в data path лише коли без нього мережево не обійтися.
DHCP сам по собі не проблема — клієнту не потрібно «пам’ятати» IP іншого клієнта. Поточні адреси/ICE candidates узгоджуються під час встановлення сесії. Але так, для першого rendezvous зараз сервер потрібен — я цього й не заперечую. В перспективі цю роль можна рознести між Super Nodes/DHT.
А прямий SIP по IP — так, аналогія правильна. Різниця не в тому, що «direct connection ніхто не робив», а в тому, що в YaTut’Ye це default transport для всього data plane, а не опція для окремого SIP/RTP сценарію.
p.s.
І ще є один плюс що це працює там де без VPN інші мессенджери нормально не працюють.
Воно працює доки не зайняло суттєвий шмат ринку — коли під нього підберуть DPI сігнатури, і за ними обріжуть трафік.
От я зараз в Телеграмі сиджу в чатах на 350 та 500 людей. Як ви такі масові чати імплементите?
можливо і підберуть сігнатури, а можливо і ні, не хочу деталі розкривати щоб не спростити цей підбір але це важко буде зробити, а якщо зроблять то багато чого перестане працювати в таких провайдерів, а коли багато людей в мережі онлайн то буде ще й через SuoerNode йти то взагали вкрай важко буде зробити якесь блокування.
Груповы чати P2P дуже просто і обмежень немає, повідомлення передаються на всі телефони групи тільки p2p, якщо хтось в онлайні є і в когось нема якихось повідомлень вони одразу відправляються, разом з ключом перевіряяються каунт, таймштамп та хеші чатів, працює нормально на тестах до 100 проганяв, затримок чи якихоь синхро-гонок не було, думаю і більше буде без проблем. З сервера береться тількі якщо наприклад 10 переписувались 20 офлайн, потім 10 офлайн стали а 20 онлайн тому без сервера поки ніяк, але і групи поки не основне, є паблік групи и канали як в телеграм
Чи може юзер зайти на один акк з двох пристроїв?
Як лікується split brain? Якщо, наприклад, частина групи в одній мережі, а інша частина — в іншій.
Як визначається порядок меседжів, якщо два юзера пишуть меседжі одночасно, і в них розходження годинників на пристроях?
Як боротися з ботами, котрі додаються в усі групи й пишуть «куплю порно»?
Може але на іншому пристрої якщо зміниться ключ шифрування, всі данні будудь недоступні, одночасно тільки один пристрій може бути активним,
та навіть в налаштуванняж можно вімкнути — видалити все якщо вхід виконаний на іншому пристрої
Якщо ви маеєте на увазь коли немає інтернету, то для повідомлень split brain не є критичною проблемою. Кожне повідомлення має унікальний ID, автора, підпис і свій sequence/causal order. Якщо група розділилась на дві мережі — обидві частини продовжують спілкуватися локально. Після відновлення зв’язку вони синхрон через сервер
Якщо два користувачі й одночасно, між ними насправді немає об’єктивного «хто був перший» — це concurrent events. Після синхронізації вони отримують стабільний детермінований порядок, за sender/device ID.
Я так глибоко не тестував ще, якщо будуть якісь баги то буду виправляти вже по ходу.
Працює ШІ модерація. Через вбудований ШІ apple до сих пір не виіпускає в реліз, погоджує вже кілька раз переробляв угоди та повідомлення та погодження в додатку та на сайті
А як це можна перевірити, якщо пристрої можуть бути в різних мережах, котрі не мають зв’язку між собою?
Оце і є split brain. В юзера є старий пост. В юзера два пристрої. Один з них знаходиться в одній підмережі, інший — в іншій. Стається блекаут. Юзер редагує свій пост спочатку з ноутбука, котрий в мережі офіса. Але мережа офіса наразі без інтернета, бо блекаут. Потім юзер бере мобілку, бачить, що його пост не відредагувався, і знову редагує свій пост тепер з наявністю мобільного інтернету. Потім вмикають електрику, і підгрупа юзерів в локальній мережі починає синхронізуватися з юзерами в мобільній мережі. І виявляється, що один і той самий пост відредаговано автором двічі, з різним контентом. І на нього навіть повідповідали різні люди, залежно його контенту. Як це ресолвиться?
Хто визначає цей детермінований порядок? Ось на моєму девайсі зараз 20:00 а на вашому — 20:01. Це якщо ми не потрапили на якісь таймзони, переведення на літній час, чи іншу фігню. Я пишу вам 5 меседжів, ви — пишете мені 5 меседжів. Мої усі 5 будуть до ваших усіх 5 меседжів, бо в мене на одну секунду годинник відстає? Чи кожен девайс їх розставить по-своєму?
Себто, воно може саме видаляти меседжі юзерів, якщо вони обговорюють законодавство стосовно дитячого порно, або хімічний склад мухоморів? І цей ШІ біжить локально на кожному пристрої?
працює тільки останій вхід, на іншому пристрої блокується ключ шивруваня, усім контактам прийде повідомлення що прістрій змінено, та пропонуються подзвонит переконатись що це власник акаунту, і може прийняти новий прістрій як не скомпроментований, на старому пристрої буде все заблоковано та видалений ключ шифроування, якщо не змінити
Ні. 20:00 чи 20:01 тут взагалі не беруть участі у визначенні порядку — timestamp потрібен лише щоб показати час користувачу.
Кожен sender має свій послідовний sequence, а для злиття повідомлень використовується логічний порядок + стабільний tie-breaker (sender/message ID). Тому після синхронізації всі девайси отримають однаковий порядок, незалежно від timezone, літнього часу чи того, наскільки неправильно виставлений годинник.
Поки такого ще не було та і не має бути.
Ні звісно ШІ на сервері, перевіряється за 2 секунди автоматично і тільки в паблік группах та каналах, вони не шифруються взагалі і цілком на сервері зберігаються, модерацію для пабліків вимагає apple інакше не випустить в апп. стор.
Видаляти не може а просто перевіряє перед відправкою і не дозволяє публікацію, якщо щось підозріле. Тому і видаляти не потрібно нічого.
Хто блокує, коли пристрої не мають зв’язку один з одним — а центрального сервера також нема? Один пристрій в локальній мережі, інший — в іншій локальній мережі, або на мобільному інтернеті?
Від кого прийде — від першого пристрою, чи від другого? Сервер же у вас опціональний.
А як це виглядає в UI, коли великий чат був розділений на дві підмережі, і в кожній за цей час набрали по 100 меседжів? Як юзер побачить, які меседжі старі, а які — нові? Окрім того, ви певні, що тай брейкер з логічним порядком розставить меседжі в хронологічному порядку (відповідно таймстемпам) коли був спліт брейн протягом, наприклад, години — і за цю годину обидві половини набрали сотню меседжів?
Себто, у вас усе в паблік групах зав’язане на сервер? А як вони працюватимуть, коли немає інтернета?
Блокування відбувається новим входом, всім контактам в списку хто в онлайні прийде повідомлення, що користувач змінив пристрій і ключ шифрування змінився, і старі повідомлення якщо навіть писати зі старого пристрою навіть якщо дійдуть то не зможуть бути розшифровані більше ніким. Один акаунт не буде працювати нормально на двох пристроях — це мінус п2п. Якщо потрібно на кількох пристроях, на комп’ютері та на веб, цей додаток не підходить, тільки один пристрій, але плюс у більшій безпеці.
За групами в п2п я так глибоко не тестував ще, я написав десяток тестів спеціально для різних комбінацій, усі вони пройшли успішно. Спробуйте потестувати самі, якщо будуть такі баги, я виправлю, а зараз складно точно відповісти. Думаю великих таких груп і не буде в додатку, він більше для приємного спілкування і невеликих груп.
Паблік групи та канали, тільки через сервер, без інтернету працювати не будуть, нічого не відправиться, тільки те, що було вже завантажено і в кеші можна подивитися
Це не працюватиме, якщо старий та новий пристрої в підмережах, котрі не мають зв’язку одна з одною та з інтернетом. Якщо ви маєте на увазі вхід до групи.
Якщо мається на увазі вхід до серверу — тоді ваш месенджер зав’язаний на сервер.
Де список зберігається — на старому чи новому пристрої? Що, якщо ці списки відрізняються? Що, якщо один з пристроїв скомпроментований?
Нащо це мені?
Є Телеграм.
Це — Телеграм.
так, зав’язаний на сервер звичайно, я і не говорив, що це чисто п2п зараз це гібрид, п2п у пріоритеті, >90% трафіку п2п. У майбутньому коли буде достатньо користувачів в онлайні роль сервера буде розподілена на СуперНоди