Cum se configurează sincronizarea glisantă Matrix pentru o încărcare mai rapidă pe mobil (fără proxy-ul vechi)

Actualizare, 6 octombrie 2026: Proxy-ul independent Matrix Sliding Sync nu mai este componenta potrivită de instalat. Matrix.org și-a arhivat matrix-org/sliding-syncdepozitul în noiembrie 2025 deoarece a implementat API-ul MSC3575 mai vechi, care a fost înlocuit de Simplified Sliding Sync (MSC4186). Synapse a acceptat implementarea nativă de la versiunea 1.114, cu suportul activat în mod implicit. În iulie 2026, echipa Matrix Spec Core a acceptat propunerea principală MSC4186; propunerile de extensie aferente rămân o lucrare separată.

Pentru o implementare mobilă modernă Synapse, configurația practică este să rulați o versiune curentă de Synapse, să confirmați că aceasta promovează Sliding Sync nativ, să vă asigurați că proxy-ul invers transmite neschimbate căile API ale clientului Matrix și să utilizați un client mobil compatibil. Nu sunt necesare un container proxy separat, o bază de date proxy și o adresă URL veche de descoperire a proxy-ului.

Ar trebui să instalați în continuare proxy-ul independent Sliding Sync?

Nu, nu pentru o nouă implementare destinată clienților mobili Matrix actuali. Proxy-ul arhivat implementează MSC3575, nu fluxul nativ MSC4186 mai nou. Depozitul propriu al proiectului precizează că acesta nu mai este întreținut și că nu se mai așteaptă ca clienții Matrix moderni să funcționeze cu acesta. Matrix.org a anunțat, de asemenea, trecerea la suport nativ și eliminarea suportului pentru proxy-ul MSC3575 din Element X în ianuarie 2025.

Ghidul proxy-ului istoric poate fi în continuare util la identificarea unei instalări vechi: acesta folosea PostgreSQL, un secret persistent și o SYNCV3_*configurație de mediu. Aceste instrucțiuni descriu o arhitectură retrasă. Nu le copiați pe un server nou și nu expuneți public un proxy vechi doar pentru că un tutorial vechi îl apelează mai rapid.

Ce s-a schimbat și ce înseamnă acest lucru pentru utilizatorii de dispozitive mobile?

Proxy-ul anterior era un serviciu separat care se afla între un client și serverul său principal. Sincronizarea glisantă simplificată este implementată chiar în Synapse. Aceasta permite clienților compatibili să solicite o fereastră relevantă din lista de camere a unui utilizator și să o actualizeze incremental, ceea ce poate reduce volumul de lucru de sincronizare pe care o aplicație mobilă trebuie să îl efectueze la deschiderea sau revenirea la un cont mare.

Aceasta este o îmbunătățire a sincronizării, nu o garanție că fiecare ecran se va încărca instantaneu. Nu face ca un server media lent, o alăturare întârziată la o cameră la distanță, o acoperire mobilă slabă sau o bază de date aglomerată să dispară. Aplicația mobilă trebuie să fie compatibilă cu MSC4186, iar serverul de acasă trebuie să îl promoveze. Anunțul Matrix.org precizează că implementarea nativă Synapse evită stocarea separată a datelor de către vechiul proxy și limitarea inițială de sincronizare completă.

De ce ai nevoie înainte să îl activezi?

• Un server de acasă Matrix care rulează Synapse. Acest ghid nu presupune că Dendrite, Conduit sau un alt server de acasă expune aceeași implementare nativă.
• O versiune Synapse întreținută. Versiunea 1.114 a introdus suport nativ pentru MSC4186, dar folosește o versiune acceptată în prezent, în loc să trateze versiunea 1.114 ca o recomandare de securitate sau întreținere.
• Un client mobil care acceptă Simplified Sliding Sync. Un server local capabil nu poate obliga un client mai vechi să utilizeze o API pe care nu o implementează.
• Un punct final funcțional al clientului HTTPS și o configurație de proxy invers pentru serverul de acasă.
• O copie de rezervă recentă a bazei de date și a configurației înainte de actualizarea sau modificarea rutării serverului.

Cum poți verifica dacă Synapse promovează deja Sliding Sync nativ?

