Ang Buhay ng isang Mensahe

Ang ating digital na buhay ay labis na lubog sa mga kumplikadong teknolohiya na hindi natin ito pinapahalagahan, bigong maunawaan kung paano talaga sila gumagana o kung minsan ay walang kabuluhan sa kanilang pag-iral. Ang isang halimbawa ng tulad ng isang teknolohiya ay ang isa sa likod ng mga apps sa pagmemensahe na ginagamit nang literal ng bawat tao sa mundong ito gamit ang isang telepono.

Tingnan natin ang teknolohiyang may kapangyarihan Status.messenger. Sa mga nakaraang artikulo, tiningnan namin kung paano malawak na gumagana ang aming messenger at inihambing ito sa iba pang mga tanyag na messenger. Sa artikulong ito, nasusubaybayan namin ang "buhay ng isang mensahe" nang makipag-usap si Alice kay Bob gamit ang Status messenger. Sa konteksto ng pagpapagana ng paglalakbay ng mensahe na ito, inilalarawan namin nang detalyado ang iba't ibang mga bahagi ng pinagbabatayan na peer-to-peer (P2P) network, mga protocol sa privacy, cryptographic algorithm at iba pang mga primitibo ng pagmemensahe na ginamit sa arkitekto ang seguridad at mga pag-aari ng privacy ng Status messenger.

Sa isang client-server paradigm - tulad ng ginamit sa mga tanyag na messenger kasama ang Signal at Telegram - marami sa mga nasa itaas na aspeto ay medyo prangka/tapat dahil ang mga kliyente ay nakikipag-usap sa mga server na sa pangkalahatan ay pinagkakatiwalaan, available at alam kung paano rumuta ng mga mensahe sa iba pang mga kliyente. Ang Status messenger ay gawa para sa desentralisadong mga network ng P2P na walang konsepto ng mga server at kliyente.

Ang desentralisadong P2P na pagmemensahe ay naglalayong alisin ang mga centralized rent-seeking intermediaries, pag-alis ng mga solong punto ng pagkabigo at pagtaas ng pagtutol sa censorship.

Ang bawat node ay isang peer, kung minsan ay may iba't ibang mga kakayahan. Ang mensahe ay walang two hops - mula sa mapagkukunan ng kliyente hanggang sa server at pagkatapos sa patutunguhan na kliyente - tulad ng kaso sa mga arkitektura ng client-server. Sa halip ay tumatawid sila sa maraming peers at nagpapatuloy sa paglipat kahit na makarating sa kanilang inilaang tatanggap dahil ang mga peers ay hindi alam kung sino ang nilalayong tagatanggap.

Layunin naming magbigay ng privacy sa transport layer na kung saan makakamit ang mga node na may posibilidad na maikakaila sa pagkakaroon ng mga natanggap na mensahe na nilalayon para sa kanila. Ginagamit din namin ang cryptographic keys bilang account identifiers sa halip na mga karaniwang ginagamit na numero ng telepono para sa mga kadahilanan ng pinahusay na privacy at pseudonymity (tulad ng inilarawan sa artikulong ito). Ang mga aspeto na ito ay natural na nagdaragdag ng mas kumplikado sa arkitektura ng aming solusyon.

Sa madaling salita, ang paglalakbay ng isang mensahe mula kay Alice hanggang kay Bob ay nagsisimula kay Alice na alam ang Status chat key ni Bob at pagkatapos ay dagsain ang P2P network sa kanyang naka-encrypt na mensahe. Ito ay naipasa sa kabuuan ng mga peers at sa kalaunan ay nakarating kay Bob na siya lamang ang maaaring makapag-decrypt ng mensaheng ito mula kay Alice. Alam din nina Alice at Bob kung paano "pakinggan" ang mga mensahe ng bawat isa nang walang ibang tao sa network na manghimasok sa kanila maging ang mga inilaang tagatanggap ng mga mensahe.

Ito, sa madaling salita, ay ang pribadong buhay ng isang mensahe sa Status messenger.

