Mozilla definitivně opouští IRC

Mozilla definitivně opouští IRC. Vloni začala hledat novou veřejnou komunikační platformu. Dosud používala IRC (plus interně neveřejný Slack a po nějakou dobu i Mattermost). Nicméně IRC i servery zastarávaly a zejména použitelnost na mobilních zařízeních byla často problematická. Po zvažování a zkoušení různých alternativ se Mozilla přiklonila k otevřenému protokolu Matrix (můžete také znát referenčního klienta Riot) a na konci února IRC vypne.

27.2.2020 13:11 | Ladislav Hagara | Komunita

Komentáře

[-]

RIP Mozilla

[Joelp]

facepalm

[Onanym]

Proč to dělat jednoduše, když to jde složitě.

[abc]

no IRC je teda vrchol jednoduchosti. Jak si treba _jednoduse_ precist zpravy mne poslane, kdyz jsem byl offline?

[xxx]

Se pocia s tim, ze ti to bezi nekde ve screenu, ne? Tak jaky offline. Jedine snad pri pozaru v serverovne.

[abc]

Takze na rozumne uzivatelske pouziti IRC potrebuju mit server, jo? Rikam, vrchol jednoduchosti!

[jejda]

Na posílání zpráv někomu kdo je offline slouží e-mail. To by nám taky za chvilku mohlo začít vadit, že náš supermoderní komunikátor neumí třeba: přehrávat mp3, překládat cizojazyčný text, ripovat DVD, kompilovat kernel ... . A dopadlo by to nakonec jak s webovýma prohlížečema. Musíš spouštět několik set megabajtovou monstrozitu aby sis prohlídl html.

[Peter Golis]

Vidím dobre, e-mail v čase facebooku a iných blikacích technológií? Pán je dinosaurus.

[rastos]

Vieš si založiť konto na f*c*book-u bez e-mail-u?

[Peter Golis]

Nikdy som si nezakladal konto na FB.

[kralyk z abclinuxu]

Na posílání zpráv někomu kdo je offline slouží e-mail.

Jakože se kouknu, jestli ten člověk je/není na IRCu a podle toho píšu do IRCu nebo emailem? To je teda vrchol komfortu opravdu. Nehledě k tomu, že to má race conditions a taky když to pošleš mailem, tak to neuvidí nikdo z ostatních na tom IRCu. Často chci, aby tu odpověď viděli i ostatní. To už by se to rovnou celý muselo přehodit do e-mailový konference (a ty zas mají svou sadu problémů).

Jako já mam IRC opravdu rád a třeba na weechat běžící v tmuxu nedám dopustit, ale ty důvodu jsou už dnes v podstatě víceméně už jen emocionální / nostalgický a fakticky IRC je na komunikaci a koordinaci ve skupině dost neefektivní. Těm snahám přejít na něco schopnějšího rozumim.

Matrix moc neznám, ale je to otevřený protokol a slyšel jsem vesměs chválu, takže možná je na čase se na to podívat...

[xkucf03]

Jakože se kouknu, jestli ten člověk je/není na IRCu a podle toho píšu do IRCu nebo emailem? To je teda vrchol komfortu opravdu. Nehledě k tomu, že to má race conditions a taky když to pošleš mailem, tak to neuvidí nikdo z ostatních na tom IRCu. Často chci, aby tu odpověď viděli i ostatní.

Já jsem po letech dospěl k tomu, že pro synchronní komunikaci (IM) nemám moc využití a ve většině případů mi vyhovuje víc asynchronní (což je typicky e-mail, která má řadu problémů, ale to není chyba asynchronní komunikace). IM mi dává smysl spíš v případech, kdy si s někým explicitně dám schůzku a místo abychom se sešli osobně nebo si zavolali, tak si píšeme, ale je to nějak časově ohraničené. Dlouhodobé vysedávání (idlování)¹ někde je podle mého blbost a spíš to odvádí pozornost od práce a snižuje produktivitu. A je celkem jedno, jestli je to archaické IRC, modernější a lepší XMPP nebo nějaký webový paskvil.

To už by se to rovnou celý muselo přehodit do e-mailový konference (a ty zas mají svou sadu problémů).

Ano. Tohle už jsem tu někde psal, bylo by lepší navázat na NNTP a e-mailové konference a posunout to někam dál. To je podle mého lepší, než primárně synchronní/IM komunikační technologie.

U těch e-mailových konferencí je problém se dostat ke zprávám z doby, kdy jsi je neodebíral (existují sice archívy, ale ty mívají dost nepoužitelné webové rozhraní). Taky je problém filtrovat zprávy/vlákna, která tě zajímají – máš pak složky s tisíci nepřečtenými zprávami, z nichž většina tě nezajímá. Tohle jde částečně řešit nějakým lepším klientem a filtry, ale spíš si myslím, že to chce nový decentralizovanější protokol, který by nahradil NNTP a e-mailové konference.

_{[1] i když takhle v nějakých místnostech jsem, tak tam vlastně moc nejsem a kouknu tam jen náhodně občas, nemá to moc velkou prioritu}

[kralyk z abclinuxu]

