Dotaz: Instant Messaging - pouzivate JABBER?

[petrfm]

Ahoj,

je tady nekdo, kdo pouziva Jabber? Nebo pres co komunikujete? Zatim vyuzivam Gtalk a dale mam na svem serveru Prosody jako Jabber server. Pripojuji se k tomu z Psi na WIN a Yaxim na androidu. Rad bych se Gtalku zbavil a pouzival jen svuj server s nejakymi transporty, abych mel vsechno pod jednim uctem (Gtalk, ICQ i Jabber), ale mam s tim Jabberem problemy.

Pouzivam tri klienty (Notebook, PC a Mobil) a dost mi chybi ta googlovska funkce, ze muzu chatovat z mobilu, PC, proste odkudkoliv, vsude vidim historii a offline zpravy.

Jabber by mel umoznovat preposilat kopie zprav na jine zarizeni, ale nefunguje mi to. Kdyz zapomenu shodit klienta v praci (Psi) ktery ma vyssi prioritu, nez mobil, protoze psani pres mobil je pomalejsi, tak kdyz mi nekdo napise, i kdyz mam mobil ONLINE, tak to nezjistim, pokud se nepripojim na remote desktop.

Chtelo by to reseni, ktere by na serveru archivovalo neprectene zpravy a ty to zobrazilo na klientovi, ktery si je zobrazi jako posledni. Defakto by to mohlo fungovat jako IMAP. Jenomze nevim, zda tohle prosody umi - asi ne a nejsem si jisty, zda to bude umet jiny server.

Jak resite instant messaging, pokud chcete mit svuj server, aby se vam ve zpravach nehrabal google, nebo nekdo jiny?

P.

Odpovědi

[Josef Kufner]

Jabber používám, mám ho přes transporty napojený na ostatní služby, ale moc spokojený nejsem.

To co popisuješ je popsáno v různých XEP, ale snad žádný klient to pořádně neimplementuje. Většina jich ani neumí potvrzovat doručení zpráv, takže když chcípne spojení, tak je server vesele posílá jen tak na prázdno a nikdo je už nenajde.

Problémy s několika zařízeními lze řešit nastavením všude stejného resource, pak poslední připojený klient odpojí ty ostatní. Ale jednou doručené zprávy už na jiném zařízení nepřečteš.

A nějaká opensource alternativa pokud vím neexistuje. Byl bych docela rád, kdyby si někdo vzal XMPP do parády a učinil ho použitelným. On v zásadě není špatný, jen by pár XEPů mělo být poviných.

[petrfm]

Ano, presne jak pises... Kdyz se klient odpoji vypadkem spojeni, muzou zpravy chodit, ale pritom se ztracet v cerne dire. Odesilatel nepozna, ze zprava nebyla dorucena. Tohle mne taky neskutecne se...

Jak jsem byl z jabberu nadseny, tak nadseni rychle vyprchalo. Dnes by to chtelo neco, co by melo i nejake webove GUI s moznosti prochazet historii zprav - neco jako je Gmail a Gtalk v nem. Prijde mi, ze neexistuje zadny rozumny IM - skoro se mi jevi jako nejlepsi komunikovat pres email s IMAPem

Pritom by jen stacilo vymyslet neco, co by oznamovalo pouze nove prichozi zpravy a umoznovalo na ne ihned odepisovat, jinak by to zachovalo princip emailu. Jabber koncept mi prijde neskutecne komplikovany.

[Josef Kufner]

XEP-0136: Message Archiving. Když se ti to povede rozchodit, tak budeš mít webové prohlížítko histori a možná i najdeš klienta, který to umí přímo.

[luky]

Ano, presne jak pises... Kdyz se klient odpoji vypadkem spojeni, muzou zpravy chodit, ale pritom se ztracet v cerne dire. Odesilatel nepozna, ze zprava nebyla dorucena. Tohle mne taky neskutecne se...

Vzdyt to bezi pres TCP - odesilatel si muzes precist ze socketu, kolik dat bylo ACKnuto.

[Josef Kufner]

TCP negarantuje doručení dat při ztrátě spojení. Garantuje ho jen při korektně uzavřeném spojení. Tento drobný detail má velmi vážné důsledky. Tedy pokud se spojení rozpadne na nižší vrstvě, TCP to zjistí až po timeoutu a vše, co mezitím je odesláno, je ztraceno. Navíc úspěch zápisu do socketu znamená, že se data povedlo uložit do odesílacího bufferu, ale neříká to vůbec nic o jejich doručení, ba ani odeslání.

TCP je fajn v tom, že garantuje správné pořadí dat. Tedy pokud něco dorazí, tak dorazilo i vše předtím. To třeba UDP nedělá, tam se pořadí zpráv může na cestě změnit.

Naneštěstí si toto mnoho lidí neuvědomuje a pak vznikají věci jako Jabber.

[pavlix]

Naštěstí si toto mnoho lidí uvědomuje a tak se to už před mnoha lety řešilo a tak si stačí pohlídat podporu ACKů v implementacích. Za hop-to-hop acky a pingy v jabberu jsem bojoval někdy v roce 2008.

[Josef Kufner]

Jo, už se to trošku zlepšilo. Ale i tak zdaleka ne všichni klienti podporují XEP-0198 a takový XEP-0313 je teprve žhavá novinka.

[pavlix]

Vzdyt to bezi pres TCP - odesilatel si muzes precist ze socketu, kolik dat bylo ACKnuto.

A jak konkrétně? Už jsem o tom s lidmi diskutoval dříve a popravdě teď nemůžu najít ani jako to udělat na Linuxu, natož všude jinde nebo dokonce v obecných vrstvách pro síťování. Co se tak dívám, tak dostupná API prezentují TCP víceméně jako dvojici streamů, přičemž jabber je explicitně postavený na zprávách a ty taky umožňuje potvrzovat.

Teoreticky by bylo možné bufferovat zprávy a nechat si od operačního systému zasílat (pomocí monitorování souborového deskriptoru) o potvrzeném sekvenčním čísle a zároveň si udržovat přehled o aktuálním sekvenčním čísle a tím pádem o rozsahu sekvenčních čísel pro danou bufferovanou zprávu. Ale takové řešení jsem neviděl a nejsem si jistý, zda to bez úpravy kernelu vůbec lze.

[tom]

Vzdyt to bezi pres TCP - odesilatel si muzes precist ze socketu, kolik dat bylo ACKnuto.

A jak konkrétně?

getsockopt(fd, SOL_TCP, TCP_INFO, &info, sizeof info);

[pavlix]

Skutečně jsem si dal práci s hledáním, neúspěšně, takže díky! Nicméně z hlediska diskuze je to jen první krok. Jde nějak zajistit, abych se dozvěděl o změně (tedy nechat si třeba přes epoll propagovat informaci o tom, že přišel ACK a mám k dispozici nové ackované sekvenční číslo) nebo je potřeba se čas od času doptat?

U klienta by mi šlo nejen o to, aby při ztrátě spojení věděl, co všechno bylo neodeslané, ale také aby uměl uživatele informovat u každé odeslané zprávy, že se dostala alespoň k serveru, ať už změnou barvy nebo třeba tím, že do té doby zprávu vůbec nezobrazí. Samozřejmě bych z mnoha důvodů byl rád, aby se aplikace pokud možno vůbec neprobouzela, pokud pro ni žádná nová data nejsou.

Pak by mě rovněž zajímalo, jestli je toto v nějaké formě dostupné na všech dnes běžných operačních systémech. Trochu problém bude s různými mezivrstvami, které takovéto detaily vůbec neřeší, ale to se holt nedá nic dělat.

Nakonec by mě zajímalo, jestli existuje alespoň jeden jabber klient testovatelný na linuxu, který by toto podporoval (alespoň ve vývojové nebo patchované verzi). Podle mě by to nemusela být špatná alternativa pro případ, kdy druhá strana nepodporuje aplikační acky.

[tom]

Skutečně jsem si dal práci s hledáním, neúspěšně, takže díky! Nicméně z hlediska diskuze je to jen první krok.

Pokud Vas zajima systemove programovani, mel byste si precist hlavicky z kernelu. Spousta veci v manualovych strankach chybi.

Jde nějak zajistit, abych se dozvěděl o změně (tedy nechat si třeba přes epoll propagovat informaci o tom, že přišel ACK a mám k dispozici nové ackované sekvenční číslo) nebo je potřeba se čas od času doptat?

Root si to muze zaridit pres netfilter, ale v tomto pripade mi to prijde zbytecne.

