У твітары са мной не вельмі актыўна гэта абмяркоўваюць, таму я да вас

Я загнаўся думкай напісаць мэсэнджэр, які пра вас ніколі нічога нікому не распавядзе.

І ўжо маю пэўныя поспехі. Шмат што трэба распавесці, таму гэта будзе трэд.

Я буду вельмі рады адваротнай сувязі на гэтую тэму, бо, на жаль, веданне матэматыкі не дацягвае да глыбокага разумення крыптаграфіі, аднак калі прыняць за аксіому некаторыя рэчы, якія зробленыя да мяне, мне здаецца я магу даць рады з такой задачай.

Пачнём. Асноўная ідэя - не збіраць, не захоўваць, не паказваць, як мага больш інфармацыі, якая можа прывесці да разумення, які чалавек, каму пісаў, калі пісаў. Нават калі база даных уцячэ. Аніякіх глабальных нікнэймаў, аніякіх пароляў, рэгістрацыя з мінімум пытанняў (у ідэале толькі адна кнопка)

Каб нават сервер ніколі не ведаў цела паведамлення, яе сэнсоўную частку, яго задача, проста зрабіць тунэль камунікацыі паміж двума або больш людзьмі

І я ўжо маю некаторыя поспехі ў гэтым накірунку.

Па першае, крыху змененая імплементацыя адносна свежага RFC 9420 - The Messaging Layer Security (MLS) Protocol

ён вырашае праблему шыфравання паведамленняў, дзе ўдзельнікаў больш за два. Дазваляючы дзве рэчы

Не толькі паведамленні 1:1, але групавыя чаты, а таксама чаты, да якіх вы маеце доступ з любой вашай прылады

Па другое - аніякіх запытаў нумара тэлефона ці сканавання адраснай кнігі (гэтым нават сігнал грашыць), або емэілаў

Гэта канешне мае мінусы, кшталту, вы не можаце знайсці чалавека, які ўжо зарэгістраваны ў мэсэнджэры проста таму, што вы ведаеце яго нумар тэлефону.

Але тут нічога не паробіш, прынцыпы дыктуюць правілы

Аднак, знайсці адно адное прапануецца QR кадамі.

Напрыклад - вось невялічкае відэа, яно паказвае як адзін дэвайс далучаецца да другога ў адзін аккаўнт, але шэрынг кантактаў прынцыпова не адрозніваецца
Далей - спам акаўнты. З аднаго боку, калі няма мажлівасці знайсці рандомнага карыстальніка, то здавалвся б, прычым тут спам акаўнты. Аднак яны могуць ствараць нагрузку на сервер. Але ў нас няма нумараў тэлефонаў і емэілаў, але нам трэба абмежаваць рэгістрацыю для тых, хто гэтым карыстацца будзе не па накіраванню. Адказ просты - PoW. Пры першым падключэнні да сервера, трэба знайсці чысло, якое пры хэшаванні дасць канкрэтны вынік.

Шукаецца такое чысло пэўны час, правяраецца рашэнне імгненна, а калі нагрузка вялікая, або шмат рэгістрацый адбываецца з аднаго адраса, заўжды можна падняць складанасць гэтай задачы дынамічна

Вось прыклад.

А як схаваць факт, што акаўнт "юзер1" меў кантакт з акаўнтам "юзер2". Думаў над гэтым пэўны час і прыйшоў да выніку, што найлепшае выйсце наступнае.

Калі ты паказваеш куар код будучаму суразмоўцы, твая прылада генерыруе рандомны айдзі - топік, праз які ты будзеш чакаць паведамленне-запыт на дадаванне ў кантакты. Ты кажаш серверу - хачу атрымліваць паведамленні, якія пазначаны вось гэтым топікам.

Пра гэты факт сервер нічога не запісвае, проста трымае ў памяці, што ўсё пазначанае гэтым топікам трэба пераслаць па гэтаму канэкшану. То бок ёсць, вядома, факт перадачы на сервер, што юзер1 падпісаўся на топік А, а юзер 2 шле на топік А паведамленне, але першая палова не захоўваецца ўвогуле, а пра другую палову нідзе не пазначаецца, што паведамленне было прыслана юзерам 2
Пры гэтым, усе паведамленні, тэхнічныя і сістэмныя, або фактычныя паведамленні што вы напісалі свайму сябру заўжды зашыфраваныя такім чынам, што і сервер не можа іх прачытаць. Толькі людзі, якім гэтае паведамленне адрасавана. Гэтая частка апісана цалкам у загаданым вышэй RFC, а літаральна ўчора мая імплементацыя навучылася вызначаць агульны сакрэт групы, не перадаваючы гэты сакрэт яўна.

І вось цяпер у мяне пытанне да вас, спадарства. Я вар'ят ці мае сэнс працягваць?

Сарцы з'явяцца як толькі я давяду гэтую справу да чагосьці, чым можна карыстацца. На гэты момант я мяркую, што гэта мае сэнс рабіць сэлфхостэд рашэннем для закрытых груп, але ёсць кейсы, калі глабальны сэрвіс толькі б дапамог схаваць факт сувязі паміж двума людзьмі. Але баюся не даць рады (сродкамі або рэсурсамі) трымаць глабальны сэрвіс.

Такія пірагі :)