Tinatanggap na, ang aming kasalukuyang pagpapatupad ay hindi ganap na P2P o ganap na desentralisado dahil ginagawang tiyak ang pagpapagaan ng praktikal na mga pagpapalagay, sa ngayon, ay makapaghatid ng isang produktong gumaganang messenger. Halimbawa, ang mga bahagi ng aming kasalukuyang pagpapatupad ay kahawig ng isang client-server relationship at ang Status ay nagpapatakbo ng lahat ng mga mensahe ng pag-hatid / pagtatago ng mga node ngayon. Gayunpaman, posible para sa sinuman ang magpatakbo ng anumang uri ng node sa aming arkitektura - ang mga pagtutukoy ay pampubliko, ang lahat ng code ay bukas na mapagkukunan at ang paglahok ng network ay walang pahintulot. Ang kulang ngayon ay ang kawalan ng mga insentibo upang magpatakbo ng mga peer node para sa relaying at (pansamantalang) pag-iimbak ng mga mensahe para sa iba at ito ay isang aktibong lugar ng pananaliksik sa Status.

Ang artikulong ito samakatuwid ay nakatuon sa paglalarawan ng aming naiisip na arkitektura, dako sa kung saan kami ay matatag na tutungo, sa halip na ang kasalukuyang pagpapatupad na patuloy na umuusbong patungo sa pangitain.

Inilalarawan namin ang architectural building blocks ng Status messenger at inilalarawan ang paglalakbay ng mensahe ni Alice kay Bob sa iba't ibang mga layer na ito. Sinusubukan ng artikulong ito na magbigay ng malalim na technical insights sa aming protocol stack sa pamamagitan ng pagsasama ng mga pangunahing aspeto mula sa buong iba't ibang mga pagtutukoy sa client, account, secure transport, payload, Waku usage at MVDS, habang hiniram din mula sa mga pagtutukoy ng Signal sa X3DH at Double Ratchet.

Protocol Stack

Ang ilustrasyon sa itaas ay nagpapakita ng limang layer ng protocol stack ng Status messenger na may kani-kanilang mga layunin sa gitna at ang mga partikular na teknolohiya na bumubuo ng layer na nasa kanan.

P2P Overlay

Ang bottommost layer ay isang overlay na P2P sa TCP / IP network. Ang layer na ito ay nagpapatupad ng isang pampubliko, walang pahintulot na peer-to-peer network, pinalakas ng mga protocol ng network ng devp2p.

Nagbibigay ang Devp2p ng mga protocol para sa pagtuklas ng node kung saan ginagamit ng mga peers ang TCP na nakabase sa RLPx na protocol ng transportasyon para makipag-usap sa isa't isa. Ang pangkat ng Vac ng Status ay kasalukuyang nagtatrabaho sa isang libp2p replacement para sa devp2p na susuportahan ang maraming mga transportasyon, mas mahusay na negosasyon sa protocol at traversal ng NAT sa iba pang mga pakinabang.

Mga Uri ng Node: Tinukoy namin ang isang node sa pamamagitan ng hanay ng mga kakayahan nito. Ang mga kakayahan na ito ay: magpadala ng mga mensahe, makatanggap ng mga mensahe, mag-relay ng mga mensahe, mag-imbak ng mga makasaysayang mensahe at mag-bootstrap ng ibang mga node.

Batay sa mga kakayahan na ito, tinukoy namin ang mga sumusunod na uri ng mga node:

1. Light node: ito ay may kakayahang magpadala at tumanggap lamang. Ang mga ito ay karaniwang mga mobile clients na may Status messenger na resource-constrained at sa gayon ay maaari lamang magpadala at makatanggap ng kanilang sariling mga mensahe.

2. Full node: lahat ng mga kakayahang magpadala / makatanggap / maghatid / mag-imbak / bootstrap. Ang mga node na ito ay nagpapadala, tumanggap at nag-hahatid ng mga mensahe para sa iba pang mga node sa network. Maaari silang pansamantalang mag-imbak ng mga mensahe na nilalayong para sa iba pang mga node na kasalukuyang offline. Maaari rin tulungan ang mga bootstrap node sa pamamagitan ng pagtulong sa kanila na matuklasan at kumonekta sa iba pang mga node sa network.

3. Bootstrap node: may kakayahan lamang sa mga bootstrap node. Ang mga node ay makakatulong lamang sa mga bootstrap node sa pamamagitan ng pagtulong sa kanila na matuklasan at kumonekta sa iba pang mga node sa network.