U klienta by mi šlo nejen o to, aby při ztrátě spojení věděl, co všechno bylo neodeslané, ale také aby uměl uživatele informovat u každé odeslané zprávy, že se dostala alespoň k serveru, ať už změnou barvy nebo třeba tím, že do té doby zprávu vůbec nezobrazí. Samozřejmě bych z mnoha důvodů byl rád, aby se aplikace pokud možno vůbec neprobouzela, pokud pro ni žádná nová data nejsou.

Jak klient tak server si mohou hodnotu precist po tom, co odeslou a nebo prijmou zpravu a nebo se spojeni prerusi. Delat to casteji nema moc smysl, protoze jediny rozdil by byl, kdy se uvolni pamet, nikoliv vsak v maximalnim mozstvi potrebne pameti, ktere bude vzhledem k velikosti ostatnich buferu v kernelu radove desitky kB (pote bude send blokovat a nebo selze).

Pak by mě rovněž zajímalo, jestli je toto v nějaké formě dostupné na všech dnes běžných operačních systémech. Trochu problém bude s různými mezivrstvami, které takovéto detaily vůbec neřeší, ale to se holt nedá nic dělat.

Je to v Linuxu a ve FreeBSD. S nicim jinym nepracuji, takze jsem se o to nezajimal.

Nakonec by mě zajímalo, jestli existuje alespoň jeden jabber klient testovatelný na linuxu, který by toto podporoval (alespoň ve vývojové nebo patchované verzi). Podle mě by to nemusela být špatná alternativa pro případ, kdy druhá strana nepodporuje aplikační acky.

Kopete v KDE3 detekuje "ztracenou" TCP zpravu.

[pavlix]

Pokud Vas zajima systemove programovani, mel byste si precist hlavicky z kernelu. Spousta veci v manualovych strankach chybi.

To bude jistě zajímavé čtení, ale mám v zásobě ještě dost jiné literatury ;).

Root si to muze zaridit pres netfilter, ale v tomto pripade mi to prijde zbytecne.

V tomto případě se především jedá o uživatelskou aplikaci.

Jak klient tak server si mohou hodnotu precist po tom, co odeslou a nebo prijmou zpravu a nebo se spojeni prerusi.

Klient si může hodnotu přečíst ve chvíli, kdy úspěšně odešle data kernelu, jenže v tu chvíli je mu tak nějak prd platná, pokud nelze zaručit, že kernel odešle data po síti před vrácením kontroly aplikaci.

Delat to casteji nema moc smysl

Klient to nepotřebuje dělat častěji, nýbrž ve chvíli, kdy přijde ACK. Pokud přijde s daty, tak ok, o tom se dozvíme, pokud by přišel samostatný ACK, tak asi smůla, ne? A bavíme se o TCP, které zadržuje data často a při problémech se sítí především, ne?

Je to v Linuxu a ve FreeBSD. S nicim jinym nepracuji, takze jsem se o to nezajimal.

Díky, zajímalo mě to i kvůlu univerzalitě.

Kopete v KDE3 detekuje "ztracenou" TCP zpravu.

Jen pro zajímavost, jak na takovou situaci reaguje?

[tom]

Root si to muze zaridit pres netfilter, ale v tomto pripade mi to prijde zbytecne.

V tomto případě se především jedá o uživatelskou aplikaci.

Tak napriklad chromium taky pouziva pomocnou suid binarku, takze se to muze resit podobne, ale jak jsem jiz napsal, prijde mi to zbytecne.

Jak klient tak server si mohou hodnotu precist po tom, co odeslou a nebo prijmou zpravu a nebo se spojeni prerusi.

Klient si může hodnotu přečíst ve chvíli, kdy úspěšně odešle data kernelu, jenže v tu chvíli je mu tak nějak prd platná, pokud nelze zaručit, že kernel odešle data po síti před vrácením kontroly aplikaci.

Delat to casteji nema moc smysl

Klient to nepotřebuje dělat častěji, nýbrž ve chvíli, kdy přijde ACK. Pokud přijde s daty, tak ok, o tom se dozvíme, pokud by přišel samostatný ACK, tak asi smůla, ne? A bavíme se o TCP, které zadržuje data často a při problémech se sítí především, ne?

Zrejme jste me nepochopil - program si zpravu drzi v pameti do doby, nez je jasne, ze byla druhou stranou prijata a nebo neprijata. Socket ale kontroluje jen pri nejake jine operaci s nim. Timto zpusobem se nezmeni pocet probuzeni procesu a spotrebovana pamet se zvysi maximalne o velikost odesilaciho zasobniku, coz neni problem udrzet pro spousty spojeni klidne i delsi dobu.

Kopete v KDE3 detekuje "ztracenou" TCP zpravu.

Jen pro zajímavost, jak na takovou situaci reaguje?

Prijde falesna zprava od puvodniho prijemce, ze zprava nebyla dorucena.

[pavlix]

Zrejme jste me nepochopil

To je sice zajímavá teorie, na druhou mám obavu, že je to přesně naopak. Vrátím se tedy k tomu textu, na který to měla být odpověď.

U klienta by mi šlo nejen o to, aby při ztrátě spojení věděl, co všechno bylo neodeslané, ale také aby uměl uživatele informovat u každé odeslané zprávy, že se dostala alespoň k serveru, ať už změnou barvy nebo třeba tím, že do té doby zprávu vůbec nezobrazí. Samozřejmě bych z mnoha důvodů byl rád, aby se aplikace pokud možno vůbec neprobouzela, pokud pro ni žádná nová data nejsou.

Tato funkcionalita přímo závisí na tom, že se o ACKu dozvím plus mínus ve chvíli, kdy přijde. U piggyback ACKů lze detekovat příchod ACKu při detekci přijímaných dat, protože ta epoll() probudí. Ale samostatné ACKy, pokud to chápu správně, epoll() nepřeruší, tudíž tato metoda vyžaduje, aby druhá strana jako odpověď na zprávu poslala alespoň něco (i kdyby white space), a to mi přijde značně neelegantní, stejně jako mi přijde neelegantní řešit to nějakou suid binárkou a bůhvíjakým rozhraním.

[Sten]

ejabberd umí posílat zprávy na všechny klienty, pokud mají stejnou prioritu. Posílání zpráv na klienty s nižší prioritou odporuje XEP, ale pro ejabberd existuje modul, který i tohle dělá.

Proti hrabání se ve zprávách funguje spolehlivě OTR.

[pavlix]

Ono je to s těmi prioritami takové řešení šité horkou jehlou, ve skutečnosti by mělo být na uživateli, jak chce být kontaktován a druhá strana by to měla pokud možno respektovat, ale pak je spousta protichůdných požadavků, jako zda má konverzace probíhat přímo nebo přes server, tak je těžké v něčem takovém najít konsensus.

Podle mě je nejlepší cestou napsat si vlastní XEP, který bude fungovat přesně podle představ, ale udělat ho tak, aby nekolidoval s obecnými zvyklostmi na jabberu. V rámci uživatelů stejného software to pak bude fungovat na 100% a pokud si to lidé oblíbí, budou to vyžadovat i u ostatního software.

[Josef Kufner]

Pak je ale docela obtížné najít klienta, který podporuje všechny požadované XEPy. Takže by bylo fajn, kdyby si vŠichni vystačili s vypnutím/zapnutím XEP-0280 (Message Carbons; rozesílání kopií na všechny klienty).

[petrfm]

Já s tím moc nelaboroval, ale tenhle XEP může za to, že mi zpráva přijde na všechny tři klienty, kteří mají stejnou prioritu? Mám to totiž od začátku na prosody zapnuté a takhle to funguje. Bez toho by se to chovalo jak? Když mají všichni klienti stejnou prioritu? Nepřišlo by to náhodou taky na všechny?

A druhá věc - je celkem nepříjemné, když mám v práci zapnutého klienta. Přijdu domů a zapnu klienta na NB. Ale v práci mezi tím bliká nová zpráva. Je šance se k ní dostat? Prostě načíst všechny "nepřečtené" zprávy? Tohle by asi měl dělat ten XEP s Historií, že? To je taky věc, která mě dost sejří - musím se pak přes RDP připojovat do práce a kontrolovat klienta přes desktop, jestli někdo něco nepsal - no pakárna.

[Josef Kufner]

Jo, chce to oba XEPy.

Mesage Carbons rozesílají i odeslané zprávy. Tedy na tvém druhém klientu jsou zprávy odeslané z prvního. Pokud máš dva počítače online, můžeš mezi nimi libovolně přecházet.

Message Archive Management je pak na to, aby si nově připojený klient mohl stáhnout už dříve doručené zprávy.

[petrfm]