Moje zkušenosti je, že IM, resp. IM diskuse jsme používali v několika zaměstnáních v rámci aktuální spolupráce na projektech. To fungovalo/funguje docela dobře, lidi se třeba vyměňují snippety, logy apod.

To rozlišení synchronní vs asynchronní komunikací IMO není dobře definovaný a ten rozdíl se dnes stírá. Třeba Zulip s těmi vlákny/tématy může fungovat v roli IM i strukturované diskuse. (Matrix to má afaik podobně, ale to jsou jen zvěsti, co jsem slyšel.)

Tohle jde částečně řešit nějakým lepším klientem a filtry, ale spíš si myslím, že to chce nový decentralizovanější protokol, který by nahradil NNTP a e-mailové konference.

A v čem je problém s Matrixem?

[abc]

To rozlišení synchronní vs asynchronní komunikací IMO není dobře definovaný a ten rozdíl se dnes stírá.

Presne tak, prijde me, ze ten rozdil byl prvnotne vubec dan jen technickymi omezenimi (IRC nepersistentni zpravy, negarantovane doruceni vs. email nedefinovana doba doruceni).

Dnesni moderni platformy jako Matrix ten rozdil stiraji a umoznuji plynule prechazet z asynchronniho stylu komunikace do synchroniho a naopak.

[xkucf03]

Třeba Zulip s těmi vlákny/tématy může fungovat v roli IM i strukturované diskuse.

Zulip jsem navrhoval místo toho „našeho“ IRC kanálu. Nějaké zlepšení by to přineslo, protože to IRC je fakt jen taková virtuální hospoda. Nicméně z aplikací jako Zulip stejně nemám úplně dobrý pocit a není to nic, na čem bych chtěl být závislý pro nějaké seriózní účely. Pořád je to jen nějaká webová stránka (byť zabalená do „desktopové“ electron aplikace), přes kterou se můžu dívat na zprávy… Teoreticky by je odtamtud šlo vytahat přes jejich API… ale pořád to pro mne není na úrovni NNTP, IMAP, což jsou standardní protokoly, ke kterým se můžu připojit různými klienty, nebo adresáře ve formátu Maildir, což je taky standard, se kterým umí pracovat různé softwary.

A v čem je problém s Matrixem?

Primárně orientované na IM, příliš webové, příliš komplexní – specifikace má nějakých 580+ stránek, implementace má přes milion řádek kódu, přes 2 GB (a to nemám postahované všechno). Nejsem zrovna extrémista typu Suckless¹, ale přeci jen bych si představoval něco jednoduššího…

_{[1] to jsou ti lidé, kteří nesnáší víceméně všechny netriviální technologie}

[kralyk z abclinuxu]

ale pořád to pro mne není na úrovni NNTP, IMAP, což jsou standardní protokoly, ke kterým se můžu připojit různými klienty

Jo, to je výhoda, ale nevýhoda tradičních protokolů jako IMAP apod. je, že jsou často technicky ošklivý, jsou např. dost free-form/plaintext (IMAP a koncekonců i HTTP) nebo mají různý jiný technický footguns, který už by se dnes nepoužily (třeba referencování stringů v DNS).

Když vemeš takovej protokol a nějak ho rozšíříš, tak máš vlastně z obou světů to horší - nevýhody starýho protokolu + nutnost implementovat něco novýho ve veškerých klientech.

Ten JSON přes HTTP teda taky není moc výhra, ale aspoň tam máš nějakou strukturu...

příliš komplexní – specifikace má nějakých 580+ stránek, implementace má přes milion řádek kódu

Koukám na to a vypadá to opravdu docela složitě. Na druhou stranu ale mi nepřijde, že by tam bylo něco, co tam vyloženě nepatří.

IMO ta složitost je daň za a) non-centralizovanou architekturu / federaci a b) vysokou napojitelnost na různé další standardy komunikace, autentizace apod. Pokud budeš od protokolu chtít podobný fíčury, IMO to nevyhnutelně prostě bude složitý. (Decentralizované technologie jsou z podstaty věci znatelně složitější než centralizované.)

Vydělit tu složitost do "rozšíření" IMO není řešení a přináší víc problémů než užitku, protože to vede ke fragmentaci. Problém se tím jen ignoruje, resp. přesune na uživatele, který pak musí řešit, jaký software podporuje / nepodporuje která rozšíření... No a tuhle story už koneckonců známe, takhle dopadlo XMPP, kde když se na to dívám zpětně, tak se divim, že se to vůbec trochu používalo...

[petr_p]

Vydělit tu složitost do "rozšíření" IMO není řešení a přináší víc problémů než užitku, protože to vede ke fragmentaci.

To je krátkozraká představa. Že někdo navrhne dokonalý protokol, který nebude třeba nikdy rozšířit. Kvalitní protokol se používá věky právě proto, že jak se mění svět, protokol se doplňuje a žije dál. Bohužel dnes je moderní místo evoluce dělat revoluce, takže málokomu přijde divné, že kvůli novým vlastnostem je třeba vše vyhodit a začít zase od nuly. Já se vůbec nedivím, že třeba Mozilla krachuje, když sotva se dopsala podpora HTTP/2, už klepe na dveře nekompatibilní HTTP/3. Samozřejmě podporu HTTP/1 si odstranit nedovolí. (I když tady je to asi záměr Googlu.)