Tandaan na ang mga kakayahang ito ay mai-configure at maaaring magbago sa paglipas ng panahon batay sa kapasidad o konteksto ng node. Halimbawa ang isang mobile client ay maaaring kumilos tulad ng isang Light node sa mga cellular network ngunit magbago sa pagiging isang Full node sa Wifi.

Node Discovery: Kailangang matuklasan ng isang node ng Status ang iba pang mga peers o magkaroon ng isang listahan ng mga peers na kumonekta. Sinusuportahan ng Status ang isang kumbinasyon ng Discovery v5 at Rendezvous protocol na may isang pagpipilian upang magamit din ang mga static node.

Ang Discovery v5 ay gumagamit ng mga bootstrap node upang matuklasan ang iba pang mga peers. Ito ay isang mekanismo na natuklasan batay sa Kademlia at maaaring kumonsumo ng isang makabuluhang (at least sa mobile) na halaga ng trapiko sa network para mapatakbo. (Tingnan ang artikulong ito para sa higit pang mga detalye.)

Ang Rendezvous protocol ay isang mas simple at mas mobile-friendly na mekanismo ng pagtuklas ng peer. Ito ay isang mekanismo ng pagtuklas ng kahilingan sa pagtugon at gumagamit ng Ethereum Node Records (ENR) upang maiulat ang mga natuklasang mga peers.

Bilang kahalili, ang isang kliyente ay maaaring umasa ng eksklusibo sa isang listahan ng mga static peers. Habang ito ay maaaring ang pinaka mahusay na paraan dahil wala talagang natuklasan, ang disadvantage ay ang mga peers na ito ay maaaring maging offline o hindi available, at nang walang mekanismo ng pagtuklas ng peer, hindi posible na makahanap ng bago.

Patakaran sa Pagkapribado

 

Ang layer ng transport privacy ay nagbibigay ng pagruruta, proteksyon ng metadata, algorithm na batay sa paksa at algorithm ng pag-encrypt upang suportahan ang asynchronous chat. Ito ay ipinatupad ni Waku, na siyang kahalili namin sa Whisper, tulad ng ipinaliwanag sa artikulong ito.

Ginagamit ni Waku ang konsepto ng mga paksa upang mahati ang mga mensahe nito. Ang mga paksa ay mga string na nagmula gamit ang mga tinukoy na algorithm at ginagamit sa Waku "envelopes", kung saan ang mga envelopes ay sumasama sa mga naka-encrypt na mensahe kasama ang paksang ito at time-to-live (TTL).

Dahil sa isang P2P network, ang lahat ng mga mensahe ay nai-broadcast sa lahat ng mga node, ang mga node ay dapat "makinig" sa ilang mga paksa ng kanilang interes. Habang ang teorya ay maaaring makipag-usap ang lahat gamit ang isang solong paksa, iyon ay magiging lubhang hindi epektibo dahil ang mga node ay kailangang subukang i-decrypt ang bawat mensahe - dahil kahit sino ay maaaring makatanggap ng mga Waku envelopes, umaasa ito sa kakayahang mag-decrypt ng mga mensahe upang magpasya ang tamang tatanggap. Ang iba pang dulo ng spectrum ay gagamit ng isang natatanging paksa para sa bawat pag-uusap ngunit hindi ito nagbibigay ng kinakailangang privacy dahil mas madali itong matukoy kung at kung kailan may aktibong pag-uusap ang dalawang partido.

Ang Status messenger ay tumatama sa isang balanse upang mabigyan ang nais na antas ng privacy ng transportasyon sa pamamagitan ng paggamit ng tatlong uri ng mga paksa:

1. Paksa ng contact code: Dahil sa ang Status messenger ay gumagamit ng mga cryptographic keys bilang mga identifier ng account at walang central server sa P2P network, ang mga node ay nangangailangan ng isang paraan upang i-bootstrap ang materyal na cryptographic na kinakailangan upang magsimula ng isang pag-uusap sa iba pang mga node. Pinapabilis ng paksa ng contact code ang bootstrapping na ito.

Ang paksa ng contact code ay tinukoy bilang "0x" + publicKey + "-contact-code", kung saan ang publicKey ay isang pampublikong chat o key ng pagkakakilanlan. Ang pampublikong chat key ay nagmula sa seed phrase ng BIP-39 na gumagamit sa m / 43 '/ 60 '/ 1581' / 0/0 na landas tulad ng bawat EIP-1581. Ang bawat node ay nag-broadcast ng isang paunang cryptographic bundle (inilarawan sa susunod na seksyon) sa paksang ito.