Zjistil jsem, ze se tomu da trochu pomoct. Nastavil jsem si vsechny tri klienty na prioritu 0. Funguje to tak, ze kdyz s nekym zacnu chat, tak na dalsi zarizeni se prestane posilat co mi pise. Takze kdyz jsem klasicky online, nekdo napise, vyskoci mi notifikace na vsech pripojenych klientech. Kdyz zacnu komunikovat na NB, tak mi dalsi zpravy na mobil a pc uz nechodi.

Tohle je OK. Problem nastava, kdyz od NB odejdu a chtel bych pokracovat treba na mobilu, nebo PC. Tak to nejde udelat automaticky. Odesilatel by musel UKONCIT CHAT a zacit novy, to by mi zase poslalo notifikaci na mobil a PC a mohl bych pokracovat v komunikaci.

Zjistil jsem, ze staci, kdyz JA na mobilu zvolim - STAV - a dam ok. Proste udelam zmenu stavu na stejny, jaky jsem mel. Tim se jakoby ohlasim a dalsi zprava mi zase prijde i na mobil.

To je fajn, ale neslo by nejak udelat, aby se tenhle stav menil treba s tim, ze aktivuju obrazovku? Nebo treba ze na NB, nebo PC pohnu mysi? To jsem nezkousel, jestli ma vliv, ale primarni je, aby mi takhle fungoval YAXIM na mobilu. Protoze casto mi nekdo pise, kdyz jsem u PC, ale ja pak necham klienta bezet a on mi pise za hodinu, ale veskere zpravy mi prijdou na PC, u ktereho uz nejsem, pritom mobil mam online, ale dokud rucne "neohlasim" stav, tak je pro dany kontakt mrtvy.

Jak na to? Takhle je ta komunikace pekelne nespolehliva, horsi, nez posilat postovniho holuba

[petrfm]

Tak jeste update - kdyz se na mobilu zmeni stav Online / pryc tak se tim mobil ohlasi a notifikace zase zacnou chodit, takze je to SKORO ok Uz jen zjistit, proc se mi yaxim pravidelne sekne vzdycky pres noc a proc prestava chodit pri zmene pripojeni wifi / 3G a bude to fajn.

Uz jen vyresit, aby v pripade, ze mi vypadne v rozjete komunikaci spojeni, tak aby se zpravy budto dorucily pozdeji, nebo se odesilateli zobrazilo, ze je nejaky problem. Tohle bude ale dost problem v pripade transportu treba ICQ - neumim si predstavit, jak by ten transport zasilal zpet na ICQ konto info o tom, ze zpravu se nepodarilo dorucit.

[Andrej]

Na instant messaging používám (výhradně) Jabber. Google Talk je naštěstí zatím ochotný komunikovat i s jinými Jabber servery, takže s mým Jabber účtem (který nijak nezávisí na službách Googlu) můžu komunikovat i s lidmi na Google Talku. To tedy znamená, že pro Google Talk není potřeba žádný transport.

Synchronizace offline zpráv nejspíš někde v XMPP specifikaci existuje, ale nevím bohužel o klientovi, který by něco takového uměl. Klienti mají možnost ukládat si na serveru nějaká data, ale příliš toho nevyužívají.

Klient v práci by měl automaticky snížit svou prioritu, když jsi away, unavailable nebo offline. Pak by měly zprávy přednostně chodit na mobil. Naopak online priorita toho klienta v práci by měla být vyšší než priorita mobilu. Tím by se mělo docílit požadovaného chování. Jiná situace ovšem je, když někdo vydoluje staré chatovací okno, do kterého psal ještě na ten počítač v práci. To se pak zprávy často pošlou na tentýž zdroj, i když se priorita změnila. V Psi je tohle vyřešeno poměrně flexibilně možností vybrat explicitně zdroj, na který se má zpráva poslat. (Pak je tam vždy ještě možnost poslat zprávu prostě uživateli bez udání zdroje, což znamená, že se pak doručování řídí podle priority zdrojů.)

Já používám jako Jabber server Openfire. Ten má možnost archivovat zprávy, ale nevím, jak to (ne)funguje, protože jsem archivování nikdy neměl zapnuté. Předpokládám, že to taky vyžaduje, aby se klient dokázal ke službě „Monitoring“ připojit a historii z ní přečíst. Zapnul jsem si tedy příslušný plugin v Openfire a vypadá to, že dokonce i funguje, ale zatím se mi nezdá, že by některý z klientů tuhle službu rozumně podporoval.

[Josef Kufner]

Zrovna jsem trošku prozkoumával situaci a je celkem smutná. Starý XEP-0136 (Message Archiving) se nechytil a XEP-0313 (Message Archive Management) ještě nedozrál. Oba mají společné to, že nemají podporu skoro nikde.

[Andrej]

Což nejspíš vysvětluje, proč mi to archivování s žádným klientem nefunguje a proč jediný přístup k němu je webové rozhraní OpenFire, které samozřejmě nemá s XMPP nic společného. To je vskutku smutné.

[petrfm]

Presne tak. Smutna je i situace okolo Gtalku, protoze dnes vetsina lidi, co ma android telefon upgradovala na Hangouts a tim jejich puvodni jabber Gtalk ztratil moznost komunikovat s klasickym jabberem. Proto uz zacina byt jabber nepouzitelny i ke komunikaci smerem ke "Gtalk" kontaktum.

Proste jsem procitl a zjistil, ze pokud nechci pouzivat Facebook, nebo Google, nemam jinou moznost, nez se vratit o 10 let zpatky ke klasickemu emailu. To je ZATIM jediny komunikacni kanal, ktery je otevreny, muzu si jej provozovat na svem serveru, ma jej KAZDY a hlavne, je SPOLEHLIVY.

Rekl bych, je jabber, jak byl vymyslen je proste k nicemu. Vsechny zpravy jdou stejne pres nejaky server, proto nechapu, proc to nefunguje stylem, ze se veskere zpravy na ten server ukladaji a v klientovi nelze zvolit, zda je mazat / ponechat - defakto jako email. Bylo by to spolehlive, jednoduche a udelat klienta pro vsechny OS by nebyl zadny velky problem.

Pouzivat Facebook / Hangouts nebo jine kramy, at uz se sifrovanim, je pro mne neakceptovatelne - sifrovani je kratkodoba vec. Do budoucna nezarucuje soukromi a proto pokud mozno, nechci, aby vsechny zpravy zustavaly na serverech facebooku, apod.

 

P.S. jeste k tem snaham ucinit Jabber spolehlivym - je sice krasne, ze po uprave kernelu a kdo vi ceho, dokazu zjistit, ze se zprava nedorucila - ALE, co je mi to platne v pripade transportu? Kdyz mi napr. uzivatel zasle zpravu na ICQ, tak by se musely upravit i transporty, aby zpet zaslaly zpravu ve smyslu : zprava nebyla dorucena.

Neni jednodussi vymyslet novou opensource komunikacni platformu? Na bazi klient / server, kde by v pripade neuspechu zustaly zpravy ulozene na serveru? Proste okopirovat Gtalk.

[pavlix]

Neni jednodussi vymyslet novou opensource komunikacni platformu? Na bazi klient / server, kde by v pripade neuspechu zustaly zpravy ulozene na serveru? Proste okopirovat Gtalk.

Jakože máme IRC, to se nám nelíbilo, vyrobíme jabber. Máme jabber, ten se nám nelíbí, vyrobíme si další. Ono je to celé tak trochu pitomost, ve skutečnosti by bylo mnohem lepší definovat, co všechno taková síť má umět, jak se toho konceptuálně docílí. Pak je v podstatě jedno, zda se to implementuje rozšířením stávajícího protokolu nebo vytvořením nového, nebo dokonce oběma způsoby.

Podstatné na tom celém je, aby primárním účelem software nebylo poskytovat protokol, ale službu. Pak může službu poskytovat pomocí jednoho protokolu, na kterém se většina shodne, ale klidně i pomocí několika různých, třeba i redundantních protokolů, pokud se většina neshodne.

[petrfm]

Tak mne napada, proc by to defakto nemohlo frcet na klasickem emailu? Vzdyt imap je super - jen by ho to chtelo upravit tak, aby komunikace fungovala trochu vice realtime. Email ma vse co potrebuji - historii, offline zpravy, dokonce prectene/neprectene, podporuje i zasilani potvrzeni o precteni.

Jedine, co tedy chybi, je klient, ktery by zpravy zapisoval v okne pod sebe a pak ochrana proti spamu - zde by se jednoduse dalo definovat, ze prijimam IM zpravy jen od kontaktu, ktere mam v seznamu.

No reknete, neni to lepsi, nez stavet nejaky dalsi protokol? Navic, ten, kdo nema zadneho klienta, tomu by prisla moje IM zprava klasicky do emailu - bylo by to absolutne multiplatformni.