[Josef Kufner]

Rozšíření protokolu je jedna věc a podpora rozšíření je druhá věc.

Pokud je protokol slušněnavržený, tak časem půjde doplnit nové funkce a vydat novou verzi protokolu, která bude zpětně kompatibilní s tou starou. Uživatel pak jen řeší, zda daný software podporuje/potřebuje verzi N nebo N+1.

Pokud protokol podporuje rozšíření, tedy například XMPP a jeho XEP, tak vzniká mnoho možných kombinací, kdy jeden program zvládá nějakou podmnožinu rozšíření, jiný software jinou podmnožinu rozšíření, a při troše štěstí se na tom podstatném shodnou. Sice se takový protokol dá snadno rozšiřovat, ale komplikuje to život všem okolo.

[xkucf03]

Rozšíření protokolu je jedna věc a podpora rozšíření je druhá věc.

A takový Linux bys zařadil kam? Je to sice „monolit“, ale můžeš si ho při kompilaci upravit a většinu modulů z něj vyházet a vyrobit si relativně minimalistické jádro. A pořád se to bude jmenovat Linux, akorát to bude obsahovat zlomek funkcí, které „běžný Linux“ obsahuje, takže programy, které očekávají, že Linux bude něco umět, nemusí fungovat. Je to podobný případ, jako u toho protokolu – je potřeba si vždy dohodnout/specifikovat nějakou množinu požadovaných funkcí.

[kralyk z abclinuxu]

Je to podobný případ, jako u toho protokolu

No, není...

je potřeba si vždy dohodnout/specifikovat nějakou množinu požadovaných funkcí

To je ale přece právě úkol protokolu. Přesně proto existují protokoly, abys nemusel s každým vyjednávat specifikaci vzájemné komunikace a mohl se místo toho odkázat na jednu z existujících specifikací a prostě začít komunikovat.

[xkucf03]

No, není...

Proč ne? V obou případech je to nějaké API. Jednou to jsou systémová volání, podruhé nějaké zprávy posílané po síti, ale to je víceméně technický detail. V zásadě jde o to, že spolu nějaké dvě strany komunikují a existuje nějaká maximální množina možných interakcí. V praxi je obvykle dostupná jen nějaká podmnožina, na které je potřeba se buď předem dohodnout, nebo si za běhu otestovat, co je dostupné a podle toho přizpůsobit svoje chování.

Někdy se to řeší formou „profilů“ (resp. dá se tomu říkat různě), což jsou pojmenované podmnožiny definované s ohledem na předpokládané využití. Např. v Javě máš SE, EE, ME… resp. v novějších verzích je ta granularita vyšší.

Přesně proto existují protokoly, abys nemusel s každým vyjednávat specifikaci vzájemné komunikace a mohl se místo toho odkázat na jednu z existujících specifikací a prostě začít komunikovat.

Vtip je v tom, že si nemusíš domlouvat „jak“ budeš komunikovat – to je definované ve specifikaci. Ty si domluvíš jen které části té specifikace je potřeba splnit (což lze dále zjednodušit pomocí těch profilů). Máš např. možné interakce A, B, C, … Z a ty jsou definované ve specifikaci. Pokud chce někdo dělat třeba B, tak v té specifikaci je přesně popsané, jak ta interakce bude vypadat – na tom už nic nevymýšlíš, nedomlouváš – je přesně jeden způsob, jak B dělat (na rozdíl od situace, kdy žádný standard neexistuje, nebo je standardů více). Takže ty si pak jen domluvíš, že např. A,B,C jsou povinné a D,E,F jsou podporované, ale nepovinné (tzn. když nebudou dostupné, program bude fungovat v omezeném režimu, ale fungovat bude a jde o situaci, na kterou je připravený).

Ještě se vrátím k tomu Linuxu: když si ho např. zkompiluji bez podpory POSIX MQ, tak aplikace vyžadující tuto funkcionalitu nebudou fungovat (tj. „druhá strana nepodporuje danou část protokolu“), ale pokud POSIX MQ povolím, tak existuje právě jeden způsob, jak má toto API vypadat a není potřeba se na ničem domlouvat – stačí říct: „POSIX MQ fronty jsou požadované“.

[kralyk z abclinuxu]

Proč ne?

Protože konfigurace kernelu mě nomezuje v komunikaci s lidma (vyjma nějakejch specielních případů).

Vtip je v tom, že si nemusíš domlouvat „jak“ budeš komunikovat – to je definované ve specifikaci. Ty si domluvíš jen které části té specifikace je potřeba splnit (což lze dále zjednodušit pomocí těch profilů).

Já ale nechci žádné části specifikace s nikým domlouvat. Tohle vede zase k těm samým problémům. Pepa chce poslat Lence soubor. Lenka používá klient, který nepodporuje soubory. Pepa tedy žádá Lenku, aby si nainstalovala další klient. Lenka odmítá, tenhle týden už to je potřetí, kdy po ní někdo chce řešit instalaci a konfiguraci dalšího klienta s jiným profilem protokolu a ona už toho má plný zuby, takže se Pepovi na jeho soubory vykašle...

[xkucf03]

Protože konfigurace kernelu mě nomezuje v komunikaci s lidma (vyjma nějakejch specielních případů).