Kaya kung interesado si Alice na makipag-usap kay Bob, nakikinig siya sa paksang ito kasama ang public chat key ni Bob (sa equation sa itaas) na inaakala nating alam na niya. Kapag ang nai-broadcast na mensahe ni Bob (ang mga node ay patuloy na nai-publish ito ng pana-panahon) sa paksang ito ay umabot kay Alice, mayroon siyang inisyal na cryptographic bundle ni Bob na kinakailangan upang magsimula ng isang pakikipag-chat sa kanya.

2. Napahiwalay na paksa: Si Alice ay kailangang makipag-usap ngayon kay Bob upang makabuo ng mga specific cryptographic keys na gagamitin upang i-encrypt ang mga mensahe sa hinaharap sa pagitan nila. Ang partitioned topic ay ginagamit para sa komunikasyon na ito.

Ang partitioned topic ay tinukoy bilang "contract-discovery-" + mod (publicKey, 5000), kung saan nagmula ito mula sa public chat key ng node sa 5000 na mga partisyon. Ang bilang ng mga partisyon ay nakakaapekto sa trade-off sa pagitan ng efficiency at privacy - mas maraming mga partisyon ang nagbibigay ng mas kaunting privacy na may mas higit na kahusayan, at gayon din naman. Ang lahat ng mga node ay patuloy na nakikinig sa kani-kanilang pinaghiwalay na mga paksa upang suriin kung may iba pang mga node na interesado na makipag-usap sa kanila.

Sinimulan ni Alice ang pakikipag-usap kay Bob sa kanyang pinaghiwalay na paksa na ginamit hanggang sa gumawa sina Alice at Bob ng isang nakabahaging symmetric key sa pagitan nila.

3. Napag-usapan na paksa: Kapag ang isang symmetric cryptographic key ay nabuo sa pagitan nina Alice at Bob, dapat nilang simulan ang pakikipag-usap gamit ang isang paksang tukoy sa 1: 1 chat na ito. Ang napagkasunduang paksa ay ginagamit para sa komunikasyon na ito pagkatapos.

Ang napagkasunduang paksa ay tinukoy bilang "0x" + unang apat na byte ng keccak256 (symmetricKey) + "-negotiated", kung saan ang symmetricKey ay ang symmetric cryptographic key na nabuo sa pagitan nina Alice at Bob gamit ang isang pinalawig na bersyon ng Diffie-Hellman algorithm.

Kaya, para mai-summarize, ang mga paksang ginamit sa daloy ng mensahe sa pagitan nina Alice at Bob ay ang mga sumusunod:

1. Nakikinig si Alice sa paksa ng contact code ni Bob upang makuha ang kanyang cryptographic bundle.
2. Nagpadala si Alice ng isang mensahe sa paksang nahati ni Bob. Sina Alice at Bob ay nakabuo ng isang ibinahaging symmetric key gamit ang isang pinahabang bersyon ng Diffie-Hellman algorithm (tingnan ang susunod na seksyon) gamit ang mga partisyon na nahati.
3. Sinimulan nina Alice at Bob ang paggamit ng napagkasunduang paksa na nagmula sa ibinahaging symmetric key.

Kung hindi natatanggap ni Alice ang cryptographic bundle ni Bob habang nakikinig sa paksa ng contact code ni Bob (sa hakbang na 1 sa itaas), nagpapadala siya ng isang naka-encrypt na mensahe gamit ang kanyang cryptographic bundle kay Bob sa kanyang pinaghiwalay na paksa, kung saan nakikipag-ugnayan si Bob sa protocol mula sa hakbang 2 pataas.

Para sa mga pampublikong group chats, ang paksa ay ang unang apat na bytes ng hash ng channel name. Ang mga pribadong group chat ay walang nakatuon na paksa - ang mga mensahe ay ipinadala 1: 1 sa maraming recipients gamit ang contact code, partitioned at napagkasunduang mga paksa na katulad ng 1: 1 mga pribadong mensahe.

Nagdaragdag din si Waku ng isang layer ng encryption sa pamamagitan ng pag-encrypt ng mga mensahe na may identifiers key ng tatanggap (sa kaso ng 1: 1 na mga mensahe o pribadong chat ng grupo) o mayroong symmetric key sa kaso ng mga pampublikong mensahe.