SERVERY - kazdy si muze vybrat, zda pouzije hostovany server, nebo vlastni. Lze aplikovat sifrovani, zasilat prilohy - vsechno je uz definovane, hotove a funkcni. Jen ti klienti nejsou vhodni pro instant messaging. Tak proc neupravit klienty?

Defakto by se IM zpravy od tech klasickych mohly lisit jen nejakym autorizacnim retezcem v predmetu emailu. To by mohlo resit i problem se spamem - nejsem v tom kovany, ale urcite by se dalo nejak zaridit, aby clovek dle sveho verejneho certifikatu dokazal podepsat svoji IM zpravu a ten podpis napasovat do predmetu zpravy. Podvrzenou zpravu by zahodil bud uz server, nebo klient.

Zprava bez retezce v predmetu by dorazila klasicky jako email - a postovni klient by si ji nevsimal.

 

A ted mi reknete, jake ma tohle reseni problem, proc by to neslo udelat a nemohlo se ujmout? Misto pouzivani nejakych debilit tapy facebook, gtalk, whatsapp, viber a jinych.

P.

[petrfm]

Jedina vec, ktera mne napada je, ze email neumi, jak to nazvat - PUSH notifikaci? Proste to neni otevrene tcp spojeni, ale musim se dotazovat. Tohle by slo ale urcite nejak resit - at uz otevrenym spojenim na vyhrazenem portu, ktere by slouzilo JEN k te notifikaci - a bylo by to dobrovolne, nebo by se nejak automaticky nastavovala doba refreshe - pri komunikaci by byl treba kazde 2 sekundy, pri neaktivite (away) treba jen kazdou minutu. Stejne jako to vlastne dela postovni klient uz dnes.

[Josef Kufner]

Tohle lze udělat už dnes pomocí XEP-0198 (Stream Management). Klient se normálně připojí a prostě zavře socket. Pak může chvilku spát a když si usmyslí, že je načase kouknout, co je nového, tak socket znovu otevře a session naváže. Z pohledu okolního světa je stále online a XML stream se hromadí na serveru. Jen to chce přizvednout timeout na serveru, těch defaultních 5 minut (ejabberd 14.07) by mohlo být málo.

[vlastik]

http://en.wikipedia.org/wiki/IMAP_IDLE

[petr_fm]

Pecka, takze tohle je vlastne vyreseno. Tim padem nevidim jediny duvod, proc nepouzit fungujici servery a neupravit jen soft, aby lepe odpovidal potrebam IM. Jde vlastne jen o ergonomii a rozsirene moznosti notifikace. Kdyz chci prijimat IM, neznamena to totiz, ze chci kazdych 5 minut mazat SPAMy a nechat se otravovat reklamnimi nabidkami v emailu. Cili takovy klient by mel umoznovat filtrovat jen IM komunikaci.

[pavlix]

Tim padem nevidim jediny duvod, proc nepouzit fungujici servery a neupravit jen soft, aby lepe odpovidal potrebam IM.

Nevidím důvod, proč jsi ještě neukázal výsledky.

[petr_fm]

Protoze nejsem programator. Specializuju se na HW a jednocipy, ne na PC SW. A zatim o tom diskutuji a prijimam podnety a nazory. Je to zatim jen napad. Pokud mi ho nikdo nevyvrati, pak to sepisu a prednesu tvurcum klientskych aplikaci pro email, jako podnet na vylepseni. Ale sam to programovat nezvladnu. Nemyslim si, ze by clovek, ktery ma napad, musel nutne stat za jeho realizaci. Ano, taky znam spoustu kecalu, ale taky znam hodne schopnych lidi, kterym zase chybi napady.

Ja z toho nechci delat komercni projekt. Chci vymyslet neco, co pouze mi a dalsim lidem ve snazsi komunikaci. A neocekavam od teto diskuze zdrojove kody, ale podnety a pripominky.

Napada mne, ze jsem videl i rozsireni pro FF, coby jednoduche emailove klienty. To by taky nemuselo byt spatne - upravit ho pro prochazeni danych slozek imapu a chatovani s danymi kontakty v prepinatelnych zalozkach. FF je multiplatformni, odpadl by tedy Thunderbird, ktery je na ustupu. Pro WIN / Linux a MacOS by tedy stacil FF a pro pristup pres web Roundcube. Roundcube by resil i webovou historii az do ja nevim jake hloubky. Vtip je taky v tom, ze vetsina emailovych klientu ma VYMAKANE vyhledavani, takze by se dalo ve zpravach dobre hledat (nepouzivam to porad, ale obcas se hodi neco vyhledat, treba odkaz, nebo nejake dulezite udaje)

[petr_fm]

Tohle tema jsem nezakladal s myslenkou, ze se budu uchylovat k presunu IM na EMAIL, ale proste po tom, co jsem byl utvrzen, ze Jabber, ktery mimochodem uz skoro rok intenzivne pouzivam,ma skutecne chyby, se kterymi jsem se setkal, tak se snazim prijit na nejake reseni. Doufat v napravu jabberu mi prijde dost chabe, navic, jak uz jsem zminil, po zruseni podpory ze strany googlu se mi prestava jabber libit jeste vice. Museli by se navic upravit klienti pro vsechny platformy, cemuz proste neverim, spis si myslim, ze lidi postupne z jabberu odejdou. Ale protoze hodne lidi pouziva adresu ve tvaru email@domena.cz (vcetne mne) tak neni problem prejit na email.

[pavlix]

Popravdě řečeno jsem kdysi snil o konvergovaném řešení taky, protože protokoly jsou z uživatelského hlediska nezajímavé. Problém je v tom, že jak jabber, tak e-mail vykazují značnou stagnaci ve vývoji. Je spousta věcí, o kterých se ví, že jsou na obou špatně, ale jejich náprava buď nepřichází, přichází pomalu, nebo nepřichází univerzálně a je dostupná jen specifické části uživatelů.

Pro mě je jabber stejně jako SIP a e-mail prostě součástí internetu. Nepoužívám XMPP, používám instant messaging, kde je kontaktem mé uživatelské jméno a doména, ze které jde pomocí DNS zjistit, jaký server se stará o jaké služby či protokoly, podle architektury dané služby. V roli uživatele bych vůbec nemusel poznat, jestli ke komunikaci se serverem používám XMPP, SIP nebo jiný protokol a stejně tak jaký protokol používá můj server při komunikaci s cizím serverem.

Rozdíl mezi instant messagingem a elektronickou poštou není v použitých protokolech, ale ve způsobu užívání.

[petr_fm]

Asi mas pravdu. Prusvih je, ze dneska stale vetsina lidi nema vlastni domenu a pod pojmem email pro ne je neco ve tvaru fanda@seznam-cz. Takze nepochopi, co to po nich chces. A zavadet neco, jako virtualni identitu, jeste navic treba potuplovanou nejakym certifikat, toho se zase bojim ja. Nechci mit sve jednoznacne cislo, defakto carovy kod na cele. Vyrostl jsem v dobe, kdy bylo bezne, zalozit si tri emailove schranky a byt schizofrenni a ve sve naivite i anonymni. Takze ti u vetsiny lidi pro takovy system zase bude chybet autorizace, protoze domenou seznamu se proste autorizovat nepujde.

[pavlix]

Asi mas pravdu. Prusvih je, ze dneska stale vetsina lidi nema vlastni domenu a pod pojmem email pro ne je neco ve tvaru fanda@seznam-cz.

Tedy spoléhá na to, že ten seznamácký e-mail je fajn. Podle mě tohle bude platit, dokud budou uživatelé primárně pod palcem firem. Byly doby, kdy se i mezi běžnými uživateli skupiny lidí nabalovaly na někoho, kdo pro ně vybudoval nějaké technické zázemí, je otázka, jestli se ty doby ještě někdy vrátí ;).

A zavadet neco, jako virtualni identitu, jeste navic treba potuplovanou nejakym certifikat, toho se zase bojim ja.

Otázkou není, zda budeš mít virtuální identitu, ale kolik jich budeš mít a jaké to budou. Pseudonymita je stejně dobře možná s jakoukoli doménou, která ti ty služby poskytne a přitom na tebe nebude zbytečně moc vyzrazovat.

[petr_fm]

Hele, to mne vubec nenapadlo ze si proste zalozim tri certifikaty, jako drive tri emaily... prusvih je, aby k jejich zrizeni nebyla pozadovana autorizace na urovni obcanky, apod. a jine nez takove certifikaty nebyly uznavane. To je to same, jako dneska autorizace facebookem. Abych mohl napsat nazor do fora, musim vyzradit spousty socialnich vazeb, nebo si pro kazde forum musim zalozit extra ucet.

[pavlix]

Tak mne napada, proc by to defakto nemohlo frcet na klasickem emailu?