Když si vypneš IPv4 či IPv6, tak bych řekl, že docela omezuje :-)

Pak totiž neplatí předpoklad, že dva lidi, kteří mají na počítači Linux a natáhnou si mezi sebou ethernetový kabel, spolu můžou komunikovat. Součástí předpokladu je totiž i to, že si při kompilaci jádra zapnou oba stejný protokol (nebo klidně oba).

Já ale nechci žádné části specifikace s nikým domlouvat. Tohle vede zase k těm samým problémům.

Tohle řeší ty profily – kdo nad tím nechce moc přemýšlet, tak ať implementuje/použije to, co je definované v profilu doporučeném pro jeho případ užití.

[kralyk z abclinuxu]

Když si vypneš IPv4 či IPv6, tak bych řekl, že docela omezuje

To jsou ty specielní případy. By default je to zapnutý a na desktopu to nemá vypnutý prakticky nikdo. Kdyby to takhle bylo i v tom protokolu, tak s tim nemám problém, jde o to, aby 99% lidí mělo kompletní sadu featur, abych se s nimi mohl bavit a nemusel řešit problémy kvůli 1% modularizačních extrémistů.

Tohle řeší ty profily – kdo nad tím nechce moc přemýšlet, tak ať implementuje/použije to, co je definované v profilu doporučeném pro jeho případ užití.

Ten příklad s Pepou a Lenkou to IMO nijak neřeší.

[xxx]

Nepodcenuj profily. Misto jedne hadky o tom, co ma byt by default podporovano, muzes mit rovnou nekolik paralelnich sporu, o tom co ma byt podporovano v tom ci onom profilu. A jako bonus muzes mit spor o to, jake profily maji byt podporovany by default.

[xkucf03]

Takže navrhuješ co? Jedno velké monolitické API, které budou muset všichni implementovat kompletně, i když využívají jen jeho podmnožinu?

[Josef Kufner]

Že je něco součástí specifikace ještě neznamená, že to musí být podporováno každým. Můžeš mít volitelné features, ale budou součástí specifikace. Klient pak může říct "to neumím", ale bude vědět, co neumí. Výhodou takového přístupu je, že je předem známo, co může chybět a jaké to bude mít důsledky a jak se v takovém případě zachovat.

[xkucf03]

Jak se pak liší a) specifikace s volitelnými částmi (ve vyšších verzích přibudou další volitelné části) od b) základní specifikace a rozšíření? Resp. v čem by měla být rozšíření horší?

[Josef Kufner]

Specifikace říká co všechno v protokolu existuje a jak se zachovat, pokud volitelná část není podporována. Vyšší verze přidá další volitelné části (nebo je upraví či odstraní), ale už v základu je uvedeno číslo verze, takže se ví, čemu daný klient nerozumí.

Rozšíření oproti tomu nemají tu jasně definovanou jednu specifikaci. Některá rozšíření mohou zastarat, mohou být nahrazena jinými rozšířeními, nebo se prostě jen přestanou používat. Výsledkem je nepřehledná situace, kdy nikdo pořádně neví, co přesně je potřeba umět. A i když to zrovna ví, tak za pár měsíců může být vše jinak a musí to sledovat. Pak je také nutné jednotlivá rozšíření sloučit do kompletní specifikace, kterou lze implementovat. V okamžiku, kdy jedno rozšíření mění chování jiného rozšíření a to nějak interaguje s dalším rozšířením, stává se situace značně nepřehlednou.

Například pokud budeme mít protokol pro textový chat později rozšířený o video konference, tak budeme mít základní protokol pro chat a rozšíření pro video. Když klientu bez podpory videa přijde požadavek na video, tak nebude mít tušení, co se děje. Může takový požadavek zahodit či ignorovat, může vrátit chybu, která může či nemusí dávat smysl. Pokud však budeme mít verzovaný protokol s volitelnou funkcionalitou, tak po vydání druhé verze protokolu, která přidává video, se do toho jednoduchého klienta připíše kultivovaná odpověď "video neumím" a chování bude hezky definované. Lze předpokládat, že protokol bude do jisté míry zpětně kompatibilní, takže oznámení podporované verze protokolu bude implikovat "video neumím".

Zrovna tento příklad je vcelku rešitelný i s rozšířeními, ale u složitějších věcí se může měnit význam a workflow některých komponent. Například XEPy Message Carbons, Message Archive Management, a Stream Management výrazně mění fungování Jabber klientů – mění se způsob práce se spojeními, příjem zpráv, načítání historie. Různé kombinace těchto rozšíření pak znamenají trochu jiné chování. Navíc některé funkce se částečně duplikují (např. stream management fronty do jisté míry duplikují message archive) a jiné upravují chovaní základu protokolu (např. časy u zpráv). Pak se do toho přidají různé bugy v různých implementacích a o zábavu je postaráno.

Jedna specifikace s volitelnými features by byla jednodušší, přehlednější a v důsledku by bylo méně chyb v implementacích.

[kralyk z abclinuxu]

Takže navrhuješ co? Jedno velké monolitické API

Ano, jistě.

které budou muset všichni implementovat kompletně, i když využívají jen jeho podmnožinu?

