Karol „Zal” Zalewski

Jak już wcześniej planowałem, dziś zrezygnowałem z serwerów XMPP Google (działających w ramach Google Apps) na rzecz Hosted.IM, czyli darmowej usługi oferowanej przez firmę ProcessOne (twórców serwera ejabberd). Największą zaletą Hosted.IM jest to, iż w przeciwieństwie do Google Apps, ich implementacja XMPP trzyma się standardów. Podpinając domenę pod serwery ProcessOne nie trzeba się obawiać o własne zdrowie psychiczne. Jest jednak coś, co w przypadku Google sprawdza się naprawdę nieźle, a czego nie posiada Hosted.IM - webowy klient XMPP.

O webowym GTalku można mówić wiele, ale jedno jest pewne - ratuje skórę tam, gdzie nie ma innej możliwości dostępu do Sieci, niż przeglądarka WWW i dostęp do dwóch portów (80 i 443). W momencie, gdy nie korzystamy z usług Google można skorzystać z popularnych Meebo oraz Imo. Na stronie poświęconej XMPP można znaleźć jeszcze więcej webowych klientów. Ideałem byłoby znalezienie tego typu klienta o otwartym/wolnym kodzie źródłowym.

Stąd też moje pytanie - czy ktoś z Was miał już do czynienia z takimi rozwiązaniami i jest w stanie polecić z czystym sumieniem któryś z nich? Nie musi to być koniecznie rozwiązanie działające po stronie serwera. Hosted.IM obsługuje BOSH (XEP-0124).

Wczoraj postanowiłem zrobić porządek w moich kontaktach egzystujących w usłudze Google Contacts. W miejscu tym znajdowała się książka kontaktowa z telefonu (osobna zakładka), roster XMPP (kontakty z automagicznymi przełącznikami „obecny w GTalk”) oraz dużo kontaktowego miszmaszu, który nazbierał się przez kilka lat. Pomysł był prosty, zrobię backup kontaktów telefonicznych (poprzez webowy interfejs Google Contacts) oraz rostera XMPP (konsola XML w kliencie XMPP) i zacznę się bawić na wszystkie możliwe sposoby, a na koniec przywrócę wszystko z kopii zapasowych. Jak pomyślałem tak też zrobiłem. Jednak, gdy przyszedł moment przywracania wszystkiego z backupów pojawił się problem. Każda próba przywrócenia rostera na GTalku kończyła się następującym błędem:

Over maximum subscriptions per day

Z planowanych 100 kontaktów udało mi się wcisnąć na listę około 20. Miarka się przebrała. GTalk to jeden z gorszych hostingów XMPP. Źle reaguje na prośby o subskrypcję, często zrywa połączenia S2S, wykorzystuje niestandardowe rozwiązania, integracja z pocztą irytuje (pojawiające się „chat z ...” w interfejsie webowym GMaila) i jeszcze do tego istnieją pseudozabezpieczenia, które użytkownik sam musi odkryć (powyższe + antyflood). Zalety? Integracja z Google Apps for Your Domain, webowy klient XMPP z poziomu interfejsu webowego poczty oraz niski koszt utrzymania (usługa darmowa).

Tymczasowo podpiąłem domenę tmp.4zal.net pod serwery z Hosted.im. Jak tylko Marta wróci z Syberii również i główną domenę przenoszę na coś bardziej sensownego.

Duża część oprogramowania zapewniającego komunikację audio/wideo (np. Skype) udostępnia usługę umożliwiającą sprawdzenie poprawności konfiguracji klientów. Jest to najczęściej tzw. usługa echo - wszystko to, co bot otrzyma na wejściu przesyła z powrotem do nadawcy. W przypadku protokołu Jabber/XMPP i wideokonferencji sprawa jest nieco trudniejsza - samodzielnie należy sobie znaleźć bota, który taką opcję udostępnia. Gdyby ktoś takiej szukał to na dzień obecny istnieje i funkcjonuje m.in.:

echo@test.collabora.co.uk

