Jabber/XMPP a niewidzialność

Stan “niewidzialny” oficjalnie nie istnieje w protokole Jabber/XMPP.
Powstało kiedyś rozszerzenie protokołu które obsługuje <presence type=”invisible” />, ale zostało ono w końcu odrzucone i wycofane. Powoduje zbyt wiele kłopotów.

Ta “niewidzialność” działa mn.w. tak:
- broadcastujesz (Twój klient) typ obecności “invisible”
- serwer odbiera go, rejestruje że jesteś niewidzialny, nie zrywa połączenia, ale zachowuje się od tego momentu tak jakbyś był rozłączony: wysyła wszystkim informację, że jesteś “offline”; na probe’y odpowiada że jesteś rozłączony

Transporty są normalnymi kontaktami w rosterze, a więc one też otrzymują od serwera informację, że się rozłączyłeś – a więc kończą Twoją sesję.

Aby to obejść, niektóre klienty wykorzystują cechę protokołu Jabber/XMPP, że pakiety <presence/> z atrybutem “to” (tzw. “directed presence”), czyli pakiety kierowane do konkretnego odbiorcy, a nie broadcastowane, nie są przetwarzane przez serwer i docierają do odbiorcy bez zmian. Więc obejście polega na tym, że zaraz po broadcaście <presence type=”invisible”/>, wysyłają taki sam pakiet po kolei do wszystkich transportów.
Niektóre transporty potrafią obsłużyć pakiet “invisible” i połączyć się w stanie niewidzialnym. Niektóre z nich (np. transport gg) opóźniają nawet rozłączenie, w oczekiwaniu na ewentualny pakiet “invisible”, co nie powoduje sekwencji obecny-rozłączony-niewidzialny tylko normalną obecny-niewidzialny.

Tak wygląda teoria. Jak widać dużo jest tutaj “niektóre”, “obejść”, “potrafić” itd. To już naprawdę dużo na przeciw tej implementacji niewidzialności.

A teraz dołóżmy praktykę.
Sieć nie gwarantuje kolejności dostarczania wiadomości. Pakiety mogą być przetwarzane równolegle, dostarczane z różną szybkościa, podlegać priorytetyzacji. Te możliwości pozostawiono do dyspozycji sieci.
Więc opieranie jakiejkolwiek funkcjonalności na kolejności pakietów jest podatne na błędy. Kolejny argument na niekorzyść tej implementacji niewidzialności.

Co więcej. Tak właśnie bardzo często się dzieje.
Klient wysyła broadcast “invisible” a następnie directed-invisible. Broadcast zaczyna być przetwarzany przez serwer i rozsyłany w postaci directed-offline do wszystkich na liście kontaktów. Równolegle przetwarzane directed-invisible docierają już do transportów. Po chwili serwer dochodzi do kontaktów transportów na liście kontaktów i wysyła im status “offline” na skutek broadcastowanego “invisible”. Przełączony już na niewidzialność transport otrzymuje informację, że klient jednak do końca się rozłączył, a więc sam się rozłącza.
„Ojej. Ta %#^@#@ niewidzialność ZNOWU nie działa. Do bani ten cały Jabber!”

Słowem podsumowania:
— Czy istnieje lepsze rozwiązanie?
— Tak, istnieje. Są nim privacy-listy, które są oficjalną częścią protokołu XMPP. Jest nawet JEP, który opisuje standardowy sposób zaimplementowania niewidzialności za pomocą privacy-list.

Szkoda tylko, że większość klientów obsługuje starą, niedobrą niewidzialność, zamiast privacy-list.

Osobną kwestią jest dla mnie dyskusyjność samej niewidzialności. Skąd to zakłamanie w ludziach? Jeśli daję komuś autoryzację na moją obecnosć (skrót myślowy na informację o mojej obecności), to chyba dlatego, że chcę aby wiedział kiedy jestem, a kiedy nie, jaki mam status itd. Jeśli nie chcę, żeby ktoś wiedział kiedy jestem, to mu po prostu autoryzacji nie daję. Nie potrzebuję go okłamywać i się ukrywać. Oczywiście czasami chcę sterować ilością i rodzajem informacji otrzymywanej przez moje kontakty — mogę to zrobić za pomocą privacy-list. Jednak gdy chcę żeby ktoś nie wiedział o mnie nic, to mu po prostu odbieram autoryzację. Proste.