Nemůže, protože klasický e-mail ktomu neposkytuje prostředky. To už je jednodušší integrovat e-mail do jabberu než jabber do e-mailu.

Vzdyt imap je super

IMAP je špatný protokol dokonce i pro ten účel, pro který se už teď používá. Nezvládá ani tak základní věc jako je odeslání zprávy (zato SMTP je na to dost nevhodné), zato jiné věci dělá značně komplikovaným způsobem.

jen by ho to chtelo upravit tak, aby komunikace fungovala trochu vice realtime.

To je jako upravit chatku na palác. Teoreticky to samozřejmě jde, ale nejjednodušší je chatku (IMAP) odstranit, aby nepřekážela nebo ji ideálně vůbec nedovézt.

No reknete, neni to lepsi, nez stavet nejaky dalsi protokol?

Není. Pokud už bych si vybíral pro IM stávající protokol, byl by to SIP a nikoliv IMAP.

Navic, ten, kdo nema zadneho klienta, tomu by prisla moje IM zprava klasicky do emailu - bylo by to absolutne multiplatformni.

To ale vůbec nezávisí na použitém protokolu, nýbrž na použitém software a jeho návrhu. Transformovat instantní zprávy na trvalé zprávy rovnocenné s poštou má své výhody i nevýhody.

SERVERY - kazdy si muze vybrat, zda pouzije hostovany server, nebo vlastni.

To platí i pro jabber a SIP (alespoň technicky) a je to obecnou vlastnostní otevřených decentralizovaných protokolů.

Lze aplikovat sifrovani,

Šifrování je pouze nástroj, nikoli cíl. Požadavky pro IM a poštu nemusí být (a nejsou) vždy stejné.

zasilat prilohy

Zasílání příloh je čistě věcí formátu zprávy, který nemusí být vůbec závislý na přenosovém protokolu, nedělá to tedy ani IMAP ani SMTP.

vsechno je uz definovane, hotove a funkcni.

Teď tu o karkulce. Vždyť ani ten e-mail nefugnuje nijak zázračně, natož aby člověk lusknul prstem a samo se to transformovalo na instant messaging.

Defakto by se IM zpravy od tech klasickych mohly lisit jen nejakym autorizacnim retezcem v predmetu emailu.

Fuj.

To by mohlo resit i problem se spamem

Autentizovaný e-mail by problém spamu teoreticky řešil, ale je dobré se zamyslet nad tím, proč to není uvedeno do praxe.

aby clovek dle sveho verejneho certifikatu dokazal podepsat svoji IM zpravu

PKI je super, když jsou lidi ochotní se o něj starat a používat ho.

A ted mi reknete, jake ma tohle reseni problem

Hlavní problém tohoto řešení je, že není ani naimplementované ani vyspecifikované a jako bonus vypadá, že by bylo podstatně horší než jsou existující řešení, a to ve všech možných ohledech, které mě napadají. Je to něco jako kdybych přišel s tím, že ta chajda už je vlastně skoro palác, stačí ji trochu obestavět.

Misto pouzivani nejakych debilit tapy facebook, gtalk, whatsapp, viber a jinych.

Další věc je, že zmíněné debility jsou stavěné za účelem, aby je lidé používali, nikoliv za účelem splnění mokrého snu o instant messagingu po IMAPu.

[Josef Kufner]

Ono ten Jabber zas až tak špatný není. Jen mu chybí pár klíčových věcí. Chtělo by to definovat nový XEP po vzoru XEP-0270 (XMPP Compliance Suites 2010), dát do něj ty klíčové věci. Tedy konkrétně:

• XEP-0198 (Stream Management), aby se neztrácely zprávy
• XEP-0280 (Message Carbons), aby zprávy mohly být na všech klientech současně a okamžitě
• XEP-0313 (Message Archive Management), aby zprávy mohly být dostupné i na tehdy offline klientech
• XEP-0203 (Delayed Delivery), by mělo být i pro real-time zprávy, neboť v kombinaci s XEP-0198 může docházet ke značnému zpoždění při doručování zpráv.
• a mimojiné i to, co se už běžně používá, tedy XEP-0270 (XMPP Compliance Suites 2010).

Aby to ale k něčemu bylo, je potřeba to trošku zapropagovat a dát tomu pěknou známku, kterou by se mohli autoři klientů i serverů chlubit. Něco jako to RYF o kterém tu zrovna sedí zprávička. To by mohlo situaci trošku oživit.

[petr_fm]

Takze defakto z xmpp udelame ruznymi xepy ten email, ze?

1) jake prostredky email neposkytuje, aby se dal vyuzit k IM?

2) to ze je email spatny je tvuj nazor, neznam cloveka, ktery by ho nepouzival a ztrata zprav je vyjimkou. Naproti tomu, znam jen velice malo lidi, kteri pouzivaji XMPP.

3) To neni upravovat chatku na palac, ale pridat na schranku, kterou uz ma kazdy na plote jenom druhou jmenovku.

4) kdo ma nejaky SIP ucet? z beznych lidi - nebavime se o proficich. S profiky muzu komunikovat libovolnym zpusobem, ja chci komunikovat se vsemi

5) zasilani priloh v emailu roky funguje. Na jabberu se mi to nepovedlo se zadnym klientem - kdyz to musim konfigurovat = stoji to za ho... - nastavi to zase jen profik, takze lame budu posilat prilohy zase emailem

Vubec nevim, co bys na tom chtel specifikovat, krome toho, ze predmet emailu pro IM je treba : IMMESSAGE

Zbytek uz je jenom o tom, vytvorit klienta s odpovidajicim UI, nebo tuhle funkci doplnit do soucasnych Email klientu - moznost otevrit chatovaci okno a nastavit si jine upozorneni pro IM zpravy.

[pavlix]

Takze defakto z xmpp udelame ruznymi xepy ten email, ze?

Je možné nad XMPP postavit e-mailovou službu, navíc XMPP poskytuje metody ověření odesilatele, které by se e-mailu docela hodily, ale v diskuzi o instant messagingu je to irelevantní.

1) jake prostredky email neposkytuje, aby se dal vyuzit k IM?

Jaké zázračné prostředky e-mail (tedy IMAP, SMTP, MIME) poskytuje, které nejsou už zakotveny v obecnějších protokolech?

2) to ze je email spatny je tvuj nazor, neznam cloveka, ktery by ho nepouzival a ztrata zprav je vyjimkou. Naproti tomu, znam jen velice malo lidi, kteri pouzivaji XMPP.

Když něco nepochopím, tak se zeptám. Nepsal jsem nic o tom, kolik lidí co používá, lidé teď stejně nejvíc komunikují přes Facebook :).

5) zasilani priloh v emailu roky funguje. Na jabberu se mi to nepovedlo se zadnym klientem

Implementace příloh je triviální, ale zcela logicky navyšuje velikost zprávy o velikost přílohy. To není problém u triviálního protokolu pro předání zprávy serveru jako je SMTP, kde se prostě nastaví limit dostatečný pro přílohy, které očekávám. Instant messaging běžně pracuje jinak a limit na zprávy mívá podstatně nižší, aby se neblokoval kanál.

Celkově je běžný jabber software navržený s ohledem na to, aby byl server ušetřen manipulace s velkými daty, ale není to podmínkou. Z toho taky vychází požadavek na přímé předávání velkých dat, které mi přijde jako super nápad, akorát ta implementace se zpoždovala a zpoždovala, škoda.

Vubec nevim, co bys na tom chtel specifikovat, krome toho, ze predmet emailu pro IM je treba : IMMESSAGE

Pokud mi chceš tvrdit, že když naseru do subjectu do IMMESSAGE, budu mít najednou skvělý instant messaging, tak na to nemám slov.

Zbytek uz je jenom o tom, vytvorit klienta s odpovidajicim UI, nebo tuhle funkci doplnit do soucasnych Email klientu - moznost otevrit chatovaci okno a nastavit si jine upozorneni pro IM zpravy.

Jasně, a všecko bude magicky fungovat. Takových teoretiků vizionářů jsem potkal dost, ale jednu věc měli společnou. Jediné, co z nich kdy vypadlo byly kecy.

[petr_fm]

Je to uplne jednoduche. Kdyz neverim jabberu, jakoze mu uz proste neverim, protoze jsem o hodne zprav pres mobil prisel, tak proste dulezite zpravy si necham poslat SMSkou, nebo na email. Vtip je v tom, ze kdyz si dnes v klientovi nastavim, aby mi oznamoval jen zpravy s predmetem IMMESSAGE, tak mam defakto fungujici IM system.