Ne. Když někdo nechce něco implemnentovat, třeba nějakou část protokolu, tak ať ji neimplementuje. Pro mě za mě. Akorát pak prostě jeho SW nedostane ten štempl "podporuje protokol X". Může tam třeba uvést "podporuje část protokolu X, funguje to a to a nefunguje to a to, protože to nepoužívám". Proč ne. Ale to označení "podporuje protokol X" by mělo být vyhrazeno pro ten SW, který to implementuje komplet. Bez toho nastane ta situce, že když se sejdou lidi a budou si chtít popovídat protokolem X, půlce z nich nebude fungovat půlka funkcionality...

[xkucf03]

Už to tu píši několikrát – tohle řeší ty profily. Můžeš mít minimalistický základ, který lze použít jako podkladový protokol pro něco jiného nebo pro základní textový chat. Pak druhý profil pro vylepšený chat mezi lidmi. A pak třeba třetí, který k tomu přidává hlas a video-hovory.

Místo, abys říkal „podporuje protokol X“, tak akorát řekneš „podporuje profil A protokolu X“. Rozhodně je to lepší než někam psát:

podporuje část protokolu X, funguje to a to a nefunguje to a to, protože to nepoužívám

[kralyk z abclinuxu]

Už to tu píši několikrát – tohle řeší ty profily.

A já už několikrát píši, že neřeší

Místo, abys říkal „podporuje protokol X“, tak akorát řekneš „podporuje profil A protokolu X“. Rozhodně je to lepší než někam psát:

podporuje část protokolu X, funguje to a to a nefunguje to a to, protože to nepoužívám

Z mého pohledu je to řešení z těma profilama striktně horší, protože vede k fragmentaci.

[Josef Kufner]

Linux, v tomto kontextu tedy jeho API, je právě případ té podpory rozšíření à la XEP. Podle toho, co si zakompiluješ, to bude umět, ale také na jednotlivé funkce budeš potřebovat různé specializované klienty. Tomu sorvnání s XMPP by odpovídalo API "vše je soubor", kde sice máš jeden soubor pro disk a druhý pro zvukovku, ale Alsa ti je k prdu, když potřebuješ upravit tabulku oddílů. Stejně tak když jeden klient umí XEP-0096, druhý XEP-0234, třetí XEP-0052 a čtvrtý XEP-0363, tak sice všechny umí přenášet soubory, ale je ti to taky k prdu (i když tím čtvrtým alespoň můžeš poslat soubory ostatním).

[kralyk z abclinuxu]

To je krátkozraká představa. Že někdo navrhne dokonalý protokol, který nebude třeba nikdy rozšířit. Kvalitní protokol se používá věky právě proto, že jak se mění svět, protokol se doplňuje a žije dál. Bohužel dnes je moderní místo evoluce dělat revoluce (...)

To je ortogonální otázka. Žádný protokol samozřejmě není vytesaný do kamene a je dobrý když se vyvíjí, ať už evolučně nebo revolučně (obojí má svoje místo).

Ten problém s XMPP byl, že v základu toho měl příliš málo a příliš mnoho nechával na rozšířeních, takže pak efektivně vlastně žádný standard neexistoval...

[xkucf03]

Tam byl AFAIK problém v tom, že některé úlohy šlo řešit několika způsoby (několik konkurujících si XEPů), což pak vedlo k tomu, že programy sice řešily stejnou úlohu (z hlediska uživatele poskytovaly stejnou funkci), ale každý jiným způsobem, takže si spolu nerozuměly.

Tohle riziko u rozšiřitelných technologií/systémů je (zvlášť pokud jsou navržené tak, aby je mohl rozšiřovat kdokoli, aniž by se musel dovolit nějaké autority), ale pořád mi to přijde lepší než nerozšiřitelný nemodulární systém. Buď tu můžeš mít nějakou autoritu, která vybere „jediný správný způsob“ jak něco dělat (přesto ale ten systém může být rozšiřitelný a v základu jednoduchý) nebo definuje nějaká doporučená rozšíření formou profilů nebo se to může nakonec rozhodnout živelně a evolučně (některá rozšíření se ujmou, jiná ne, případně programy můžou podporovat více variant a za běhu se vždy domluvit s druhou stranou na tom, co podporují oba – to se dělá např. při výběru šifrovacích algoritmů při navazování spojení nebo třeba v HTTP při domlouvání jazyka či kompresního algoritmu).

Zrovna XMPP se dá používat jako obecný protokol pro posílání zpráv, klidně na tom můžeš postavit API pro propojení dvou systémů (tzn. komunikují spolu jen stroje, ne člověk). A v takovém případě tě třeba vůbec nezajímá nějaký VoIP nebo posílání souborů a není důvod, aby tě specifikace nutila tyhle věci implementovat.

Nebo z úplně jiné oblasti: lidská řeč – na to, aby sis např. objednal jídlo nebo se zeptal na cestu, nepotřebuješ znát celý jazyk a terminologii ze všech oborů – stačí ti umět relevantní podmnožinu.

[Josef Kufner]

XMPP bylo postaveno jako jednoduchý základ pro posílání zpráv a řekl bych, že celkem povedený (až na nějaké drobnosti, jako třeba že to v základu ztrácí zprávy). Problém je v tom, že ten protokol nad tím už se moc nepovedlo uřídit. Sice to nějak tak funguje, ale … jen tak nějak.