Secure Transport

Ang layer na ito ay may pananagutan sa pagbibigay ng garantiya ng cryptographic ng pagiging konpidensiyal, integridad, pagiging tunay at pasulong na lihim. Ito ay transport-agnostic at gumagana sa mga hindi nakakabit na mga network. Hindi nangangailangan ng parehong mga pakikipag-ugnay na mga nilalang na maging online sa parehong oras. Ito ay batay sa mga pagtutukoy ng X3DH at Double Ratchet mula sa Signal, na may ilang mga pagbagay upang gumana sa isang P2P environment.

X3DH: Ang ibig sabihin ng X3DH ay Extended Triple Diffie-Hellman, ay ginagamit upang magtatag ng isang nakabahaging secret key sa pagitan ng dalawang partido na kapwa nagpapatunay batay sa kanilang mga public keys. Nagbibigay ito ng pasulong na lihim at maaaring mangyaring ka walang ng kakayahan sa asynchronous settings.

Ginagamit ng X3DH ang konsepto ng mga identity keys, mga ephemeral keys at signed prekeys sa panahon ng protocol run na nagtatapos kay Alice (A) at Bob (B) na magkasama na bumubuo ng isang nakabahaging symmetric key. Ang tatlong Diffie-Hellman na kasangkot ay:

1. DH-1 = DH(IK-A, SPK-B)

2. DH-2 = DH(EK-A, IK-B) and

3. DH-3 = DH(EK-A, SPK-B)

at ang pangwakas na ibinahaging symmetric key (SK) ay kinakalkula bilang:

SK = KDF(DH-1 || DH-2 || DH-3)

Na kung saan, ang IK = Identity Key, EK = Ephemeral Key, SPK = Signed PreKey, DH = Diffie-Hellman at KDF = Key Derivation Function.

Ang X3DH protocol na tinukoy ng Signal ay nagsasangkot ng tatlong partido: Alice, Bob at isang server. Ngunit sa aming P2P setting, kung saan walang server, ang X3DH cryptographic bundle na naglalaman ng IK (public chat key sa aming kaso), ang mga lagda ng SPK at PreKey ay ipinagpapalit sa paksa ng contact code ng Waku  tulad ng inilarawan kanina.

Ang hindi umaasa sa mga server para ipamahagi ang mga bundle ng X3DH ay ginagawang mas mahirap para sa isang panlabas na tagamasid upang mangalap ng metadata at sa gayon ay nagpapabuti sa privacy. Dagdag pa rito, ang aming pagpapatupad ay hindi gumagamit ng One-time PreKeys (OPK tulad ng inilarawan sa Signal spec) dahil hindi namin masiguro na ginagamit lamang sila nang isang beses nang walang isang interactive na protocol o pag-iimbak ng mga ito sa mga server na wala sa aming setting ng P2P. Sa halip ay paikutin namin ang mga keys nang mas madalas.

Ang mga phase ng X3DH protocol ay pinapatakbo gamit ang pinaghiwalay na paksa ng Waku tulad ng inilarawan kanina upang makabuo ng isang nakabahaging symmetric key sa pagitan nina Alice at Bob. Ang nakabahaging symmetric key ay ginamit upang maipahiwatig ang pagbuo ng mga encryption keys para sa mga mensahe sa hinaharap gamit ang Double Ratchet algorithm at pati na rin sa pagkuha ng napagkasunduang paksa ng Waku na ginamit pagkatapos.

Double Ratchet: Ang Double Ratchet algorithm ay ginagamit nina Alice at Bob upang makipagpalitan ng mga naka-encrypt na mensahe batay sa ibinahaging secret key (na nabuo ng X3DH) na nagbibigay ng end-to-end encryption (E2EE) at perfect forward secrecy (PFS).

Ang mga bagong keys ay nagmula para sa bawat mensahe upang ang mga naunang mga keys ay hindi makakalkula mula sa mga susunod na (forward secrecy). Naglalaman din ang mga mensahe ng mga bagong Diffie-Hellman public keys na halo-halo sa derived keys upang ang mga keys sa bandang huli ay hindi makakalkula mula sa mga nauna. Pinoprotektahan ng mga pamamaraan na ito ang mga naka-encrypt na mensahe mula sa nakaraan o sa hinaharap kung ang mga kasalukuyang key ay nakompromiso.