Vis, ja jsem zase ve svem zivote potkal spousty lidi, kteri zili ve svych snech o idealnim svete. Vsichni meli jedno spolecne - presne vedeli, jak to ma fungovat, aby to bylo SUPER. Vetsina z nich to dokonce vyrobila. Ale nikdo krome jich samotnych to nepouzival. Vis proc? Protoze lidi chteji jednoduche a funkcni veci a hlavne, nechteji na ne cekat rok, dva nebo pet. Chteji je hned.

To, co tady popisujes ty je beh na dlouhou trat. Navic je to neco, co musis lidem vysvetlit a naucit je pouzivat. Email pouzivaji vsichni. Kdyz to uplne zjednodusim, tak mi staci, rict kazdymu, kdo mi chce poslat instantni zpravu . cili zpravu na mobil, nebo klienta kde mne vzdy zastihnou, tak at do predmetu emailu napisou DULEZITE.

Nakrasne mne ted napada, ze by se stejne daly resit i ty pitome transporty. Stacil by k tomu jednoduchy script, ktery by neslouchal na ICQ / jabberu / facebooku a prichozi/odchozi zpravy by lifroval do emailu. Vyhodou je, ze by to behalo i bez SMTP, protoze by stacilo, kdyby to ten IM klient strkal do slozky pro transporty a ten script by si to vybiral a odesilal na ICQ / FB apod.

Ale transporty ser pes. Ja tady resim spise akutni potrebu nahradit SMSky a ICQ necim, na co mu budou moci napsat VSICHNI a pojede to na mobilu, na PC i pres web. Bude to umet historii a nebude to zavisle na serveru zadneho velkeho bratra.

Tohle je mozna lepsi resit s vyvojari konkretnich softu, treba K9 pro android. Protoze je to ciste veci toho softu. Stejne tak by se dal upravit jen nejaky plugin do roundcube + thunderbird a clovek ziska smahem klienty pro vsechny platformy. Staci se jen dohodnout, jak znacit IM zpravy.

[pavlix]

Běh na dlouhou trať je ať to naroubuješ na jakýkoli transport, ale řekl bych, že zrovna IMAP tě bude zdržovat víc než to stavět od nuly, ale pokud po tom tak toužíš, jdi do toho, těšíme se na výsledky ;).

[petr_fm]

Hele, znovu jsem si cetl, co jsi psal. Ja se nechci hadat, ze email je TECHNICKY dobre reseni. Neni, byl proste urceny na neco jineho a jeho protokoly jsou mozna zastarale, ale ohromnou vyhodu - je nezavisly a MASOVE ROZSIRENY.

Vis co je ohromny problem kazdeho reseni ala jabber, irc apod? Ze neexistuje zadny mainstreamovy, masove rozsireny a pouzivany klient. Zakladni predpoklad toho, aby mne lidi mohli kontaktovat je, ze to musi byt pro ne snadno proveditelne. Jsou lidi, kterym stoji za to, si instalovat jakykoliv soft, ale pak jsou lidi, kteri mi chteji jednou za rok neco sdelit a sami pouzivaji facebook / Google hangouts. Takove neprinutim si neco instalovat. Proste mi poslou email, ktery treba prave nesleduju, protoze to pro mne neni IM kanal.

Jabber se mi libil, protoze vetsina lidi mela Gtalk a byli tak schopni mi bez problemu psat. Nemusil jsem je nutit nic instalovat. Tohle se stava minulosti a ja proste nechci prechazet na G Hangouts, nebo dokonce facebook. Jasne, muzou mi psat emaily, nebo SMSky, ale to jsme zase u toho.

Takze email ma ohromnou vyhodu v tom, ze KAZDY uz UCET i klienta ma. Takze neni treba nikoho presvedcovat at si neco instaluje, staci mu dat treba adresu ve tvaru hotline@mojedomena.cz a presmerovat si ji na IM - treba jen filtrem.

[pavlix]

Ja se nechci hadat, ze email je TECHNICKY dobre reseni.

To je taky to jediné, co jsem tím chtěl říct.

Neni, byl proste urceny na neco jineho a jeho protokoly jsou mozna zastarale, ale ohromnou vyhodu - je nezavisly a MASOVE ROZSIRENY.

You don't say.

Takove neprinutim si neco instalovat.

Stejně jako je nepřinutíš začít používat software nebo nedej bože službu na e-mail s tebou vysněnými IM rozšířeními.

Takze email ma ohromnou vyhodu v tom, ze KAZDY uz UCET i klienta ma.

Z hlediska instant messagingu je účet a klient, který instant messaging nepodporuje nulovou hodnotou. Navíc ten účet vůbec není e-mailový, je to jen jméno a heslo, na které lze navázat libovolné služby přes libovolné protokoly.

Navíc ten účet vůbec není e-mailový, je to jen jméno a heslo, na které lze navázat libovolné služby.

Pokud mi nějakej debil začne do standardního e-mailu posílat zprávy v kadenci běžné na IM, tak docílí jen toho, že si ho zabokuju. Snad jedině že by se jednalo o účet k tomu určený jako jsou třeba konvergované zprávy na Facebooku.

Kritizuješ můj technický vhled bez pádných technických argumentů a přitom zjevně ignoruješ uživatelskou stránku celé věci. Epic fail.

[hydrandt]

Uz to existuje, hledej quickmsg na f-droidu. Nezkousel jsem to.

[petr_fm]

To vypadá dost dobře. To by mi mohlo řešit náhradu spojení s lidmi co jsou na androidu ale používají Hangouts.

Mimochodem, docela dobrý nápad, filtrovat hlavičku a přijímat tedy jako IM zprávy podle toho, zda je odesílatelem taky daný SW.

[Josef Kufner]

První věc, kterou e-mail neumí je, že negarantuje doručení zpráv (nebo informování o selhaní). Odeslaný e-mail je prostě poslán do světa a zda dojde je o náhodě. Že to funguje celkem spolehlivě je malý zázrak.

[petr_fm]

To ano, ale uz nyni ma spousta klientu implementovanou funkci notifikace doruceni/precteni zpravy. Cili by stacilo ji jen vyuzit. Pak jasne vidim, ze adresat zpravu cetl / pripadne adresat nemusi tohle potvrdit a muze hrat mrtveho brouka (kazdy nepotrebuje byt vzdycky zastizitelny)

Pokud email spadne do spamu, nebo je nejaky problem s prijemcem, pak vetsina serveru zasle zpet zpravu, kterou by klient zobrazil a ktera je uz notoricky znama.

Ale jinak jo, je to docela vecna pripominka, muze se stat, ze email bude "spolehlivy" stejne, jako ten jabber. Ovsem jeho spolehlivost nezavisi na kvalite spojeni klienta do internetu, ktera v pripade mobilniho pripojeni je dost chaba. Takze proto jsou problemy s dorucovanim emailu spise vyjimkou, kdezto na jabberu jsem mel pri prechazeni 3G/wifi problemy se ztracenim zprav neustale.

[Josef Kufner]

Pokud mail spadne do spamu, nikdo se nic nedoví. Od toho spam filtr je. Další problém e-mailu je, že není interaktivní. Zpráva musí projít několika frontama, než se někam dostane a to trvá. Občas sekundy, občas minuty. Takový IM by neměl šanci.

To, nad čím slintáš, je vymyšleno a popsáno v těch XEPech, které jsem tu odkazoval. Přečti si alespoň jejich úvody. K části z nich už i existuje použitelná stabilní implementace.

Za domácí úkol si pak zkus implementovat jednoduchého XMPP klienta a vedle toho jednoduchého IMAP+SMTP klienta. To ti myšlenky na e-mail rozežene.

[pavlix]

Že to funguje celkem spolehlivě je malý zázrak.

Větší zázrak je vysvětlovat to lidem, když zjistí, že to spolehlivě nefunguje.

[j]

"Rekl bych, je jabber, jak byl vymyslen je proste k nicemu. Vsechny zpravy jdou stejne pres nejaky server,"

Ehm ... ani nahodou, pokud mas internet (a ne nejakou zNATovanou srajdu) tak se klidenti bavi naprimo. Navic jabber by default sifruje komunikaci, takze vymejslet takovy kraviny, jako ze budes komunikaci ukladat nekde cestou ...

[pavlix]

Ehm ... ani nahodou, pokud mas internet (a ne nejakou zNATovanou srajdu) tak se klidenti bavi naprimo.

Můžou se bavit napřímo a dokonce se můžou bavit napřímo i přes NAT, ale nejsem si vědom toho, že by to byl běžný default. Což samozřejmě nemění nic na tom, že to, na co reaguješ je v tomto ohledu mimo, protože to jabber skutečně umožňuje a dokonce i s tím NATem.

[petr_fm]