[kralyk z abclinuxu]

a za běhu se vždy domluvit s druhou stranou na tom, co podporují oba – to se dělá např. při výběru šifrovacích algoritmů při navazování spojení nebo třeba v HTTP při domlouvání jazyka či kompresního algoritmu

Tohle se ale děje pro uživatele v podstatě transparentně a musí to fungovat, selhání TLS handshake je považováno v praktické situaci za chybu.

Zrovna XMPP se dá používat jako obecný protokol pro posílání zpráv, klidně na tom můžeš postavit API pro propojení dvou systémů (tzn. komunikují spolu jen stroje, ne člověk).

Jakože bych v rámci XMPP znovuvynalezl TCP nebo něco takovýho?

[xkucf03]

Tohle se ale děje pro uživatele v podstatě transparentně a musí to fungovat, selhání TLS handshake je považováno v praktické situaci za chybu.

Však třeba u toho posílání souborů to taky může fungovat transparentně – klienti se budou snažit dohodnout na co nejefektivnějším způsobu posílání a když se nedohodnou, tak si to pošlou přes XEP-0047: In-Band Bytestreams. A kdyby selhalo i to, tak se teprve ohlásí chyba.

Jakože bych v rámci XMPP znovuvynalezl TCP nebo něco takovýho?

Nikoli. XMPP je obecný protokol pro posílání zpráv, nemusí se používat jen pro IM mezi lidmi. Jmenuje se to Message-oriented middleware (další klíčové slovo je Message broker). A jako protokol je to o úroveň výš než TCP – na stejné úrovni jako AMQP, STOMP, MQTT a další protokoly pro posílání zpráv. Můžeš tím implementovat vzory Point-to-Point nebo Publish–subscribe. Tohle jsou věci, které TCP neřeší. Na Point-to-Point bys maximálně mohl použít SCTP, které je na stejné úrovni jako TCP, ale musel bys adresovat přes IP adresy a porty (zatímco v XMPP adresuješ přes JID + tam máš federaci přes víc serverů/domén).

[kralyk z abclinuxu]

Však třeba u toho posílání souborů to taky může fungovat transparentně – klienti se budou snažit dohodnout na co nejefektivnějším způsobu posílání a když se nedohodnou, tak si to pošlou přes XEP-0047: In-Band Bytestreams. A kdyby selhalo i to, tak se teprve ohlásí chyba.

Nevzpomínám se, že by to takhle u XMPP fungovalo.

Nikoli. XMPP je obecný protokol pro posílání zpráv, nemusí se používat jen pro IM mezi lidmi. Jmenuje se to Message-oriented middleware (další klíčové slovo je Message broker). A jako protokol je to o úroveň výš než TCP – na stejné úrovni jako AMQP, STOMP, MQTT a další protokoly pro posílání zpráv.

Wtf. Matrix ti přijde složitý, ale přitom řešíš, že by IM/diskusní protokol mohl sloužit taky jako protokol pro MQs...

[xkucf03]

Matrix ti přijde složitý, ale přitom řešíš, že by IM/diskusní protokol mohl sloužit taky jako protokol pro MQs...

Na tom není nic zvláštního. IM (diskuse mezi lidmi) jsou vlastně jen speciální případ posílání zpráv. Obecné posílání zpráv je tedy nízkoúrovňový koncept, na kterém lze postavit řadu aplikací mj. i ten chat mezi lidmi. Je to asi jako kdyby ses pohoršoval nad konceptem souborů kvůli tomu, že do nich lze ukládat obrázky i texty. Ano, soubor je nízkoúrovňový koncept a lze ho použít k více účelům – to ale neznamená, že by byl nějak přehnaně komplexní.

[kralyk z abclinuxu]

Je to asi jako kdyby ses pohoršoval nad konceptem souborů kvůli tomu, že do nich lze ukládat obrázky i texty.

Ne, není, je to jako kdybych se pohoršoval, že daotvý formát pro obrázky řeší zároveň obecné otázky ohledně filesystémů, smyslu života a vůbec...

Já myslim, že další diskuse asi nemá smysl, máme na tohle zřejmě příliš jiný názor...

[j]

Jako ze dam delanasovi krumpac a reknu mu ze lopata jako lopata ze?

Kdyz si chci s nekym pokecat, tak kupodivu potrebuju, aby online byl. Kdyz snim kecat nechci, tak ma email. IRC je pak primarne o hromadnym pokecu N lidi. Ty zjevne pak naprosto nechapes, ze IRC neni a nikdy nebylo o komunikaci dvou osob. IRC funguje presne stejne jako hospoda, kam vlezes, a poklabosis s tema, ktery tam sou. Divny co? A ty se rozcilujes, ze kdyz v ty hospode budes hodinu mluvit do zdi, ze pak tu komunikaci neuvidi tvuj znamej, kterej tam obcas sedi ...

[kralyk z abclinuxu]

A ty se rozcilujes, ze kdyz v ty hospode budes hodinu mluvit do zdi, ze pak tu komunikaci neuvidi tvuj znamej, kterej tam obcas sedi ...