Dopiero przy jego pomocy odkryłem, że z Jingle najlepiej radzi sobie Psi+ (w przeciwieństwie do Empathy i Pidgina). O przesyle wideo mogę obecnie zapomnieć - mam nadzieję, że nie na długo. Co ciekawe, wspomniany wyżej bot korzysta z Telepathy, a jego kod jest dostępny dla wszystkich zainteresowanych.

Nie wyobrażam sobie, abym do komunikacji typu IM mógł obecnie korzystać z czegokolwiek innego, niż XMPP. Standardy, w szczególności otwarte, są w komunikacji szczególnie ważne. Wyobraźcie sobie Internet bez e-maili, w którym to funkcjonalność poczty dostarczana byłaby przez różnego rodzaju niekompatybilne ze sobą nawzajem serwisy społecznościowe. Brr... Bądź, co bądź, w przypadku IM wybór jest prosty - XMPP. A co w przypadku, gdybym chciał prowadzić rozmowę głosową lub wideokonferencję?

Na pewno nie sięgnął bym po czarną, własnościową skrzynkę, jaką jest Skype. Owszem, to standard „de facto” jednak daleko mu do bycia otwartym. Do tej pory do rozmów głosowych wykorzystywałem sprzętową bramkę VoIP wykorzystującą protokół SIP (standard spisany w RFC i rozwijany przez IETF). W przypadku rozmów wideo naturalnym byłoby zatem sięgnięcie po klienta, który również korzysta z SIP i umożliwia transfer obrazu - np. po wieloplatformową Ekigę (Speex i Theora w roli kodeków). Pozostaje jeszcze co najmniej jedno rozwiązanie. Jingle!

Jingle to rozszerzenie XMPP (m.in. XEP-0166) stworzone przy współpracy z Google umożliwiające przesyłanie ww. danych między klientami XMPP. Problem polega jedynie na tym, że jest to jeszcze szkic standardu i różne jego implementacje bywają niekompatybilne ze sobą. Jakie klienty wspierają Jingle? Psi (tylko głos), Pidgin, Telepathy i kilka innych.

Pytanie tylko, co w praktyce lepiej się sprawdza. SIP, czy XMPP z Jinglem? Mam nadzieję sprawdzić to w ciągu najbliższych kilku tygodni.

Kilka godzin temu wydano kolejną wersję, tym razem 0.14, mojego ulubionego komunikatora XMPP, czyli Psi. Niestety, o ile poprzednia wersja wprowadziła naprawdę wiele zmian (m.in. rozmowy głosowe dzięki Jingle), tak większość prac dot. obecnego wydania dotyczy w głównej mierze detali. Kolorki w oknach, polecenia z poziomu CLI, eksterminacja bugów itp.

Cóż, bywa i tak.

Sporo osób zna zapewne Infobota dostępnego użytkownikom sieci GG. Proste i całkiem użyteczne narzędzie udostępniające z poziomu komunikatora użyteczne informacje (np. aktualny kurs walut, słownik ang-pol itp.). Ma ono jednak jedną, zasadniczą wadę - nie jest dostępne dla użytkowników XMPP. I tutaj pojawia się z pomocą Teabot.

Teabot to prosty, łatwy i przyjemny polski bot XMPP, którego kod udostępniony został na wolnej licencji GNU AGPL 3.0. Nie jest może jeszcze tak dojrzały, jak Infobot, ale posiada już całkiem bogatą funkcjonalność: słownika, pogodynki, narzędzia skracającego linki, czy też pokazującego status naszego konta XMPP () itp.

Ze swojej strony polecam się z nim przynajmniej zapoznać.

Wszystkie znaki na niebie i ziemi wskazują, że Facebook przymierza się do tego, aby udostępnić swój wewnętrzny chat na zewnątrz w formie XMPP. Można z tego wywnioskować, że z pewnością pojawi się wsparcie dla client-to-server - pytanie, czy i na s2s można liczyć?

Miło widzieć, że XMPP się upowszechnia. Teraz wystarczy poczekać na ruch ze strony lokalnych serwisów społecznościowych.