У мяне адразу адно пытанне. Чым гэта плануецца быць лепей ды адрозніваца ад, скажам, XMPP + OMEMO + Jingle/XEP-0166 ? Бо самаробная імплементацыя крыптаграфіі заўжды таіць сабе *БАГАТА* пастак, а яшчэ адзін новы пратакол/тып/кліент (?) месанджэру з ідэей сэлф-хостынгу федаратыўных сістэм, калі

@afox.me xmpp па змаўчанні мае метадату, якая расказвае, што ты кантактаваў з васей пупкіным у 19:13 учора, напрыклад

Адзінае што я не вельмі дасканала знаёмы з усімі экстэншамі, але калі вы скажаце мне адваротнае, то добра

А яшчэ, чаму тэлеграм лепей за пералічанае? Здавалася б нічым, але карыстаюцца ім нашмат больш за xmpp, хіба не?

Я намагаюся павязаць бяспеку са зручным экспірыенсам. Атрымаецца ці, час пакажа.

@afox.me так, і я разумею што крыптаграфія гэта складана. Таму і спасылаюся на RFC. Тым больш што згаданы RFC адносна нядаўні, наколькі хапае майго мозгу - ён прам геніальна просты (у сэнсе ядра, ідэі)

Таму для кліентскай рэалізацыі я выкарыстоўваю голэнг, дзе ўсе патрэбныя прымітывы крыптаграфіі ўжо ёсць у стандартнай бібліятэцы, што паніжае шанец на крытычную памылку

@afox.me
Ну а яшчэ, самае як на мяне прыгожае - Ты можаш аднесці дамп базы каму заўгодна, але акром колькасці паведамаленняў, што прайшло праз сістэму, адтуль нічога не атрымаць

@GomZik дарэчы, ёсць яшчэ такі не вельмі знакаміты праект https://code.briarproject.org/briar/briar
Я ім не карыстаўся, але выглядае цікава, як менш па апісанню. З мінусаў - здаецца, толькі пад Андроід.

Там увогуле няма цэнтральнага сервера і калі камунікацыя праз інтэрнэт (ёсць яшчэ магчымасць працаваць праз wifi і bluetooth), то сувязь ідзе праз тор.
Магчыма, можна ўзяць адтуль пару ідэй.

briar / briar · GitLab

Secure messaging, anywhere.

GitLab
@GomZik Канешне варта рабіць праект, калі важна тое, чаму навучышся па дарозе. Я таксама сваё раблю для эстэтычнага задавальнення і практыкі новых тэхналогій. Змагацца з тэлеграмамі наўрад атрымаецца – сеткавы эфект непераадольны. Я на Сігнал толькі найбліжэйшых сяброў угаварыў.
Можна натхнення пашукаць яшчэ ў Delta Chat. Яны таксама стараюцца зменшыць метададзеныя, а сэлф-хостэд серверы выкарыстоўваюць толькі як перадатчык паведамленняў са скразным шыфраваннем. UI - форкнуты сігнал.
@safonas а дэльта чат гэта хіба... Не зашыфраваны емэіл?
@GomZik там транспартны пратакол ад мэйла, так. Але дастаўка імгненная, dovecot дае рады лёгка. Адрасы паштовыя аўтаматычна генеруюцца толькі для маршрутызацыі, асноўная тоеснасць (user identity) – крыптаграфічная, захоўваецца на прыладзе. Такім чынам можна змяняць сервер без рэгістрацыі. Паведамленні пасля дастаўкі выдаляюцца Так што з пункту гледжання карыстальніка, гэта ўсё ж чат 🙂
@safonas не падобна што яны падтрымліваюць групавыя чаты. То ж гэта проста GPG паверх емеіла ў іншай абалонцы, хіба не?
@GomZik я найбольшы групавы чат бачыў на 130 чалавек, deltachat support называецца. Бот там выдаляе неактыўных удзельнікаў бадай з-за таго, што большы лік ўплывае-такі на сервер, г. зн. ёсць нейкія невырашаныя праблемы з пратаколам. GPG паверх эмэйла - згодны, наконт "проста" - не зусім 😁

@safonas ды проста :)

Мяркую таму што каб зрабіць выгляд групы, табе трэба даслаць Н паведамленняў на кожнае лагічнае паведамленне. Не скейліцца. MLS (які ў рфц), прапануе спосаб дамовіцца пра агульны сакрэт і як яго змяняць пры тых ці іншых умовах, таму яно для мяне выглядае больш масштабуемым і цікавым :)

@xzfantom так, я пра яго даўно ведаю, але гэта не зусім тое, як мне здаецца. Яно нават не блізка дае нейкі экспірыенс штодзённага мэсенджэра. Ды і быццам бы пераследуе іншыя мэты.

Я недзе ўжо казаў - p2p у гэта нават магчыма мінус у нашым выпадку, як бы я не любіў п2п тэхналогіі

@GomZik ну я не кажу, што брось дурное і карыстайся ім) але можна разглядзець, напрыклад, сервер як onion сервіс

@xzfantom ну ... Я проста мяркую што каб гэта было юзабельна, яно мусіць быць даступна з клірнэта

А адвансэд юзеры самі пюмогуць завярнуць усё ў оніон, гэта таксама варыянт

Маю на ўвазе каб сокет адкрыты быў менавіта ў оніон сетцы