Ginagamit ng Double Ratchet algorithm ang konsepto ng KDF chains. Sa isang sesyon sa pagitan nina Alice at Bob, ang bawat nilalang ay nagiimbak ng KDF key para sa tatlong chain: isang root chain, isang sending chain at receiving chain. Ang sending chain ni Alice ay tumutugma sa receiving chain ni Bob, at vice versa.

Ang mga lihim ng output ng Diffie-Hellman ay naging mga input sa root chain at ang mga output keys mula sa root chain ay naging mga bagong KDF keys para sa pagpapadala at pagtanggap ng mga chains. Ito ay tinawag na Diffie-Hellman ratchet. Ang pagpapadala at pagtanggap ng mga chains ng maaga habang ang bawat mensahe ay ipinadala at natanggap at ang kanilang mga output keys ay ginagamit upang i-encrypt at i-decrypt ang mga mensahe. Ito ay tinatawag na Symmetric-key ratchet. Ang kumbinasyon ng Diffie-Hellman at Symmetric-key ratchets ay kilala bilang Double Ratchet algorithm na ipinapakita sa itaas na paglalarawan mula sa detalye ng Signal. (Panoorin ang video na ito para sa isang detalyadong paliwanag ng protocol na ito.)

Data Sync

Ang layer na ito ay nagpapatupad ng Minimum Viable Data Synchronization (MVDS) na protocol na nagsisiguro sa pagkakapareho ng data na may maaasahang pagmemensahe sa pagitan ng mga peers sa isang hindi mapagkakatiwalaang network ng P2P kung saan ang mga peers ay maaaring unreachable o unresponsive.

Ang mga payload sa layer na ito ay binubuo ng mga records na may apat na uri: Offers, Requests, Messages at Acks. Kapag may mensahe si Alice na ipadala kay Bob, nagpapadala siya ng isang Offer. Kung tumugon si Bob na may Request, ipinadadala pa niya kay Bob ang Mensahe na kung saan tumugon siya pabalik sa isang Ack. Ang isang maximum ng isang payload ay dapat ipadala sa bawat panahon. Ang mga mensahe ay maaaring maipadala alinman sa Interactive o Batch mode.

Ang diagram sa itaas ay naglalarawan ng daloy ng payload sa interactive mode. Magpadala ng mga bilang at mga oras ay sinusubaybayan para sa retransmission ng mga payload.

Data at Payload

Ang layer na ito ay responsable para sa pagpapatupad ng end user na pag-andar ng 1: private messages,  private group chat at public chat. Ipinapakita sa ibaba ang magkakaibang bahagi ng isang mensahe tulad ng inilarawan sa payload specification.

Ang uri ng mensahe (1:1 private group, public group) ay nagtutukoy kung paano i-encrypt ang isang partikular na mensahe at kung ano ang kailangang isama sa metadata. Tinutukoy ng uri ng nilalaman ang aktwal na payload ng mensahe. Halimbawa, ang nilalaman ay maaaring simpleng teksto, sticker, emoji, imahe o isang audio message. Ang lahat ng mga payload ay naka-encode gamit ang Protobuf.

Paglalakbay ng isang Mensahe

Ngayon na inilarawan namin ang lahat ng mga layer ng aming protocol stack at pati na rin sinubaybayan ang mensahe ni Alice sa pamamagitan ng mga bahagi nito, ating ibuod ng buong pagkakasunod-sunod ng mga hakbang para kay Alice na makipag-usap kay Bob gamit ang Status messenger. Ipapalagay natin na pareho sina Alice at Bob ay may naka-install na Status messenger app sa kani-kanilang mga mobile device na kumakatawan sa mga Status Light node.

1. Peer Discovery: Ang Status messenger apps sa mga mobile device ni Alice at Bob ay natuklasan ang mga Status peers sa P2P network na mga Full nodes gamit ang mga Bootstrap node. Ang Mga Full node na ito ay responsable para i-relay ang mga mensahe ni Alice kay Bob o kahit pansamantalang itago ang mga ito kung hindi online si Bob.