Ano, protože je to zjevná nevýhoda. Viz třeba situace, kdy se třeba sejde 5 lidí a něco si řeknou a pak přijdou další 2 o hodinu později a je potřeba jim sdělit, co se dělo, aby byli v obraze. Na IRCu bez dalšího se jim to bude muset znova odvykládat nebo překopírovat nebo si to budou muset tahat odněkud z logu...

Jako dlouholetý uživatel IRC vim, že stejně si tam tu historii lidi obvykle nějak dodaj, např. běží IRC klienta non-stop na serverech nebo sdílí logy apod., takže to tvoje přirovnání s hospodou stejně v praxi často neplatí.

[Peter Golis]

Na IRC kanáloch viseli aj kvôli tomuto Boti.

[abc]

Ty zjevne pak naprosto nechapes, ze IRC neni a nikdy nebylo o komunikaci dvou osob. IRC funguje presne stejne jako hospoda, kam vlezes, a poklabosis s tema, ktery tam sou. Divny co?

To s tou hospodou je docela fajn prirovnani. Ale komunikacni potreby organizaci jsou trochu jinde - IRC Mozilly se nepouziva jen na nezavazny pokec, ale vedou se tam i zajimave/dulezite diskuse ktere by se nemely jen tak ztratit, lidi tam anoncuji ruzne veci atp. IRC model "hospoda" je pak pro takove pouziti proste nevhodne a v minulosti se pouzivalo spis proto, ze nic lepsiho nebylo.

[j]

"komunikacni potreby organizaci" "nic lepsiho nebylo" ???

Webovy diskusni forum je vec jak stara, 30 let? Mailova konference jeste starsi ...

To IRC provozovali prave a jen a pouze jako tu hospodu, ve ktery muzes schodou okolnosti potkat lidi z nejaky firmy. Kdyz potkam v hospode svyho dodavatele, tak s nim dam to pivko, a mezi reci se ho trebas zeptam, kdy mi dodaj co sem si objednal, ale rozhodne to neni jakkoli oficielni/zavazna komunikace.

A je to jen a prave o tom, ze si pokecam prave ted.

[abc]

Webovy diskusni forum je vec jak stara, 30 let? Mailova konference jeste starsi ...

No a ty platformy jako Zulip jsou proste evoluci techto konceptu. Co je na tom spatneho?

To IRC provozovali prave a jen a pouze jako tu hospodu, ve ktery muzes schodou okolnosti potkat lidi z nejaky firmy. Kdyz potkam v hospode svyho dodavatele, tak s nim dam to pivko, a mezi reci se ho trebas zeptam, kdy mi dodaj co sem si objednal, ale rozhodne to neni jakkoli oficielni/zavazna komunikace.

A je to jen a prave o tom, ze si pokecam prave ted.

No ocividne to v Mozille vidi jinak a chteji z toho mit vic nez hospodu.

[kralyk z abclinuxu]

No a ty platformy jako Zulip jsou proste evoluci techto konceptu. Co je na tom spatneho?

Nic, to akorát pro uživatele `j` je špatné skoro cokoliv na skoro čemkoli...

[xkucf03]

Já se nad tím moc nerozčiluji, ale víceméně je to důvod, proč jsem IM (téměř) přestal používat. Nechci vysedávat celý den v jakési virtuální hospodě, nechci, aby mi tu vyskakovalo okno a rušilo mne od práce, kdykoli v té hospodě někdo něco plácne. IM mi dává smysl spíš v případě, kdy se dohodnu na konkrétní schůzce (je jedno, jestli ve dvou nebo ve více lidech) v určitý čas a něco konkrétního tam (synchronně) prodiskutujeme.

Daleko lépe fungují i diskuse tady na Ábíčku – jsou členěné podle témat (jednotlivé články, zprávičky, blogy, dotazy v poradně…) a v rámci nich jsou vlánka, takže je hezky vidět, kdo na co reaguje. Používají se citace. A snadno poznám nové zprávy od mojí poslední návštěvy (s tou drobnou vadou, že jakmile nějakou stránku otevřu, „označí“ se všechny příspěvky jako přečtené, ale s tím se celkem dá žít). Když budeš chtít diskutovat online a téměř synchronně, tak stačí po odeslání příspěvku kouknout, co napsali ostatní – resp. ten systém k tomu svádí a často zdejší diskuse vypadají jako chat.

[Ovoce]

no IRC je teda vrchol jednoduchosti. Jak si treba _jednoduse_ precist zpravy mne poslane, kdyz jsem byl offline?

Naprostý souhlas, lidi zase automaticky kafraj, protože je řeč o Mozille.

Ale co je kurník těžkého na pochopení, že pro potřeby SW projektu by to chtělo něco jako IRC, ale s tím, že vám dojdou PM a historie hlavnícho chatu i z doby, kdy jste byli offline? Hrůzo! Že to IRC neumí není proto, že by to byla debilní věc pro lamy, ale proto, že IRC vzniklo před víc jak 30 lety, kdy prostě byli lidi rádi, že maj aspoň ten holej základ komunikace.

Přímé vkládání obrázků/souborů z klienta bez laborování s uploadem někam a linkováním prostě šetří čas a určitě by se daly na IRC-like rozhraní nalepit i další věci pro usnadnění/zvýšení produktivity.

