İnsanlar Matrix'i kendi sunucularında barındırır, çünkü bir şirketin konuşmalarına el koymasını böylece durdururlar ve bu kısım tam da vaat edildiği gibi işler. Sonradan şaşırdıkları şey, kurdukları şeyin gerçek şeklidir: bir homeserver, sohbeti olan sıradan bir özel kutu değildir. Herkese açık bir ağdaki bir çoğaltma (replikasyon) düğümüdür ve federasyon, çoğu yeni yöneticinin beklediğinden çok daha fazla bir yayın protokolü gibi davranır.
Bunların hiçbiri bir homeserver çalıştırmaya karşı bir gerekçe değildir — tam tersine, onu bilinçli biçimde çalıştırmanın gerekçesidir. Kazandığınız gizlilik gerçektir ama sınırlıdır: kontrol size geçer, hesabınızı başkası kapatamaz ve hukuki sorular bir şirketin değil, sizin seçtiğiniz bir yargı alanına düşer. Kazanmadığınız gizlilik de aynı derecede belirgindir ve bunun neredeyse tamamı "mesajlar şifreli" ile "kimin kiminle konuştuğu belli değil" arasındaki boşlukta yaşar. Bu rehber her iki yarıyı da, ardından sunucunun bir yıl sonra hâlâ sağlıklı olup olmayacağını belirleyen operasyonel ayrıntıları ele alır.
Kendi homeserver'ınızı çalıştırmak gerçekte neyi değiştirir
Önce tehditleri birbirinden ayırarak başlayın, çünkü bir homeserver bunların bir kısmını tamamen, bir kısmını kısmen çözer, bir kısmını ise hiç çözmez. Aşağıdaki tablo bu vaadin dürüst hâlidir ve donanımı seçmeden önce okunmayı hak eder.
| Endişeniz nedir | Kendi homeserver'ınız bunu çözer mi? |
|---|---|
| Bir şirketin mesajlarınızın içeriğini okuması | Uçtan uca şifreleme bunu özel odalarda zaten karşılar — evet, kendi sunucunuzu çalıştırmak şirketi de tamamen devre dışı bırakır |
| Bir şirketin kiminle ne zaman konuştuğunuzu profillemesi | Kısmen. Tek bir merkezi operatörü beslemeyi bırakırsınız, ancak bu kaydı artık kendi sunucunuz tutar |
| Hesabınızın başkası tarafından kapatılması veya askıya alınması | Evet. Bütün bu işin en net kazanımı, ve en az konuşulanı |
| Verileriniz için gelen bir hukuki talep | Ortadan kalkmaz, yer değiştirir. Talep artık size, seçtiğiniz ülkenin hukuku altında ulaşır |
| Başkalarının sosyal grafınızı öğrenmesi | Hayır. Odada üyesi olan her sunucu, sizinkiyle aynı üyelik verisini alır |
| Sunucunun var olduğunu bile gizlemek | Hayır. Federasyon herkese açık bir isim ve erişilebilir bir port gerektirir; bu, gizliliğin tam tersidir |
Son iki satırı dikkatle okuyun, çünkü beklentilerin kırıldığı yer tam olarak burasıdır. Amacınız bir hizmetin var olduğunun bile tespit edilememesiyse, Matrix yanlış araçtır ve bir onion servisi doğru olana daha yakındır. Amacınız denetim, kontrol ve yargı yetkisiyse, bir homeserver mükemmel bir araçtır ve bu rehberin geri kalanı onu iyi çalıştırmakla ilgilidir.
Federasyon, bir sohbet protokolü kılığına girmiş bir çoğaltma protokolüdür
Çoğu şaşırtan durumu açıklayan mekanizma şudur. Kullanıcılarınızdan biri başka bir yerde barındırılan bir odaya katıldığında, sunucunuz bir e-posta istemcisi gibi mesajları talep üzerine çekmez. Dağıtık bir olay grafiğinde katılımcı olarak odaya katılır, ardından odanın olaylarının, üyeliğinin ve sonrasını doğrulamaya yetecek durum geçmişinin bir kopyasını çeker ve saklar. O andan itibaren makineniz bir kopya (replika) tutar, ve federasyona katılan diğer her sunucu da bir tane tutar.
Sonuçlar iki yönde de işler ve hiçbiri sezgisel değildir. Kullanıcılarınızın ürettiği veriler — görünen ad, avatar, katılma ve ayrılmalar, zaman damgaları, tepkiler — o odada üyesi olan her sunucuya kopyalanır ve siz kendi tarafınızda sonradan silseniz bile onların veritabanlarında kalmaya devam eder. Redaksiyon (içerik silme) eşlere gönderilen bir taleptir, bir komut değildir. Bağımsız işletilen sunuculardan oluşan bir federasyonda "gönderiyi geri alma" diye bir şey yoktur, ve böyle bir şey beklemek bu protokolle ilgili en yaygın yanlış anlamadır.
Diğer yönde ise, büyük genel odalara katılmak başkalarının geçmişini diskinize aktarmak anlamına gelir. Üç kullanıcısı olan yepyeni bir homeserver'ın onlarca gigabaytlık bir veritabanı taşıyabilmesinin sebebi budur: üç kullanıcınızın çok şey yazması değil, elli bin üyeli ve yıllar süren durum geçmişine sahip odalara katılmış olmalarıdır. Bilinçli oda seçimi, gizlilik kadar bir kapasite kararıdır da.
Şifreleme neyi kapsar, ne açıkta kalır
Matrix, mesaj içeriğini Megolm ile şifreler ve bu, özel odalarda varsayılan olarak açıktır. Bu, insanların en çok önemsediği kısmı korur ve gerçekten işe yarar — sunucunuz okuyamadığı bir şifreli metin saklar, ki bu, sunucu kiralık donanım olduğunda gerçek ve faydalı bir özelliktir. Mesajın etrafındaki zarf ise başka bir hikâyedir, ve buradaki boşluk çoğu özetin kabul ettiğinden daha geniştir.
| Sinyal | Şifreli mi? | Kime görünür |
|---|---|---|
| Mesaj metni ve dosya içerikleri | Evet | Yalnızca oda üyelerinin doğrulanmış cihazlarına |
| Odada kimlerin olduğu ve her katılma veya ayrılma | Hayır | O odada üyesi olan her homeserver'a |
| Zaman damgaları, mesaj sıklığı, aktif olunan saatler | Hayır | Federasyona katılan her homeserver'a |
| Görünen adlar, avatarlar, çevrimiçi durumu ve yazıyor bildirimi | Hayır | Federasyona katılan her homeserver'a |
| Oda adı, konusu ve avatarı | Hayır | Federasyona katılan her homeserver'a |
| Ek boyutu ve aktarımın zamanlaması | Hayır | Federasyona katılan her homeserver'a |
| Sunucunuzun alan adı ve IP adresi | Hayır | Federasyonun tamamına — bu, tasarım gereğidir |
Pratikteki karşılığı şudur: şifreleme neyin konuşulduğunu korur, federasyon ise kimin, ne zaman ve ne sıklıkla konuştuğunu yayınlar. Çoğu topluluk için bu takas tamamen kabul edilebilirdir ve mesele de bu dürüstlüktür. Sosyal grafın kendisinin hassas olduğu bir tehdit modelinde ise federe bir protokol yapısal olarak yanlış kalıptır, ve hiçbir yapılandırma bayrağı bunu değiştirmez.
Synapse, Dendrite mi Conduit mi — gerçekte hangisini çalıştırmalı
Pratikte üç uygulama önemlidir, ve seçim çoğunlukla felsefi değil, bir kaynak kararıdır.
- Synapse, Python ile yazılmış referans sunucudur ve ilk günden itibaren her özelliğin çalıştığı tek uygulamadır. Aynı zamanda en açgözlü olanıdır: bellek kullanımı, kullanıcılarınızın katıldığı odaların sayısı ve büyüklüğüyle birlikte artar, ve yoğun bir sunucu er ya da geç worker süreçlerine bölünmek ister. Alanlar (spaces), moderasyon araçları, köprüler ve yönetici API'lerinin tam olarak belgelendiği gibi davranmasını istiyorsanız bunu seçin.
- Dendrite, Go ile yazılmış yeniden yazımdır. Synapse'ten belirgin şekilde daha hafiftir ve küçük bir sunucu için gayet kullanılabilir, ancak bunun bedeli bazı özelliklerin geriden gelmesidir. Synapse, sahip olduğunuz kullanıcı sayısına göre ağır geliyorsa makul bir orta seçenektir.
- Conduit ve onun aktif geliştirilen çatalı
conduwuit, Rust ile yazılmıştır ve gömülü bir veritabanıyla tek bir ikili dosya olarak dağıtılır. Sattığımız en küçük planda bile bir aile veya küçük bir topluluk sunucusunu sorunsuzca çalıştırırlar. Bunun bedeli daha küçük bir ekosistemdir: bazı yönetici araçları ve birkaç köprü Synapse varsayar.
Az sayıda kullanıcısı olan ilk bir sunucu için, küçük bir VPS üzerinde Conduit ailesinden yazılım, işe yarayan ve ucuz kalan bir sonuca giden en az sancılı yoldur. Büyümesini beklediğiniz her şey için — genel bir topluluk, bir şirket, köprüleri olan bir proje — Synapse ile başlayın ve göçü baştan atlayın, çünkü uygulamalar arasında sonradan geçiş yapmak bir yapılandırma değişikliği değil, dışa aktarıp yeniden kurma işidir.
Herkesin yanlış yaptığı devretme (delegation) kurulumu
Matrix, kullanıcı kimliklerinizdeki adı, trafiği sunan makineden ayırır, ve bunu ters anlamak kendi sunucunuzu barındırırken yapılan en yaygın, kalıcı hatadır. server_name, sunucunuzdaki her kullanıcı kimliğinde iki nokta üst üsteden sonra görünen alan adıdır. İlk olay imzalandığı anda federasyondaki kimliğinizin bir parçası hâline gelir ve makinedeki her hesap ve odadan vazgeçmeden sonradan değiştirilemez.
Neredeyse her zaman istediğiniz kurulum şudur: server_name çıplak alan adınız olur, yazılım ise bir alt alan adında çalışır. İkisini devretme (delegation) yoluyla birbirine bağlarsınız, ve bunun iki yolu vardır. Basit olanı, çıplak alan adında /.well-known/matrix/server konumunda sunulan ve gerçek sunucuyla portu belirten statik bir JSON dosyasıdır. Diğer seçenek ise aynı yeri işaret eden bir DNS kaydı olan _matrix._tcp'dir. Uygulamaların homeserver'ı yalnızca bir adresten bulabilmesi için istemci tarafı dosyasını da /.well-known/matrix/client konumunda sunun.
Hiçbir şey kurmadan önce adı belirleyin. Yazılımın çalıştığı yer olduğu için server_name'i alt alan adına ayarlamak klasik hatadır ve geri döndürülemez: her kullanıcı kimliği, oda kimliği ve imzalanmış olay bunu sonsuza dek taşır. Bir kartvizite basılmasını isteyeceğiniz alan adını seçin, sürecin gerçekte dinlediği her yere devredin, ve her iki addaki TLS sertifikasını da geçerli tutun — devredilen sunucudaki bir sertifika hatası, uygulama yerelde sorunsuz görünse bile federasyonu çökertir.
Boyutlandırmayı dürüstçe yapmak
Matrix, normal çalışmada CPU'ya değil, belleğe ve veritabanı davranışına bağlıdır. Synapse için yayımlanan rakamlar kullanışlı bir taban çizgisidir: başlangıçta yaklaşık 2 GB RAM, on ila elli aktif kullanıcıda yaklaşık 4 GB, yüzü aştığında ise 8 GB veya daha fazlası. Conduit ailesi sunucular bunun çok altında kalır. Bu rakamların atladığı nokta şudur: tüketim, kayıtlı kişi sayısını değil, katılınan odaları takip eder — yüz büyük genel odadaki beş kullanıcı, birkaç özel odadaki elli kullanıcıdan çok daha pahalıya mal olur.
Buradan iki pratik kural çıkar. Veritabanını hızlı bir depolama üzerine koyun ve büyümesi için yer bırakın, çünkü yazma deseni patlamalı değil, küçük ve süreklidir. Ve bugünkü kullanıcı sayınıza göre boyutlandırmayın: o kullanıcıların ilk ayda katılacağı odalara göre boyutlandırın, çünkü sürpriz genellikle orada saklıdır. Giriş seviyesi planımız küçük bir Conduit veya Dendrite sunucusunu rahatça taşırken, gerçek bir topluluk için bir Synapse örneği orta katman bir plana veya üzerine aittir — sohbet barındırma sayfası, bu profillerin her birine karşı önerdiğimiz katmanları listeler.
Çalışma süresi burada çoğu iş yüküne göre daha fazla önem taşır, çünkü çevrimdışı bir sohbet sunucusu yalnızca erişilemez olmakla kalmaz — eşlerin bir süre yeniden deneyip sonra göndermeyi bırakacağı olayları sessizce kaçırır. Federasyon dakikaları hoşgörür, günleri affetmez.
Medya deposu, ağır çekimde patlayan bir disk bombasıdır
Kullanıcılarınızın bulunduğu bir odadan geçen her görsel, video ve dosya, kullanıcılarınızın hiç açmadığı uzak medya dahil, diskinizde önbelleğe alınmış olarak bitebilir. Synapse'teki varsayılan saklama politikası bunu süresiz olarak tutar. Sonuç öngörülebilirdir ve yine de insanları yakalar: veritabanı istikrarlı olan ama medya dizini sessizce büyüyen bir sunucu, disk doluncaya kadar fark edilmez — o noktada belirti "disk dolu" değil, "sunucu tuhaf davranıyor" olur.
Uzak medya için bir saklama politikasını ilk kesintiden sonra değil, ilk günden itibaren belirleyin. Synapse, homeserver.yaml içinde saklama ayarlarını sunar; ayrıca eski geçmişi ve önbelleğe alınmış dosyaları temizlemek için yönetici uç noktaları vardır; synapse-compress-state ise eski bir sunucuda durum tablolarından şaşırtıcı miktarda yer geri kazandırır. Hem veritabanını hem medya yolunu izleyin, ve hizmetin çökmesi yerine boş alan üzerine uyarı kurun — ikinci belirti, birincisinden günler sonra ortaya çıkar.
Bir ayar, varsayılana bırakılmak yerine bilinçli bir karar hak eder. URL önizlemeleri, bir odaya gönderilen her bağlantıyı sunucunuzun getirmesine yol açar, ki bu da birisi bir bağlantı yapıştırdığı anda sunucunuzun IP adresinin üçüncü bir tarafa giden bir istek yapması anlamına gelir — özellikle kimin tıkladığını görmek için seçilmiş bir bağlantı da dahil. Homeserver'ınız bir önün arkasındaysa ve gerçek adresi önemliyse, bunu dikkatle tartın; kaynak adresi gizleme rehberimiz aynı sızıntı sınıfını daha ayrıntılı ele alır.
Kayıt, spam ve devraldığınız itibar
Herkese açık bir homeserver'da açık kayıt, bir davetiyedir, ama istediğiniz türden değil. Otomatik kayıtlar günler içinde küçük bir sunucuyu spam kaynağına dönüştürür, ve bunun sonucu yerel kalmaz: diğer homeserver'lar alan adınızı erişim kontrol listelerine ekler, ve adınız yeterince listede yer aldığında meşru kullanıcılarınız başka yerlerdeki odalara katılamaz hâle gelir. Yanmış bir alan adı itibarını kurtarmak, onu baştan önlemekten çok daha zordur — tıpkı e-posta ulaştırılabilirliğinde olduğu gibi.
Savunulabilir varsayılanlar basittir. Özel bir sunucu için enable_registration ayarını kapalı tutun ve hesapları kendiniz dağıtın. Kapıyı açık tutmak istiyorsanız, denetim altına alın: registration_requires_token, üçüncü taraf bir servise ihtiyaç duymadan kaydı bir davet sistemine dönüştürür, ve bir captcha da sorunun kaba ucuna karşı yardımcı olur. Yönettiğiniz odalar için, Mjolnir ve Draupnir ailesindeki moderasyon botları, yasaklama listelerini ve oda ACL'lerini tek tek değil, bütün bir topluluk genelinde uygulamanızı sağlar.
Tersi yönde bilinmeye değer bir nokta: adres aralıklarımız, homeserver'lar arasında dolaşan Matrix ACL kara listelerinde yer almaz, bu yüzden yeni bir sunucu temiz bir itibarla başlar. O itibara sonrasında ne olacağını belirleyen şey, makinenin nerede olduğu değil, kaydı nasıl yönettiğinizdir.
Köprüler ve beraberinde gelen metaveri faturası
Köprüler, birçok insanın Matrix'te kalmasının dürüst nedenidir: başka ağlarda yaşayan odalar için tek bir istemci. Aynı zamanda sunucunuzun güvenlik konumunu, kolayca gözden kaçan bir biçimde değiştirirler. Bir köprü, uzak hesap için kimlik bilgilerini tutar ve protokollerin buluştuğu sınırda, dönüştürebileceği bir biçimde mesajları işlemek zorundadır — bu da köprü sürecinin, her iki tarafında da uçtan uca şifreli olan trafiğin düz metnini gördüğü anlamına gelir.
Bu, köprülerden kaçınmak için bir sebep değildir. Köprünün çalıştığı makineyi hassas bir altyapı olarak ele almak için bir sebeptir: ele geçirildiğinde, adına konuştuğu hesapları ifşa eden makine budur. Her köprü, küçük bir sunucunun bellek ayak izini kabaca ikiye katlar, bu yüzden kapasiteyi buna göre planlayın, ve nerede çalıştığına, homeserver'ın kendisine gösterdiğiniz özenin aynısını gösterin — yargı yetkisi rehberimizdeki mantık, aynı anda birden fazla ağın kimlik bilgilerini tutan bir makineye daha fazla ağırlıkla uygulanır.
Sunucuyu ayakta tutmak: anahtarlar, yedekler ve yükseltmeler
Bir Matrix sunucusunun, kaybı veri hacmiyle hiç ilgisi olmayan bir biçimde telafisi imkânsız olan tek bir dosyası vardır. İmzalama anahtarı — Synapse'te signing.key — sunucunuzun, alan adınızdan geldiğini iddia eden olayların gerçekten öyle olduğunu kanıtlamasının yoludur. Onu kaybederseniz artık inandırıcı biçimde kendi sunucunuz olamazsınız; eşleriniz, adınızı taşıyan bir yabancı tarafından imzalanmış olayları reddedecektir. Onu her şeyin geri kalanından ayrı yedekleyin ve o kopyayı makinenin dışında tutun.
Anahtarı ve veritabanını yedekleyin, ve birini diğeri olmadan geri yüklemenin neden tehlikeli olduğunu anlayın. Bir Matrix veritabanını daha eski bir anlık görüntüye döndürmek, sunucunuzu eşlerinin çoktan geride bıraktığı bir duruma sokar, ve ortaya çıkan sapmayı onarmak temiz bir yeniden kurulumdan çok daha zordur. pg_dump ile tutarlı dökümler alın, bunları makinenin dışında tutun, ve bu platformda geri dönülecek bir sağlayıcı kopyası olmadığını unutmayın — sonlandırmadan sonra hiçbir şey saklanmaz, ki bu anlaşmanın bütün amacıdır ve yedekleme rehberimizde ele alınır.
Yükseltmeler sıradandır ama isteğe bağlı değildir. Homeserver sürümleri şema geçişleri taşır, ve birçok sürümü atlamak beş dakikalık bir yükseltmeyi bir öğleden sonraya çevirir. Atlamadan önce sürüm notlarını okuyun, her adımın küçük kalması için yeterince düzenli yükseltin, ve ilk saat sıkılaştırma listesindeki temel sunucu hijyenini uygulayın — bir sohbet sunucusu, veritabanı bağlı, uzun ömürlü ve internete açık bir servistir, ve aynı muameleyi hak eder.
Sunucunun bulunduğu yer, sonucu hâlâ belirler
Yukarıdakilerin hepsi yapılandırmadır. Yapılandırmanın dokunamadığı kısım, kullanıcılarınız hakkındaki bir talebi hangi hukuk sisteminin alacağıdır, ve bir iletişim sunucusu için bu soru bir web sitesinden çok daha fazla ağırlık taşır. Bir homeserver, mesaj gövdeleri şifreli olsa bile üyelik kayıtlarını, zaman damgalarını ve sosyal graf verisini açıkta tutar — dolayısıyla onu barındıran yargı yetkisi, o kayda erişimi yöneten yargı yetkisidir.
Bir konumu yalnızca gecikme süresine göre değil, bilinçli olarak seçmenin pratik gerekçesi budur. Biz yedi yargı yetkisinde sunucu işletiyoruz, ve aralarındaki ödünleşimler yargı yetkisi rehberimizde ve konumlar sayfasında anlatılır. Aynı sorunun diğer yarısı, sağlayıcının sizi kim olarak tanıdığıdır: hiçbir kimliğin bağlı olmadığı bir hesap, hiç toplamadığı kimlik belgelerini üretemez, ki KYC'siz barındırma ile kendi kendine barındırılan iletişimin aynı konuşmada sürekli birlikte anılmasının açık nedeni budur. Hiçbiri, adınızı zaten bilen bir mahkemeye karşı savunma değildir, ve OpSec rehberimiz bu çizginin nerede durduğu konusunda açık sözlüdür.
Kısa özet
Bu sayfadan altı şey alacaksanız, şunları alın:
- Hiçbir şey kurmadan önce
server_name'i seçin — bu, asla geri alamayacağınız tek karardır. /.well-known/matrix/serverveya bir SRV kaydıyla devredin, ve her iki addaki TLS'yi de geçerli tutun.- Kaç kullanıcınız olduğuna değil, kullanıcılarınızın katılacağı odalara göre boyutlandırın.
- Medya saklamayı ilk günden ayarlayın, ve URL önizlemeleri konusunda varsayılanı miras almak yerine kendiniz karar verin.
- Kaydı kapalı veya jeton korumalı tutun; yanmış bir alan adı itibarını geri kazanmak pahalıya mal olur.
signing.key'i ayrı yedekleyin, ve veritabanını asla eşlerinizin gerisinde bir noktaya geri sarmayın.
Bunları yapın, sunucu da tam bir sohbet sunucusunun olması gerektiği gibi sıradan kalsın. Karşılığında elde ettiğiniz şeyi açık gözle değerlendirmeye değer: görünmezlik değil, kimin kiminle konuştuğunu gizleyen bir protokol de değil, ama içeriği size ait olan konuşmalar, başkasının kapatamayacağı bir hesap ve bilinçli olarak seçtiğiniz bir hukuk sisteminin altında duran bir makine. Homeserver'ı kendi seçtiğiniz bir yere koyun, ve federasyonun ona gelmesine izin verin.