2. Contact Discovery: Ang unang hakbang ay upang matuklasan ni Alice si Bob sa Status messenger. Maaari itong mangyari sa maraming paraan tulad ng pag-scan sa QR code ng Status ni Bob, pagdaragdag ng chat key ni Bob sa labas ng banda, paghahanap ng pangalan ng ENS ni Bob o pagdaragdag ng chat key ni Bob sa pamamagitan ng isang nakabahaging pampublikong channel.

3. Contact Verification: Maaaring opsyonal na i-verify ni Alice ang public keys ni Bob na sa palagay niya ay si Bob nga talaga sa pamamagitan ng pag-check sa kaukulang three-word pseudonym, ang pangalan ng ENS ni Bob, o paggawa ng ilang pag-verify ng banda.

4. Initial Key Exchange: Nakuha ni Alice ang bundle na X3DH ni Bob sa pamamagitan ng pakikinig sa paksa ng contact code ni Bob na inilarawan nang mas maaga sa seksyon sa Waku.

5. Secure Channel Creation: Ang X3DH at Double Ratchet na mga protokol ay tumatakbo sa partisyon ng Waku at napag-usapan ang mga paksa ayon sa pagkakabanggit upang makatulong na lumikha ng isang ligtas na end-to-end na naka-encrypt na channel sa pagitan nina Alice at Bob.

6. Message Transfer: Ang pagkakaroon ng isang ligtas na channel, maaari na ngayong magpadala si Alice ng 1: 1 pribadong mga mensahe kay Bob. Ang mga naka-encrypt na mensahe ay nakabalot sa Waku envelope na may napag-usapang paksa at isang TTL (kasalukuyang 15 segundo). Ang mga mensahe ay kumakalat sa mga Status peer nodes sa loob ng kaunting panahon, hanggang sa mag-expire ang kanilang TTL, at pagkatapos ay mai-save sa Status Full Nodes ng hanggang sa 30 araw. Kung si Bob ay online sa oras na iyon, matatanggap niya ang mensahe ni Alice. Kung hindi, kakailanganin niyang makuha ito mula sa Full nodes sa ibang pagkakataon.

7. Message Notification: Sa mga notification na inilabas kamakailan sa bersyon 1.4 sa Android, makakatanggap din si Bob ng isang notification kung nasa Android siya. Ang mga notification sa iOS ay isinasagawa pa.

8. Message Retention: Kapag natanggap ng app ni Bob ang mensahe, naiimbak ito sa database ng chat ng app na naka-encrypt na may key na nagmula sa seed phrase ng BIP-39 ng gumagamit sa m / 43 '/ 60' / 1581 '/ 1/0 path bilang EIP-1581.

Buod

Inilarawan namin ang limang mga layer ng Status protocol stack at inilarawan ang paglalakbay ng mensahe ni Alice kay Bob sa pamamagitan ng iba't ibang mga layer na ito.

Ang dalawang mga bottommost layer na nagpapatupad ng overlay ng P2P na may iba't ibang mga uri ng node at transport privacy sa mga paksa ng Waku na makabuluhang lumihis mula sa karaniwang mga arkitektura ng client-server paradigm na ginamit ng iba pang mga messenger. Ang mga protokol na ginamit sa layer ng Secure Transport na nagbibigay ng mga garantiyang cryptographic ay inangkop para sa aming desentralisadong P2P network. Ang dalawang pinakamataas na layer na nagpapatupad ng pagsabay sa data at namamahala ng mga kargamento para sa tatlong magkakaibang mga mode sa chat ay natatangi sa stack ng protocol ng messenger ng Status.

Binibigyan ka ng artikulong ito ng mga pangunahing pang-teknikal na pananaw sa paglalakbay ng mensahe ni Alice kay Bob habang nagna-navigate ito sa mga layer ng protokol na ito at umakyat sa maraming mga node na may isang solong layunin sa buhay nito - privacy.

Nilalayon ng status messenger na maging ultimate na privacy-preserving messenger na binuo gamit ang desentralisadong P2P na teknolohiya.

(Salamat kina Andrea Piana, Corey Petty, Jonathan Zerah at Tobias Heldt para sa pagsusuri ng mga draft ng artikulong ito at pagbibigay ng kapaki-pakinabang na puna. Salamat kay Alex Howell para sa kamangha-manghang ilustrasyon. At, salamat sa mga may-akda ng pagtutukoy para sa pagbibigay ng pundasyong materyal para sa artikulong ito. )