Interogați endpoint-ul versiunilor publice ale API-ului Client-Server dintr-un terminal. Înlocuiți gazda exemplu cu adresa URL publică de bază pe care o utilizează clienții dvs. Matrix:

curl -fsS https://matrix.example.org/_matrix/client/versions   | jq -r '.unstable_features["org.matrix.simplified_msc3575"]'

Un răspuns de truetipul înseamnă că serverul anunță semnalizarea funcției native Simplified Sliding Sync. Un răspuns de tipul false, null, sau o cheie lipsă înseamnă că ar trebui să verificați versiunea și configurația Synapse înainte de a testa clientul. Dacă jqnu este instalat, solicitați aceeași adresă URL într-un browser sau rulați curl -fsS https://matrix.example.org/_matrix/client/versionsși inspectați răspunsul JSON.

Acest flag este semnalul de capabilitate al serverului; nu dovedește că o anumită versiune a aplicației este compatibilă sau că fiecare rută reverse-proxy este corectă. Folosește un client ale cărui note de lansare documentează suportul nativ pentru Sliding Sync și verifică calea solicitării în jurnalele sale sau în diagnosticele browserului/rețelei, atunci când sunt disponibile.

Cum activezi suportul nativ în Synapse?

Synapse 1.114 și versiunile ulterioare au activat implicit sincronizarea glisantă nativă. Dacă răspunsul versiunilor este deja true, de obicei nu există niciun serviciu separat de instalat și nicio nouă bază de date de sincronizare de creat. Evitați adăugarea unei configurații speculative doar pentru că ghidurile mai vechi descriu proxy-ul.

Dacă funcția este dezactivată explicit în configurația Synapse, verificați setarea de la experimental_features. În versiunile care utilizează steagul documentat, YAML-ul relevant este:

experimental_features:
  msc3575_enabled: true

Adăugați sau modificați această setare numai după ce verificați documentația de configurare pentru versiunea Synapse instalată. Faceți o copie de rezervă homeserver.yaml, păstrați restul experimental_featuresblocului existent și mențineți indentarea YAML consistentă. Validați fișierul folosind comanda de validare a configurației Synapse pentru instalarea dvs., apoi reporniți Synapse prin intermediul managerului de servicii sau al metodei de orchestrare a containerelor pe care o utilizați deja. Verificați din nou /_matrix/client/versionsulterior.

Dacă utilizați o versiune mai veche decât 1.114, planificați o actualizare Synapse utilizând instrucțiunile oficiale de actualizare. Citiți notele de lansare ulterioare, faceți o copie de rezervă a bazei de date și a fișierelor media/de configurare și urmați calea de actualizare acceptată pentru implementarea dvs. Nu combinați o actualizare a serverului principal, o rescriere a proxy-ului invers și o eliminare a proxy-ului vechi într-o singură modificare neverificată.

Proxy-ul invers are nevoie de o rută Sliding Sync specială?

De obicei nu. Native Sliding Sync folosește o rută API Matrix Client-Server sub /_matrix/client, așadar proxy-ul invers existent ar trebui să redirecționeze spațiul de nume API client Matrix către Synapse. Ghidul oficial pentru proxy-ul invers Synapse spune să redirecționați /_matrixși /_synapse/clientși pentru a păstra URI-ul cererii, în loc să îl canonizați sau să îl normalizați.

Verificați regulile proxy dacă /_matrix/client/versionsfuncționează, dar o aplicație compatibilă nu se poate sincroniza. Confirmați că solicitările ajung la /_matrix/client/unstable/org.matrix.simplified_msc3575/Synapse și nu sunt trimise către un proxy MSC3575 rămas, blocate de un firewall de aplicație web sau rescrise de o regulă de cale. Dacă Synapse rulează în spatele unui proxy, păstrați anteturile corecte forwarded-protocol și client-IP descrise în documentația Synapse.

Nu creați o org.matrix.msc3575.proxyintrare nouă /.well-known/matrix/clientpentru suport nativ. Acea cheie promovează API-ul proxy retras. Dacă ați adăugat-o anterior într-un fișier JSON static bine cunoscut sau în Synapse extra_well_known_client_content, eliminați doar proprietatea proxy moștenită după ce verificați dacă niciun client mai vechi necesar nu depinde de ea. Păstrați intacte informațiile normale de descoperire a serverului de acasă.