Jeste mi vysvetli, k cemu je to dobre, ze se muze bavit naprimo, kdyz spojeni spolu navazuji pres server? Odpovim si sam : k tomu, aby se nedalo rozumne na serveru implementovat ukladani zprav a historie. Rozumim tomu u SIPu a jinych, kde se prenasi velke objemy dat, ale IM, kde je zatizeni serveru uplne minimalni? Je to blbina.

[pavlix]

Mně je jedno, k čemu je to podle tebe dobré. XMPP prostě umožňuje přenášet zprávy jak prostřednictvím serverů, tak prostřednictvím přímého kanálu, tedy poskytuje jak to, co chce j, tak to, co chceš ty.

[petrfm]

Souhlasim. A to s tou prioritou, starym chat oknem a moznosti rozpadu spojeni, kdy se mezitim zpravy doruci na jineho - Treba i away klienta, napr. v kancelari cini z jabberu komunikacni nastroj k prdu.

Pokud ocekavam DULEZITOU zpravu, treba ze mam nekam jet, nebo ze se nekam nejede, tak se klidne muze stat, ze tu zpravu nedostanu - a nejhorsi na tom je, ze to nezjistim (treba gtalk mi ukaze, ze jsem offline, takze vim, ze mam problem s komunikaci. Ve chvili, kdy se dostanu online, mi naskoci stare zpravy, takze VIM, ze mi nikdo mezitim nepsal - mohu se na to ABSOLUTNE SPOLEHNOUT - to je to, co na jabberu TRAGICKY CHYBI.)

[petr_fm]

Porad se tady bavime o xepech, protokolu, technickem reseni IM, atd. Ale unikla mi odpoved diskutujicich na jedny ze zakladnich otazek. Kdybyste mi na ne odpovedeli, byl bych rad a cenil si toho. Kazdy clovek totiz IM pouziva jinak a ma od nej jine ocekavani a naroky. Proto k vzajemnemu porozumeni je dulezite, abychom vedeli, co kdo od IM ocekava.

1) Vam pripada Jabber jako spolehlivy IM?

2) nevadi vam, ze se mohou zpravy tvarit jako dorucene, odesilatel si mysli, ze jste je dostali a vy nic nevite?

4) nevadi Vam, ze kdyz si s nekym pisete pres pocitac, nemate sanci z jineho pocitace vyhledat historii?

5) skutecne byste dokazali naucit pouzivat jabber treba svou babicku, nebo nejakou pipinu na diskotece? Ted nechejme stranou, ze zadne pipiny na diskotece kontaktovat nepotrebujete a babicka uz nezije. Chci tim rict, zda si skutecne myslite, ze je jabber a jeho klienti tak, jak je dneska, vhodny pro absolutni PC analfabety, kteri umi pracovat s emailem a facebookem, cili Vam to umozni byt v kontaktu s lidmi, kteri dosud pouzivaji jen email + fb?

6) kdybyste potkali cloveka, treba spoluzaka ze studii, ale nechteli byste mu davat mobilni cislo, protoze mobil na volani nepouzivate. Dali byste mu jako kontakt na sebe jabber, nebo email? A proc?

[pavlix]

1) Vam pripada Jabber jako spolehlivy IM?

Nejednoznačná otázka. Software, který neimplementuje hop-to-hop ACKs ani nepoužívá ten trik s TCP je v principu nespolehlivý. Nicméně vzhledem k tomu, že lidé používali ICQ a SMS a dnes používají Facebooḱ, tak spolehlivost pro většinu zjevně nepatří mezi klíčové vlastnosti.

2) nevadi vam, ze se mohou zpravy tvarit jako dorucene, odesilatel si mysli, ze jste je dostali a vy nic nevite?

Někdy vadí, někdy nevadí. Trpí tím většina technologií, které používám, od SMS přes IM až po e-mail, a u některých lidí to ani sebespolehlivější technologie nezachrání, takže jsem zvyklý se podle toho chovat.

4) nevadi Vam, ze kdyz si s nekym pisete pres pocitac, nemate sanci z jineho pocitace vyhledat historii?

Nevadí, nedělám to.

5) skutecne byste dokazali naucit pouzivat jabber treba svou babicku

Mojí ne, ale to je trochu jiná story. Babičku, která je ve formě a schopná zvládnout základy používání PC samozřejmě ano.

nebo nejakou pipinu na diskotece

Když zvládla ovládat smartphone, zvládne všechno, ale nejspíš nebude chtít, má už fejs.

Chci tim rict, zda si skutecne myslite, ze je jabber a jeho klienti tak, jak je dneska, vhodny pro absolutni PC analfabety

Nejsložitější je pro ně všimnout si notifikace o žádnosti o autorizaci. Jakmile se jim podaří zobrazit žádost, odkliknout ji už zvládnou a zbytek nevyžaduje víc znalostí než psaní.

kteri umi pracovat s emailem a facebookem

Pokud někdo zvládne webmail a facebook, zvládne i jiná ekvivalentní uživatelská rozhraní, pokud chce.

6) kdybyste potkali cloveka, treba spoluzaka ze studii, ale nechteli byste mu davat mobilni cislo, protoze mobil na volani nepouzivate. Dali byste mu jako kontakt na sebe jabber, nebo email? A proc?

Mobil na volání používám, a používám ho i na SMS. Pro mě by byl na prvním místě vzhledem k rozšířenosti a dostupnosti, na druhém elektronická pošta vzhledem k rozšířenosti a pohodlnějšímu psaní delších textů, jabber pokud by to byl člověk z oboru. Ale ve skutečnosti by se mě na kontakt nikdo neptal a dostal bych zprávu přes Facebook.

[Josef Kufner]

Pokud chceš spolehlivý kontakt, tak potřebuješ dva, jedním z nich je obvykle e-mail. Jenže prostý netechnický lid maily čte jen občas a pokud si to přečte, ještě to zdaleka neznamená, že odpoví.

Facebook má do spolehlivého daleko, ale lze použít k tomu, aby byl člověk nalezitelný (pokud chce). Taktéž LinkedIn.

Jabber bude fajn až bude těch pár XEPů výše samozřejmostí. To bude ještě nějaký ten pátek trvat.

Tak jako tak, žádná služba není 100%, a i kdyby ten IM byl dokonalý, stále je potřeba všem říkat, že zprávy se občas ztratí a občas se přehlédnou, takže dokud na ně adresát neodpoví, nelze je považovat za doručené.

Spolehlivý komunikační kanál sice šetří starosti, ale stále se to může podělat o vrstvu výš.

[pavlix]

Stejně si myslím, že největší problém je motivace stavět služby a software nad zcela otevřenými protokoly. A v rámci open source komunity nízká koncentrace lidí, kteří by oplývali jak schopnostmi připravit UI, které zaujme masy, tak technickým vhledem, tak finanční nezávislostí, tak nekonečným samaritánstvím vůči lidem, kteří se stejně většinu doby projevují jako nevděční idioti¹.

¹ Pozor nadsázka.

[petr_fm]

Jo, s tim souhlasim. Z takoveho nastroje defakto tvurce nemuze nic mit, pokud nemuze ani smirovat, ani zobrazovat reklamu. Takze ac neznam historii jabberu, myslim, ze je to takove to udelej si sam. To znamena, ze to potrebuju ja, tak si to udelam a kdyz to funguje a jsem dostatecny samaritan, tak to DAM i druhym. Popravde, ja jsem si myslel, ze tady uz nekdo takovy existuje. Ze nejsem jediny, kdo resi takove problemy a ze jsou lidi, kteri k tomu maji odpovidajici znalosti, aby to pro ne nebyl problem na vice, jak par hodin, ktere jim stoji za to, mit kvalitni komunikacni nastroj.

Ja popravde vubec nemuzu pochopit, proc nekdo udelal neco takoveho, jako je jabber (coz muselo samo o sobe dat dost prace) a nedodelal k tomu tech par blbosti navic, aby to fungovalo spolehlive. Ale mozna jo, v te dobe nebyl Gtalk a zrejme nikdo nemel Jabber s cim srovnavat A dnes uz proste lidi radeji pouzivaji ten gtalk, nebo FB, nez aby si upravili jabber do funkcni podoby.

[pavlix]

Popravde, ja jsem si myslel, ze tady uz nekdo takovy existuje. Ze nejsem jediny, kdo resi takove problemy a ze jsou lidi, kteri k tomu maji odpovidajici znalosti, aby to pro ne nebyl problem na vice, jak par hodin, ktere jim stoji za to, mit kvalitni komunikacni nastroj.

Čistě hypoteticky, jestliže se teď rozhodnu napsat si třeba e-mailového klienta dle vlastních představ nebo IM klienta, když na to přijde, co z toho budu mít? Spoustu práce, která povede k nedokonalému software, které budu muset dále udržovat nebo opustit. Takže to pro mě nedává smysl, pokud se nenajdou další, kteří by se na tom z vlastních důvodů podíleli a pokud možno tomu mohli věnovat vzhledem ke svým individuálním podmínkám třeba i více času.