Do tej pory, do obsługi Jabbera/XMPP we własnej domenie korzystałem z Google Apps. Problem z Google Apps polega na tym, że niestety nie jest to usługa najwyższej jakości. Owszem, jest darmowa, stabilna i ładnie zintegrowana z resztą usług dostępnych w GAFYD, ale implementacja XMPP w wykonaniu Google pozostawia wiele do życzenia. Okazuje się jednak, że nie jestem skazany do korzystania z usług Google.

Serwis hosted.IM będący własnością firmy ProcessOne udostępnia możliwość darmowego wykorzystania ich serwerów do obsługi XMPP we własnej domenie. Całość oparta jest o ejabberd, więc nie trzeba martwić się o kwestię zgodności ze standardami XMPP. Haczyk? Usługa umożliwia podpięcie jedynie 10 użytkowników pod każdą z dodanych domen, większa ich liczba wymaga wykupienia płatnej opcji u ProcessOne.

Prowadzę obecnie testy na jednej z moich subdomen i planuję migrację z Google Apps do hosted.IM.

Zaczęło się niewinnie, od bliższego przyjrzenia się Empathy oraz Pidginowi i dostrzeżenia możliwości utworzenia kont „Bonjour” oraz „People nearby”. Szybki test i spojrzenie do Wikipedii. Okazuje się, że to leciwe już rozwiązanie (okolice 2005 roku), jest całkiem przydatne. Ten sposób komunikacji oparty o implementacje Zeroconf (np. wieloplatformową Bonjour, czy też linuksową Avahi), znany pierwotnie z iChata (MacOS), pozwala na rozmowę z innymi uczestnikami sieci lokalnej bez konieczności udziału serwera pośredniczącego np. XMPP. To bardzo miłe udogodnienie, szczególnie, kiedy mowa o uczelnianych laboratoriach komputerowych oraz sieciach bezprzewodowych tworzonych „ad hoc”.

Co więcej, od samego początku bazował on na Jabberze, a obecnie opisany został w XEP-0174. Dzięki temu znany z MacOS-a iChat, linuksowy Empathy, czy też wieloplatformowy Pidgin są w stanie komunikować się między sobą bez uczestnictwa centralnego serwera. Miło byłoby, gdyby i w Psi kiedyś się to pojawiło.

Dzięki doświadczeniu przeprowadzonemu przez Psychola (nie, nie kupię ci Lemmingów) wiemy już, że GTalk posiada pewne zabezpieczenie przed floodem. Po intensywnym wysyłaniu przez użytkownika wiadomości zawierających hiperłącza jest on ograniczany poprzez nałożenie blokady. Blokada ta jest krótkotrwała (przypuszczalnie około minuty) i objawia się tym, iż każda próba wysłania wiadomości zawierającej link kończy się niepowodzeniem (kod 503 - „service-unavailable”).

Co ciekawe, sam „feature” nigdzie nie jest opisany. Ciekaw jestem przed czym się jeszcze bronią i w jaki sposób.

Czyżby kolejny transport mógł spokojnie zniknąć z rostera? Co prawda, aby skorzystać z tlenowego konta nadal należy używać klienta zgodnego z Tlenem, ale S2S jest już aktywne i działa z serwerami XMPP.

Nie jest to może idealne rozwiązanie, ale podoba mi się - XMPP, jako język uniwersalny. To teraz jeszcze tylko GaduGadu?

Telefonia internetowa zyskała popularność już jakiś czas temu. Protokołów z nią związanych jest kilka, a do tych najpowszechniej stosowanych można zaliczyć otwarty SIP oraz własnościowy Skype. Na horyzoncie pojawił się również Jingle, protokół bezpośrednio związany z XMPP (m.in. XEP-166 oraz XEP-167), a rozwijany i wykorzystywany głównie przez Google w GTalku. Z racji swej otwartości (zarówno specyfikacji, jak i googlowej implementacji) powoli pojawia się również w takich komunikatorach, jak Psi, czy też Pidgin. Można więc przypuszczać, iż niedługo zyska na popularności.