Cum ar trebui să migrezi o instalare proxy existentă?

1. Înregistrați versiunea curentă a Synapse, versiunile clientului, adresa URL a proxy-ului, rutele de proxy invers, baza de date și locațiile secrete ale vechiului proxy.
2. Faceți o copie de rezervă a bazei de date a serverului principal, a configurației și a bazei de date proxy. Păstrați aceste copii de rezervă până când au fost verificate autentificările și sincronizarea clienților nativi.
3. Actualizați Synapse prin calea de lansare documentată dacă este mai veche decât 1.114, apoi confirmați că indicatorul de capacitate nativă returnează true.
4. Actualizați clienții mobili la versiuni care acceptă nativ Simplified Sliding Sync. Urmați orice solicitare de migrare sau de reconectare în aplicație. Este posibil ca unele sesiuni existente să necesite conectarea din nou pentru a trece de la vechiul protocol.
5. Eliminați reclama proxy retrasă și direcționați calea API a clientului Matrix către Synapse. Reîncărcați proxy-ul invers și verificați configurația acestuia înainte de a-l aplica.
6. Testează mai întâi cu un cont și un dispozitiv mobil. Confirmă conectarea, încărcarea listei de camere, deschiderea unei camere criptate, trimiterea și primirea de mesaje și reconectarea după schimbarea rețelelor.
7. După ce testul reușește pentru clienții pe care îi asistați, opriți proxy-ul vechi. Păstrați copia de rezervă a bazei de date pentru o fereastră de revenire convenită; ștergeți datele vechi numai după ce confirmați că nu mai sunt necesare.

Baza de date proxy a păstrat starea de sincronizare pe partea proxy, în loc să înlocuiască istoricul camerei Synapse. Totuși, evitați să o ștergeți ca parte a migrării inițiale: aceasta oferă o referință pentru depanarea configurării vechi și o limită de revenire mai sigură în timp ce utilizatorii trec la sesiunile native.

Cum îți dai seama dacă încărcarea pe mobil s-a îmbunătățit?

Comparați același client, cont, dispozitiv și rețea înainte și după modificare, dacă aveți măsurători de referință fiabile. Înregistrați timpul de la deschiderea aplicației până la o listă de săli utilizabilă, dacă mesajele recente apar fără un cursor lung și dacă aplicația recuperează decalajul după o scurtă perioadă offline. Repetați comparația de mai multe ori; o singură lansare poate fi distorsionată de starea memoriei cache, condițiile rețelei sau o descărcare media mare.

Dacă clientul încă efectuează /syncsolicitări obișnuite și nu anunță sau nu încearcă niciodată suport nativ, verificați versiunea clientului și propria setare de sincronizare. Dacă solicită endpoint-ul simplificat, dar primește o eroare, inspectați jurnalele Synapse și reverse-proxy pentru solicitarea respectivă. Verificați starea bazei de date și încărcarea serverului dacă mulți utilizatori raportează o încărcare lentă. Sliding Sync poate reduce munca de sincronizare, dar nu poate compensa o bază de date supraîncărcată sau o solicitare API direcționată greșit.

Care sunt principalele opțiuni de configurare?

Surse și note de versiune

Depozitul proxy independent este arhivat. Implementarea nativă a Synapse datează de la Synapse 1.114. Echipa Matrix Spec Core a acceptat propunerea principală MSC4186 în iulie 2026, în timp ce extensiile aferente rămân separate. Synapse, clienții mobili și specificația Matrix continuă să evolueze, așa că verificați documentația și notele de lansare pentru versiunile exacte pe care le rulați.

• Note de configurare pentru depozitul proxy Sliding Sync arhivat și versiunea veche
• Matrix.org: Desființarea proxy-ului și migrarea către suport nativ
• Matrix.org: Sincronizare glisantă simplificată nativă în Synapse 1.114
• Jurnal de modificări Synapse: Suportul MSC4186 este activat în mod implicit în versiunea 1.114
• Documentația sinapselor: Rutare proxy inversă și gestionarea URI-urilor
• Matrix.org: Acceptarea MSC4186 și lucrările de extindere rămase