Milyen lehet az email utáni világ?

Ezzel a kérdéssel indít egy IT World cikk, és aztán jönnek a válaszra esélyes megoldások: Facebook, Twitter, Google Wave (a koncepció, mármint), satöbbi, satöbbi.

A kérdésfeltevés helytelen, az email jelenlegi formájában nem tud kimúlni, és azt is megmondom miért: azért, mert a technológiát még egy olyan világban dolgozták ki, ahol a profit másodlagos volt a felhasználhatóság, pontosabban az interoperabilitás mögött. Magyarul: az email egy olyan nyílt szabvány, amit az implementál, aki akar. A cikkben felmerülő lehetséges válaszok pontosan arra világítanak rá, hogy ma nincs ilyen, ma szolgáltatók vannak, üzleti érdekekkel, akik több vagy kevesebb elszántsággal (és sikerrel) walled garden-t építenek. Nekik nem céljuk, hogy legyen egy szabvány, amit mindenki használ, nekik az a céluk, hogy legyen egy általuk gründolt szolgáltatás, amit mindenki használ — ez pedig nem ugyanaz, nagyon nem.

Összehasonlításképpen, az email nagy vonalakban egy pár darab RFC: az SMTP (RFC 821, illetve RFC 2821), az IMAP (RFC 3501), és a POP3 (RFC 1939) összessége. (Most itt nagyvonalúan elsiklok a POP3 before SMTP, meg hasonló extrák fölött, mert nem vágom fejből a számukat.) Ezeket a protokollokat az IETF tartja karban, egy nonprofit, az internetért dolgozó, és nem azon leechelkedő szervezet. És bár az RFC dokumentumok nem esnek “free” licensz alá (ennek is komoly irodalma van), az RFC-k tiszta, átlátható dokumentumok és nem változnak. Csinálnál saját mail szervert? Go ahead, ott a protokolldoksi, valósítsd meg, aztán hajrá. Csinálnál klienst? Detto, ott a doksi, csináld meg. (Csinálják is sokan.)

Ehhez képest egy Facebook Connect, egy Twitter Oauth, egy szolgáltató, vagyis egy profitorientált cég által karbantartott API-k, teljesen zárt licensszel (Terms of Use), amit bármikor kényük-kedvük szerint változtatnak. (Az RFC 821 1982 óta nem változott. Az Oauth ha jól emlékszem, úgy 2 hete.) Ami nem változik, az a hozzáállás: Facebook Connect-tel sose fogsz saját Facebook node-ot megvalósítani, Twitternél detto, a lényeg mindig az, hogy az adatod náluk, a szolgáltatónál maradjon, és lehetőleg ne lehessen egyszerűen átemelni, metásítani másik szolgáltatásban. Klienst megvalósíthatsz, de meglehetősen korlátozott funkcionalitással, gyakorlatilag slave-ként üzemelve az anyaszolgáltatás emlőin.

Ezzel persze semmi baj nincs, ha akként tekintünk ezekre a csökevényekre, amik: kommunikációs technológia helyett szolgáltatások. Ja, és: ha nem említjük egy lapon őket az emaillel.

Összefoglalva: a mai szolgáltatások “connect” API-jainak az a célja, hogy használatukkal még több adat folyjon be a szolgáltató adatbázisába és ezzel növelje az adott cég reklámozási képességeit, értékét. Az emailhez kapcsolódó protokollok célja az (volt), hogy az emberek tudjanak egymással kommunikálni.

Vannak kísérletek ma is interoperábilis technológiák, szabványok létrehozására, némelyiket használja is egy-egy szolgáltató. Az XMPP jó példa, a Google implementációjával még talán el is érem a jabber.org-os buddykat (asszem, de nálam okosabb emberek majd megtrollkodják ezt a mondatot kommentben). Az OpenID meg egy másik, csak azt meg a kutya nem használja. De persze ezek is csak addig jók, amíg nem implementálja a szolgáltató — kis módosításokkal. A Google Talk accountommal biztosan nem fogok tudni kommunikálni a Facebookos haverral, pedig mindkettő XMPP. Az OpenID lényege az lenne, hogy bárhova be tudjak jelentkezni akár egy saját OpenID authority által adott referral-lal — de ha minden igaz, már a Google se engedi ezt, csak néhány “trusted” szolgáltatót. (De megintcsak: javítsatok ki. Vidítsatok fel.)