I tutaj pojawia się pewien problem. Jak poradzić sobie taką różnorodnością protokołów? Rozwiązaniem problemu mogą być usługi konstruowane na wzór transportów znanych z XMPP, a zajmujące się tłumaczeniem jednego protokołu na drugi. Jednym z popularniejszych usługodawców w tym zakresie jest GTalk2VoIP, który pozwala na darmowe połączenia między użytkownikami Jingle oraz SIP-a. Co więcej, udostępnia również możliwość podpięcia całej usługi pod własną domenę. Dzięki temu ten sam adres może służyć do wymiany poczty oraz komunikacji poprzez XMPP, Jingle, czy też SIP. Jednak rozwiązanie takie ma oczywiście swoje wady. Przy czym najpoważniejszą najpoważniejszą według mnie jest naruszenie bezpieczeństwa komunikacji poprzez dodanie pośrednika.

Abstrahując od samej usługi dostarczanej przez serwis GTalk2VoIP, marzy mi się realizacja idei komunikacji zintegrowanej w przypadku typowych użytkowników komputera. Jeden adres kontaktowy, który nie tylko łączy w sobie wiele usług (poczta, IM, głos, wideo itp.) które przenikają się nawzajem, ale również wiele urządzeń (np. telefon, czy też komputer) tak, aby wyeliminować fizyczne bariery w komunikacji. Nim to jednak nastąpi mam nadzieję, że większa część klientów XMPP będzie sobie lepiej radziła z Jingle.

Psi 0.13 zostało wydane! Tak, jak wspomniałem, pojawiło się sporo nowości. Włącznie z rozmowami głosowymi.

Dnia 2009-07-10, czyli w miniony piątek, pojawiła się trzeci kandydat do wydania 0.13 komunikatora Psi. Jeżeli wszystko pójdzie dobrze to już za tydzień, czyli 19 lipca, pojawi się właściwe wydanie wersji 0.13.

Tak, jak już wspominałem, największą nowością w nowym Psi będzie możliwość prowadzenia rozmów głosowych m.in. z innymi użytkownikami Psi oraz GTalka (mowa o klientach, a nie o usłudze).

Opublikowano kolejną, czyli drugą wersję kandydującą do wydania 0.13 jednego z najbardziej popularnych komunikatorów bazujących na protokole Jabber/XMPP - Psi. Poprawiono błędy znalezione w Psi 0.13 RC1. Największe zmiany, które pojawią się w finalnej wersji, która miała zostać wydana 6 czerwca, to:

• możliwość prowadzenia rozmów głosowych przez użytkowników Windowsa, Mac OS X i Linuksa (Jingle RTP),
• podstawowa obsługa uchwytu XMPP URI,
• możliwość trwałego zaufania certyfikatom w trakcie łączenia się z serwerem,
• miniaturowy system poleceń (Ctrl+7 w oknie rozmowy) implementujący XEP-0146,
• poprawa wielu błędów.

Wydaje się, że rozmowy głosowe to największa i najważniejsza zmiana w stosunku do poprzednich wersji. Warto jednak zwrócić uwagę na wspomniany system poleceń, który w wersji pełnowymiarowej istnieje w Psi już od jakiegoś czasu (początki w wersji 0.11). Dlaczego może być przydatny? Pozwala on kontrolować innego klienta Psi podłączonego pod to samo konto (np. zostawiliśmy włączony komunikator w pracy, a obecnie jesteśmy w domu) i np.:

• zmienić status drugiego klienta (w tym priorytetu),
• pobrać nieprzeczytane wiadomości znajdujące się po stronie drugiego klienta,
• zmienić opcje klienta pod drugiej stronie (np. odtwarzanie dźwięków),
• zaakceptować przesył oczekujących po drugiej stronie plików,
• opuścić pokój rozmów,
• itp.

Psi obsługuje obecnie pierwsze trzy możliwości. Jest to zdecydowanie przydatna funkcjonalność.