Ale, ne musí se brblat, že se mělo použít horší legacy řešení, protože je to piitomá Mozilla a protože chci bejt chytrej jak rádio.

Já mám taky IRC velmi nostalgicky rád a používám ho, ale jsou prostě věci, kdy je tu větší komplexitu klientů lepší akceptovat, protože to stojí za to. V práci taky používáme ke komunikaci něco novějšího než IRC.

[j]

Takze protokol, pro kterej existujou tisice klientu, nahradime necim, o cem nikdo nikdy vzivote neslysel ... jooo, to urcite zafunguje.

[_]

Dobre veci se za zachvili prodavaj samy.

[tuxmartin]

Kdyz uz nemuze byt IRC, tak proc ne treba XMPP/Jabber? Podporuje MUC (XEP-0045: Multi-User Chat). Klientu je spousta. Je to relativne stary, osvedceny a normovany protokol.

[Josef Kufner]

Jabber má docela podstatnou nevýhodu v tom, že pokud si správně nenamícháš XEPy, tak ztrácí zprávy a neumí posílat soubory.

[Roman]

jo, kazdy klient umi jinou mnozinu XEPu a ruzne dobre

[joejoe]

Otazka je jestli se tento problem neda vyresit tim, ze se standardizuje vycet povinnych XEPu.

Ostatni instant messaging sluzby na tom bohuzel nejsou lip. Napriklad telegram klient pro Sailfish neumi supergroups. Kdyz jsem naposledy zkousel Androidi whatsapp, tak se mi nepodarilo pripojit. Jabber klienta pro mel i v J2ME na starickem Siemens C65.

[Josef Kufner]

Otazka je jestli se tento problem neda vyresit tim, ze se standardizuje vycet povinnych XEPu.

To by asi šlo, ale muselo by se chtít a bylo by potřeba mít autoritu, která by to dokázala prosadit a dokopat klienty, aby to implementovaly.

[xkucf03]

To se obvykle řeší tak, že se zúčastněné strany¹ sejdou a nějak se dohodnou – ostatně je to jejich společný zájem (chtějí, aby se např. daný protokol rozšířil a lidé nepřešli někam jinam).

_{[1] autoři klientů, serverů, poskytovatelé služeb atd.}

[Josef Kufner]

Což ale předpokládá nějakou motivaci to řešit. Takže nakonec přijde někdo, kdo má prostředky a motivaci na vývoj a nějak to udělá. Ostatní mu do toho jen kecají a vezou se. Takto přišel Google s HTTP2 a bylo.

[rastos]

Nicméně IRC i servery zastarávaly ...

Vie niekto vysvetliť, čo to vlastne znamená? Nemajú dostatočný synergetický efekt proaktívnej parelelizácie v cloude alebo čo?

[billgates]

Na mlady a dynamicky kolektiv je tam prilis vela pismenok a malo animovanych gif, takze uplne nepouzitelne.

[xxx]

Tezko ric, IRC si pmatuji z doby, kdy frcel mIRC a BitchX. Nice v kontextu dnesni doby. Jak se tam da do kanalu pastnout treba obrazek, textovej log nebo treba nejakej binarni soubor?

[kralyk z abclinuxu]

Jak se tam da do kanalu pastnout treba obrazek, textovej log nebo treba nejakej binarni soubor?

Nijak.

[rastos]

Súbor dáš na svoj server a do kanálu pastneš link. Čo? Ty nemáš svoj server? Pri odchode odovzdaj svoj členský preukaz ...

[kralyk z abclinuxu]

On je to opruz i s vlastním serverem...

[xkucf03]

Tohle může z větší části řešit IRC klient - klidně bys do něj mohl soubor přetahovat myší nebo vkládat přes schránku a on by ho nahrál na tvůj server a ostatním poslal URL. Na straně příjemce by ten klient zase mohl zobrazovat náhledy, pokud URL odpovídá nějakému regulárnímu výrazu.

Totéž by šlo dělat s ukázkami kódu nebo dalšími formáty/médii. Bot, který loguje, tak tyhle odkazy může vyhledávat a archivovat.

Ano, je to takový bastl, ale proveditelné to je a to i bez jakýchkoli změn protokolu (takový XMPP by na to byl vhodnější, protože ten se dá rozšiřovat a řadu věcí už umí) a s minimálním navýšením komplexity.

[xxx]

Takova vec uz existuje. Prej se to jmenuje Slack, a ani nemusis mit vlastni server.

[xkucf03]

Když už, tak Zulip (Slack je proprietární software/služba).

[xxx]

Whatever

[abc]

Ano, je to takový bastl, ale proveditelné to je a to i bez jakýchkoli změn protokolu (takový XMPP by na to byl vhodnější, protože ten se dá rozšiřovat a řadu věcí už umí) a s minimálním navýšením komplexity.

S minimalnim navysenim komplexity pro koho? Pro uzivatele urcite ne ...

[BoneFlute]

Mozilla na mě začíná působit extrémně progresivním dojmem. Nejdřív Rust, pak FluentProject, teď Matrix. Jako docela respekt. Fandím.

[-]

klient pro GNOME