Mi lesz az email után? Nem tudom. Azt látom, hogy ma semmi sincs még a közelében sem annak, hogy kiválthassa az emailt. Az egyszerű használhatóság (ami ugye a mai startup vonal Szent Grálja) szart sem ér, ha zárt a szolgáltatás. Márpedig manapság általában zárt.

7 hozzászólás “Milyen lehet az email utáni világ?” bejegyzéshez

  1. Ha jol emlekszem az rfc nem is fog valtozni, mivel az rfct csak egy magasabb szamu rfc modosithatja…

  2. Az email tenyleg nem fog valtozni ahogy te is irod mert az egy szabvany. Ami valtozni fog az a felulet amin hasznaljuk. Lasd Gmail, probaltal mar egy thunderbirdot hasznalni utana? Pain in the ass. Ide lehetne emelni a Sparrow klienst macre ami nagyon jo, vagy a Zeromail nevu uj startupot.

    Nekem az a feature hianyzik pl hogy tudjak mergelni threadeket ne csak szetbontani.

  3. @Utas jól emlékszel (ha jól emlékszem), de még a 2821-es RC, ami obszolálja a 821-et, az is asszem 2001-ben jött ki. szóval érted amit mondani akarok… értem én, hogy API-t verziózni meg evolválni jó a haladás szempontjából, de hosszútávon káros az implementációkra nézve.

  4. “Az OpenID meg egy másik, csak azt meg a kutya nem használja.”

    Olyan kis nevek hasznaljak, mint a Stackoverflow, SourceForge, Novell, szinte minden Drupal oldal tamogatja, a Google is erre epiti a SSO technologiajat, a Verisign OTP alapu OpenID hitelesitest nyujt, a MyOpenID meg tanusitvany alaput. Bagatell.

    Az OpenID-t nem csak az implementalja, aki akarja, hanem nagyon sokan implementaljak is, integraljak a sajat szolgaltatasukba, elsosorban mint consumerek (SourceForge, StackOverflow), de providerek is vannak szep szammal (tessek megnezni a StackOverflow OpenID belepteto kepernyojet, ket-harom hosszu sorban listazza a providereket a rendszer).

  5. Az OpenID-nal amugy providert valasztani tudni kell. A Verisign sajat providere pl. barhova enged regelni, menedzselheted, hogy mit engedsz/tiltasz nekik, a regisztracio folyamataba bele tudsz lepni, szabalyozhatod, mely oldal, milyen informaciokhoz jusson a providertol. Egyszoval a Verisign azt nyujtja, amiben profi: biztonsagot.

    A Google OpenID provideret ugy tudom, eleg sok helyen lehet hasznalni, bar azt nem tudom, hogy mik a korlatjai. A Novellest tudom, hogy csak a Novell cuccai hasznalhatjak. De amugy a Google ID-n nem lehet olyan nagy korlat, mert nagyon eldugott kis oldalak is adnak Google OpenID auth lehetoseget.

    Summa summarum: OpenID szolgaltatot az ember ugy valaszt, mint email szolgaltatot: bizalom, es a szolgaltatas minosege. Suru tomott sorokban allnak es kuncsorognak a szolgaltatok a userek kegyeiert, szoval a valasztek nagyon boseges, nem vagy egy providerhez lancolva.

  6. Elképesztő ez a Facebook őrület ez lenne a jövő akkor nem kérek belőle. Az e-mail azért kicsit más kategória szerintem. A sok idióta mindent megoszt magáról (elnézést nem tudok jobb szót rá). Könnyebb egy az adatokból a profil elkészítése. Én személy szerint maradok az elavult e-mail technológia boldog felhasználója.

Hozzászólások lehetősége itt nem engedélyezett.