Ja popravde vubec nemuzu pochopit, proc nekdo udelal neco takoveho, jako je jabber (coz muselo samo o sobe dat dost prace) a nedodelal k tomu tech par blbosti navic, aby to fungovalo spolehlive.

A hlavně proč to bylo na vzdory tomu natolik úspěšné, že o jabberu vůbec víš a navíc jsi ochotný se o něm snad i hádat.

A dnes uz proste lidi radeji pouzivaji ten gtalk, nebo FB, nez aby si upravili jabber do funkcni podoby.

Facebook, Google Hangouts apod. jsou konzumní služby, jejichž primárním účelem není se předvádět s otevřenou technologií, ke které může každý připojit vlastní doménu. Jsou to takové dvě strany světa, kde na jedné je láska k technologii a otevřenosti, na druhé je chladný komerční kalkul a mezitím se to různě potkává, viz googlí don't be evil.

[Josef Kufner]

Takže jsme skončili na tom, že Jabber prostě nevydělává a nestojí za ním žádná komerční entita.

Jak jsem teď prolézal XEPy, narazil jsem na pár věcí okolo Internet of Things (XEP-0347, XEP-0326, XEP-0325, XEP-0324, XEP-0323). Tam by se možná nějaký business model dal najít.

[petr_fm]

Sranda je, ze ja bych treba byl ochotny za takove reseni zaplatit. Ale ne stylem, ze si pronajmu nekde na serveru neco, co dela buhvi co. Ja mam lepsi napad, nez internet of things, ktere se podle mne budou ubirat cestou vlastniho protokolu. (mimochodem, odkazy ti nefunguji)

Resil jsem nadavno, jak naroubovat nejaky webchat na komunikaci pres jabber. To by mozna byla zajimavejsi cesta. Podpora pro eshopy a support na weby. Tohle vsechno potrebuje klienta a jabber je fajn klient. Dokonce uz je hotova cast i na web - ruzne minichaty. A zase jsme u toho - pokud chci tohle komercne nasadit, pak to musi fungovat a zpravy se musi dorucovat.

[pavlix]

Sranda je, ze ja bych treba byl ochotny za takove reseni zaplatit.

Ale ne dost. A ani bys nebyl ochotný sehnat dostatek lidí, kteří by zaplatili s tebou.

A zase jsme u toho - pokud chci tohle komercne nasadit, pak to musi fungovat a zpravy se musi dorucovat.

Což je jak už jsme se tu bavili triviálně implementovatelné, pokud máš pod palcem jak klienta, tak server, nebo dokonce pokud jen klienta, pokud využiješ vlastností Linuxu nebo FreeBSD kernelu na tom web serveru.

[petr_fm]

Vis co mi prijde jako vetsi problem? Ze se tady x dnu bavime o Jabberu, jakozto otevrenem IM. Verim, ze pulka uzivatelu tohohle serveru NEJAKY IM pouziva, ale k Jabberu tady diskutujeme - kolik nas je? 5? Ja si proste myslim, ze Jabber vymira a my jakozto uzivatele to nevidime, protoze ho pouzivame. Ale kdyz se kohokoliv zeptam jestli ma jabber, mysli si, ze je to nejaka eroticka pomucka.

[pavlix]

Já osobně žádný problém nevidím. Jsem většinu doby dostupný přes GSM volání, SMS, irc, jabber a e-mail. Všechno to jsou buď otevřené technologie, nebo je alespoň zajištěno, že se druhá strana nemusí registrovat u mého poskytovatele té služby. K identifikaci se používá telefonní číslo, přezdívka registrovaná v síti nebo přezdívka kvalifikovaná doménou. Nevidím důvod nad tím nějak brečet.

[Jezekus]

Sam mam jabber (i vlastni server), pred par lety na nej preslo nekolik kamaradu (nejsou v IT oboru), cela rodina ho pouziva ke komunikaci a to velice spokojene (vcetne babicky).

Co jsem procital tuhle diskuzi tak jsem si zkousel nektere scenare. Ale obvykle bud na PC jabber vypinam, kdyz prechazim na mobil nebo tak nejak pocitam s tim, ze v mezidobi nez kontaktuji danou osobu z mobilu (proste s ni otevru konverzaci a napisu ji) nebo nez se mi klient na PC prepne do Away tak zpravy mohou dorazit na nej. Jinak to funguje pomerne spolehlive, ale kriticke veci resim pres GSM obvykle volanim, protoze SMS jsou snad jeste mene spolehlive nez ten jabber

[pavlix]

Takže jsme skončili na tom, že Jabber prostě nevydělává a nestojí za ním žádná komerční entita.

To ani tak ne, spíš že není komerční či nekomerční entita schopná většího vývoje, která by měla eminentní zájem na zlepšení těch věcí, o kterých jsme se bavili a to pokud možno napříč alespoň open source implementacemi. Nehledě na to, že se většině tradičních open sourcařů při pohledu na XML transport udělá špatně.

[Jiří Lisický]

1) nemel jsem s tim zatim extra problem 2) jo to je blby 4) mam VIP jabber.cz a k nemu je historie ukladana na serveru. Takze kdyz neco potrebuju da se tam podivat. 5) babicce jsem kdysi jabber nainstaloval. 6) dam mu oboje. Ale asi ma jen email

[jopa]

1/ pro mne ano, je to dostatecne k tomu k cemu to slouzi

2/ obcas se to stane, vadi mi to, ale spolehlivy IM neexistuje, stava se mi to i na jinych protokolech nejen na jabberu

4/ ne, historii nepotrebuji. IM beru jako nastroj rychle komunikace a ne nahrazku mailu (kde vyhledavam stare odeslane zpravy). Nejakou dobu jsem historii lokalne ukladal, ale nikdy jsem se do ni nedival, tak jsem to vypnul.

5/ ano. Podle me je to jedno jestli jde o jabber, icq nebo cokoliv jineho. Jde o to nainstalovat klienta a ukazat jak se s tim dela. Nejvetsi omezeni ale vidim v tom, pokud neexistuje online moznost pouzivat chat pres prohlizec. Z vlastni zkusenosti - pokud chci nekomu nainstalovat a nastavit jakykoliv klient, je to problem, vyzaduje to spustu prace a vysvetlovani a vzdy jsem musel fyzicky na pc uzivatele. Pokud existuje jednoduche web rozhrani, kde se user zaregistruje a hned pouziva, tak to zvladne kazdy sam. Takze kdyz sbalim pipinu na diskotece a vysvetlim ji, at se regne na google (nebo uz casto ucet ma), ze si pak budem chatovat, tak bez problemu.

6/ davam telefon a mail, IM (jakykoliv) malokdo ma, maximalne maji FB.

Jeste par postrehu:

- udajne je jabber nejrozsirenejsim protokolem pro IM na svete (mimo jine to pouzva Google, Cisco, myslim, ze i FB chat)

- smula je, ze i kdyz ruzne firmy pouzivaji stejny protokol, nejde komunikovat ven (z FB nenapisu nikomu na Google) bez ruznych transportnich serveru apod. Nemluve o jinych protokolech jako icq apod. To mi prijde absurdni, to je jako bych nemohl poslat mail ze Seznamu na Centrum. K tomu misto sjednoceni pribyvaji dalsi komunikatory - Viber apod.

- podobna situace je u IP telefonie. Existuji standardy jako SIP, ale stejne si kazdy vymysli svoje ptakoviny jako skype, takze opet nejde volat mezi sebou vzajemne (bez transportu).

[Josef Kufner]

Zrovna Skype se jako příklad vymýšlení ptákovin moc nehodí. Byl to asi první peer-to-peer komunikační nástroj, který nepotřeboval téměř žádnou infrastrukturu poskytovatele (přihlašovací server, jinak nic). V době kdy přišel už SIP sice nějakou dobu existoval (cca 8 let), ale ještě se pořádně nerozšířil.

[pavlix]

V době kdy přišel už SIP sice nějakou dobu existoval (cca 8 let), ale ještě se pořádně nerozšířil.

Tedy to bylo vymýšlení ptákovin, z technologického pohledu.

[Josef Kufner]

I tak se dá říkat výzkumu a nové technologii.

[Josef Kufner]

Btw, zrovna jsem narazil na Jits. Máte s tím nějaké zkušenosti?

Android klient vypadá poněkud mladě a povedlo se mi ho pěkně rozhodit, ale píšou, že to je alfa verze pro odvážné. Na druhou stranu, audio hovor s Gajimem se mi povedlo uskutečnit.