Semua utusan yang ada memiliki pro dan kontra, tetapi masing-masing dari mereka menarik selimut ke sisinya karena ketidakcocokan dengan yang lain - dan pengguna menderita karenanya.
XMPP bisa menjadi standar tunggal, tetapi, tidak seperti E-Mail, muncul relatif terlambat dan tidak berhasil mendapatkan audiensi yang cukup sehingga perusahaan tidak bisa menolaknya. Setelah semua, mereka dengan cepat menyadari bahwa tanpa mempertahankan audiens dalam ekosistem mereka sendiri, tidak ada banyak yang bisa didapat. Dan di samping itu, saya harus akui, XMPP memiliki kekurangan yang cukup karena banyaknya ekstensi, yang banyak di antaranya, meskipun penting, tetap dalam status eksperimental, dan beberapa sama-sama saling menduplikasi.
Setelah tinggal di "dunia luar biasa baru" dari selusin kurir instan di smartphone, dan setelah merasakan semua kekurangan dari keadaan ini, kami akhirnya siap untuk sesuatu yang baru.
Dan ya, kami membutuhkan standar baru!
Future Messenger yang sangat baik memenuhi persyaratan berikut: memastikan keandalan, keamanan, melalui pengembangan dan desentralisasi terbuka, portabilitas (lintas platform), multi-protokol (kemampuan untuk terhubung ke jaringan komunikasi lain) dan ramah pengguna.
Mengapa semuanya begitu buruk?
Tapi pertama-tama, mari kita cari tahu mengapa semua orang tidak beralih ke siapa pun yang sudah populer == messenger terpusat, apakah itu WhatsApp bersyarat atau, katakanlah, Telegram, yang memiliki pemirsa yang cukup besar di Rusia.
Tentu saja, konstruksi terpusat memungkinkan pemilik untuk mendapatkan lebih banyak uang, dan dengan demikian tidak hanya membayar untuk pengembangan, tetapi juga menginvestasikan uang yang signifikan dalam iklan dan bahkan pemuliaan fungsi yang hampir tidak ada , seperti keamanan layanan, misalnya. Namun, seiring dengan ini, pemilik dapat tiba-tiba memutuskan untuk menutup layanan, traktor untuk memindahkan kawat dari pusat data, atau hanya seorang kurir yang dapat dilarang di wilayah negara tertentu. Tidak harus karena alasan politik, mungkin, dan atas permintaan pemegang hak cipta bersyarat, mungkin ada banyak alasan. Nah, jika, meskipun ukuran pasarnya tidak signifikan, Telegram terus bekerja dengan berbagai keberhasilan di Rusia, tetapi ini karena akun pribadi pemiliknya, dan dalam hal pemblokiran WhatsApp yang sama, Facebook tidak mungkin berinvestasi besar-besaran untuk mem-bypass kunci.
Sulit untuk berbicara segera untuk semua utusan terpusat, mengumpulkan di bawah satu sisir. Ada kejahatan absolut dengan klien, server, dan protokol berpemilik yang bahkan hanya bekerja pada beberapa platform paling populer dan tidak memiliki enkripsi apa pun. Ada juga kebaikan relatif, misalnya, Pengirim sinyal, yang sepenuhnya terbuka, tetapi server tidak mendukung mode gabungan, itulah sebabnya semua orang bergantung pada server pusat dengan semua konsekuensi berikutnya. Di sini, klasifikasi harus dilakukan sesuai dengan prinsip yang berbeda, tetapi ini di luar cakupan artikel ini.
Nah, mengapa tidak beralih ke sesuatu yang federal. Misalnya, Matriks yang sama. Saya tidak akan berbicara tentang HTTP Long Polling, ketahanan server yang buruk dan geekiness eksplisit dari antarmuka klien - semua ini adalah tugas yang dapat diselesaikan, meskipun tidak sepele (di tingkat global, ini tidak mengubah apa-apa). Saya suka bahwa para pengembang memperhitungkan pengalaman XMPP dan mengembangkan spesifikasi umum alih-alih sekelompok XEP independen, tetapi ini hanya salah satu kelemahan XMPP. Masalah lain adalah perangkat klasik dari jaringan federal, ketika kita dipaksa untuk memilih beberapa server dan mempercayai pemiliknya bahwa itu akan memastikan server berfungsi dan tidak akan menutupnya. Dan jika terjadi kegagalan lain dari pusat data, kami akan terputus dari dunia, tidak dapat berkomunikasi dengan akun sebelumnya di server lain. Bahkan jika Anda membuat akun baru, dan entah bagaimana mentransfer daftar kontak Anda dari server lama, saat berkomunikasi, Anda harus mengonfirmasi kembali bahwa itu benar-benar Anda, dan bukan seseorang yang memperkenalkan Anda.
Dalam hal ini, mungkin benar-benar meninggalkan server? Ada sejumlah pengirim pesan instan yang didasarkan pada teknologi tanpa server. Kasus khusus di sini adalah yang populer di kalangan sempit Firechat, yang menggunakan jaringan jala dari perangkat wifi dan bluetooth untuk berkomunikasi dengan pengguna. Utusan ini benar-benar berfungsi dengan baik ketika semua pengguna terkonsentrasi, misalnya, di area tersebut. Tetapi ini adalah situasi yang agak spesifik, dan bahkan jika kita membayangkan situasi di mana setiap penghuni planet ini menginstal aplikasi, ini menciptakan banyak masalah lain dari jeda jaringan mesh oleh tanda-tanda geografis dan kecepatan bertukar pesan dengan pengguna yang jauh, dengan jumlah data yang tersimpan yang diperlukan pada perangkat. Tapi, mungkin, kurir ini tersingkir dari massa total dan dalam perbandingan kita tidak berguna. Ini lebih eksperimental daripada user-centric.
Ada juga proyek-proyek seperti Tox yang mencoba mengimplementasikan messenger p2p. Pendekatan ini memungkinkan Anda untuk tidak khawatir tentang keamanan server, dan hampir tidak mungkin memblokir messenger semacam itu. Tox memiliki banyak masalah, tetapi ini adalah proyek yang sangat menarik yang memiliki ceruk tersendiri. Tidak masuk akal untuk menyebutkan kerugian spesifik Tox, karena proyek ini sedang berkembang dan terlepas dari kenyataan bahwa layanan p2p jauh lebih sulit untuk dikembangkan, jika Anda menetapkan tugas seperti itu, Anda dapat membuat berbagai arsitektur menarik untuk membangun jaringan seperti itu: dengan kelebihan dan kekurangannya sendiri, persyaratan berbeda untuk lebar saluran internet dan jumlah ruang pada perangkat, dengan super-node, login simultan dari berbagai perangkat dan bahkan pengiriman pesan offline. Tetapi umum akan selalu ada redundansi lalu lintas yang signifikan dibandingkan dengan arsitektur client-server dan peningkatan daya baterai pada perangkat seluler karena kebutuhan untuk terus-menerus memegang sejumlah besar koneksi dan berbagai perhitungan.
Jadi, meskipun p2p adalah teknologi yang menarik, itu akan menjadi tidak efektif jika, katakanlah, mengirimkan koordinat Anda ke penyelamat, berada di suatu tempat di pohon di taiga dengan hampir tidak ada koneksi internet dan biaya baterai 1%.
Bagaimana cara memperbaikinya?
Oleh karena itu, saya ingin memperkenalkan arsitektur client-server hybrid yang mengambil yang terbaik dari pendekatan yang ada dan menghindari kelemahan mereka.
Jadi, agar messenger kami dengan sumber daya minimum yang diperlukan bekerja di perangkat seluler, kami akan menggunakan model client-server, di mana operasi komputasi maksimum dan sumber daya yang menuntut lalu lintas terkonsentrasi di server, dan di sisi klien data didekripsi dan ditampilkan kepada pengguna.
Mengatasi masalah
Setiap pengguna menerima alamatnya dalam format E-Mail, atau XMPP, yaitu, nama panggilan @ domain. Namun tidak seperti layanan yang disebutkan di atas, menentukan domain tidak memiliki peran alamat penting yang sama dalam arsitektur ini.
Domain lebih cenderung digunakan sebagai pendaftar nama panggilan untuk mengesampingkan kemungkinan bahwa semua nama panggilan yang ada mungkin secara sengaja atau tidak sengaja ditempati.
Domain membutuhkan uang di Internet, yang tidak menghalangi pendaftaran massal, tetapi secara signifikan mengurangi cakupannya. Dalam layanan terpusat, akses seringkali melalui tautan ke telepon seluler, yang juga bukan merupakan faktor eksklusif, tetapi kartu SIM juga tidak diambil dari udara! Dan dalam hal ini, omong-omong, saya bertanya-tanya bagaimana mereka akan melawan ini di https://toxme.io/ - layanan untuk Tox yang memungkinkan Anda untuk mengaitkan kunci panjang dengan nama panggilan pendek. Saya tidak melihat alasan mengapa mereka tidak dapat dib spam dengan milyaran julukan sampah.
Selain itu, domain mungkin masuk akal untuk berbagai akun untuk rumah dan kantor. Atau untuk mengatur jaringan internal perusahaan.
Dari sudut pandang pengguna, untuk menulis kepada seseorang, Anda perlu mengetahui login lengkap atau kunci publiknya.
Dari sudut pandang perangkat lunak server, jika pengguna diminta untuk sidik jarinya, server mencari dalam tabelnya untuk login yang terkait dengannya, jika diminta segera untuk login, masing-masing, langkah ini dilewati. Kemudian, login dan alamat server tempat akun tersebut didelegasikan dibuat. Jika tidak ada entri seperti itu, dianggap bahwa akun yang ditunjukkan setelah @ dalam login bertanggung jawab atas akun tersebut.
Profil pengguna
Aplikasi klien menyimpan profil pengguna yang mewakili:
- Login pengguna penuh
- Daftar server cadangan
- Kunci pengguna publik dan pribadi
- Informasi profil seperti daftar kontak, pengaturan obrolan dan profil pengguna
Kunci publik dari setiap pengguna didistribusikan di antara masing-masing server di jaringan gabungan. Pengguna dapat masuk ke salah satu server, karena otentikasi tidak menggunakan hash kata sandi yang disimpan dalam database server, tetapi kunci pribadi pengguna.
Prosedur otorisasi adalah sebagai berikut: server mengirimkan satu set data acak yang dienkripsi dengan kunci publik dari klien ke klien, klien mendekripsi dengan kunci privatnya dan mengirimkan hash dari data yang didekripsi ke server. Jika hash data cocok, server akan mengotorisasi pengguna. Pada saat yang sama, jika pengguna terakhir kali mengubah server tempat koneksi dibuat, maka semua server dari jaringan gabungan diberitahu tentang lokasi baru pengguna.
Tidak adanya kebutuhan untuk mengingat kata sandi (namun, klien memungkinkan Anda untuk mengenkripsi kunci privat) keduanya menyederhanakan interaksi dengan messenger dan menciptakan risiko kehilangan kunci Anda. Untuk menghindari hal ini, disarankan untuk menggandakannya ke perangkat pengguna lain. Tidak ada yang mencegah obrolan di bawah akun yang sama dari beberapa perangkat pada saat yang sama, satu-satunya batasan adalah mereka semua harus terhubung ke server yang sama, jika tidak arsitektur akan menjadi terlalu membingungkan. Tapi ini bukan minus besar.
Add-on untuk browser
Bagi banyak produk, titik lemahnya adalah aplikasi web. Dan solusi ini, tentu saja, memiliki banyak kelemahan. Obrolan seperti itu tidak akan diunduh saat Anda luring, maka Anda harus menunggu unduhan lengkap, dan alamatnya mungkin diblokir, atau server bisa macet. Menyortir alamat secara manual - Saya tidak terlalu suka.
Dan opsi belum dikecualikan bahwa penyerang akan meretas aplikasi web dan menanamkan kode yang akan menggabungkan semua data Anda - bahkan setelah bagian lain dari aplikasi mendekripsi untuk Anda, dan Anda bahkan tidak mengetahuinya.
Dalam hal ini, saya mengusulkan untuk meninggalkan aplikasi web seperti itu, dan mengusulkan menginstal add-on untuk browser, di mana semua kekurangan ini secara definisi tidak ada.
Selain itu, tidak adanya kebutuhan untuk pemilik server konfigurasi klien web untuk menurunkan ambang entri untuk membuat server mereka. Setiap rumah tangga memiliki server sendiri!
Transportasi
Siapa yang butuh utusan di mana tidak ada orang untuk berkomunikasi? Ada proyek menarik dari pembawa pesan yang tidak biasa, tetapi masalah kurangnya penonton tidak memungkinkan mereka untuk mendapatkan setidaknya beberapa popularitas. Akibatnya, lebih sering daripada tidak utusan dengan audiens yang besar mendapatkan audiensi lebih banyak, dan pengirim pesan instan dengan audiens kecil kehilangannya. Dan paling sering situasi ini hanya dapat mengubah investasi yang signifikan dalam periklanan.
Selain itu, keadaan ini membutuhkan pemasangan messenger lain, ketika Anda harus segera menghubungi seseorang yang tidak ada di jaringan lain.
Oleh karena itu, server harus mendukung operasi transportasi ke jaringan pihak ketiga.
Jika pengguna menentukan data yang akan dihubungkan ke akunnya di messenger instan lain, ia akan melihat orang-orang dari jaringan yang ia hubungkan di kontaknya.
Koneksi ke jaringan pihak ketiga dibuat di sisi server, dan di klien kontak ditampilkan sebagai yang paling biasa, dengan perbedaan minimal - misalnya, ikon jaringan dari mana pengguna berasal ditampilkan.
Sebagai suatu kerugian, menjadi perlu untuk mempercayai server dengan data untuk terhubung ke jaringan pihak ketiga. Tidak semua orang siap untuk mendelegasikan wewenang mereka ke server pihak ketiga, jadi Anda perlu mendorong pembuatan server Anda sendiri dengan segala cara.
Kriptografi
Tentu saja, perangkat jaringan terdesentralisasi tidak dapat melakukan tanpa enkripsi semua data yang dikirimkan, karena kami tidak dapat memastikan bahwa bahkan di server yang dipercayakan kepada kami, tidak ada semacam tab yang menggabungkan semua data.
Telah ditunjukkan bahwa sepasang kunci pengguna digunakan untuk otorisasi, semua pesan yang dikirim ke pengguna lain juga ditandatangani dengan kunci pribadi pengirim dan dienkripsi dengan kunci publik dari pihak penerima.
Tidak ada yang baru di sini, alat enkripsi GPG standar digunakan.
Masalah enkripsi dalam grup belum diselesaikan, tetapi Anda mungkin dapat menggunakan mekanisme yang digunakan dalam Signal.
Apa yang sudah dilakukan
Saat ini, kami telah membuat server di Python menggunakan Tornado, yang mengimplementasikan fungsi dasar messenger, ada versi web yang sedikit beku yang harus dikonversi ke tambahan untuk browser, ada perpustakaan di Rust, yang menjadi dasar klien beroperasi dengan antarmuka QML.
Koneksi ke server dilakukan menggunakan WebSockets, di mana data diserialisasi secara default ke format biner dari representasi data CBOR, tetapi ketika membuat koneksi WebSockets, dimungkinkan untuk meminta format yang berbeda, misalnya protobuf.
Saya juga menganggap penting untuk dicatat bahwa klien menggunakan divisi ke dalam daftar obrolan, diurutkan berdasarkan tanggal pesan terbaru, banyak digunakan dalam pesan instan modern, dan daftar nama tradisional, dengan menyortir kontak ke dalam kategori. Dengan penggunaan aktif messenger, Anda harus berinteraksi dengan sejumlah besar obrolan, dan menjadi sulit untuk mencari mereka dalam urutan daftar yang selalu berubah. Dalam Telegram yang sama sebagian menyelesaikan masalah menyematkan obrolan terpilih di bagian atas daftar, tetapi ini hanya solusi sementara untuk masalah tersebut.
→ Berikut adalah repositori yang berisi wawasan kami