Oh my goodness, I can't believe nobody found the time to translate this document yet. Please do! In the meantime the whitepaper should answer most questions.

Grundsatzdiskussion

Why this hasn't been done before is because there must be a very good reason against it.

False: All things have a beginning. And not doing things just because others before you haven't done those things is no reason not to do them or make excuses why not to do them.

Wenn PSYC die Antwort auf alle Fragen ist, warum kennt es keine Sau?

Dieselbe Frage habe ich mir auch 1990 gestellt, als eine Handvoll Firmen ins Internet gingen und per E-Mail erreichbar waren. Ich fragte mich warum nicht die gesamte Wirtschaft E-Mail und FTP verwendet um effizienter zu kommunizieren und Daten auszutauschen als mühsam per Fax oder Modem? Fünf Jahre später machte mich ein Bekannter auf MP3 aufmerksam. Ich schrie Juchei und sagte den Redakteuren vom stern, das wird 'ne ganz große Nummer. Die meinten: Nein, das ist viel zu kompliziert - das bleibt eine Liebhabersache für Computerfreaks. Manchmal braucht es halt seine Zeit, bis der Groschen fällt. Sicherlich ist es von Vorteil wenn der Einstieg leicht ist, sich gut anfühlt und toll aussieht. Da sind wir dran. Und dann könnte man noch Marketing machen. Iih, Marketing! ;°)

Betrieb des psyced

Ich finde XML vollkommen ungeeignet für Chatprotokolle. Kann ich PSYC auch ohne XMPP- und Jabber-Gedöns betreiben?

Ja, es reicht schon keine Kommunikation mit XMPP-Anwendern zu führen, und die entsprechenden Module werden gar nicht erst von der Festplatte geladen. Man kann auch einen Schritt weiter gehen, und den XMPP-Port einfach abschalten. Es liegt also in der eigenen Hand, das XMPP Protokoll als wichtige Schnittstelle zwischen den Systemen zu betrachten, oder als technologische Entgleisung im Umfeld der Überbewertung der XML-Syntax. Wir unterstützen grundsätzlich beide Meinungen.

Ich finde IRC recht unpassend für ein Messaging-System, kann ich diese alte Technologie bei mir ausklinken?

Genauso wie bei XMPP, aber wozu? Es gibt so viele Menschen, die gerne mit ihren IRC-Clients aktiv bleiben wollen. Sollten sich dennoch keine IRC-User einfinden, dann werden auch in diesem Fall die IRC-Module gar nicht erst in den Speicher geladen.

Sicherheit und Privatsphäre in PSYC

ich als user moechte nicht, dass der server meine ip-adresse an irgendjemanden rausrueckt, der mit mir chatten moechte. so wie ich das verstanden habe, gibt einer ein psyc://die.server.ip/~mc und der server rueckt meine richtige IP raus, und den port auf dem mein client listened...

das kann dein server entscheiden wie du es willst. das normalverhalten sollte sein: freunden gebe ich meine ip direkt. "feinde" werden gefiltert. unbekannte werden durch den heimserver versorgt, damit sich mein user später entscheiden kann, ob das ein freund ist. diese logik ist aber an sich nirgendwo festgenagelt, du kannst also auch aus prinzip niemandem vertrauen, oder du kannst so tun als seiest du niemals online. psyc erlaubt -im gegensatz zu datenbankbasierten buddylistsystemen- zu lügen - ganz wie im echten leben kann man für uwe da sein und für zora nicht zu sprechen.

im prinzip koennte doch jeder daherkommen und sagen, hallo ich bin joe, ich bin in deiner friendlist, ich floode dich jetz n bisschen und du denkst ich bin joe, dabei bin ich in wirlichkeit jack

der client soll unerwuenschte messages per default ignorieren. erst wenn jemand sagt er sei XY und der server von XY bestaetigt das: ja, das ist wirklich XY dann werden seine nachrichten verarbeitet. im normalfall spricht die person sowieso erstmal mit dem heimserver des anderen. dieser kontrolliert sofort dessen id und wenns die richtige person ist schickt er die nachricht weiter an den client und der person die aktuelle adresse des clients, falls direktkommunikation erwünscht ist.

oki. und woher weiss der "heim"-server von joe, dass joe wirklich joe ist u nd nicht jack? weil sich joe bei ihm authentifiziert. default wie üblich mit Klartext-Passwort, aber es gibt ja bereits SSL/TLS-geschützten Zugang zum psyced.

Gruppenkommunikation mit PSYC

ich moechte schon ein "channel"-konzept haben, allerdings serverbasiert, und nicht, dass jeder client dann jedem anderen client in der "gruppe" eine kopie schicken muss.

PSYC hat was das betrifft überhaupt keine Festlegung, durch das veraltete Whitepaper (Wir müssen das mal auffrischen!) entsteht der Eindruck PSYC wäre eine reine peer-to-peer-Technologie. P2P war damals noch so exotisch, dass wir das erst erklären mussten. PSYC ist aber mitnichten zwingend P2P. Genaugenommen gibt es nur wenige Clients die experimentell so etwas in der Art unterstützen. Der Realzustand ist, dass die meisten Räume nur auf einem bestimmten Server existieren, oder mit anderen psyced ein IRC-artiges Netzwerk bilden. Dies wird in Junctions erklärt. Dies ist nur ein Zwischenstand auf dem Weg zum eigentlichen PSYC Conferencing, aber schon dieser Ansatz hat IRC gegenüber den Vorteil, dass jeder "Channel" sein eigenes optimiertes Baumnetz durch das PSYC-Universum konstruieren kann, und dies nicht vom IRC-Netz vorgegeben ist, mit den daraus resultierenden Nachteilen. In PSYC kann man jedenfalls viele Verteilungsstrategien ausprobieren, der Verwalter eines Raumes/Channels kann es sich aussuchen wie dieser funktioniert, und man kann beliebig Hybride konstruieren. Also beispielsweise ein Raum in dem eine Handvoll Leute direkt untereinander reden, der Rest aber zentral vom Hauptserver versorgt wird. Ja sogar "IP Multicast" könnte eingebunden werden, was für Radio/TV-artige Kanäle sinnvoll wäre.

das heisst, man kann festlegen, auf welchen servern der "raum" laeuft?

der raum hat eine network identification, das ist eine "url" psyc://bei.mir.de/@partyraum. da schickt der client seinen join hin, oder der heimserver des users tut es, join heisst _request_group_join. man bittet um einlass. nichts ist garantiert. der raum kann tun was er will. person weiterleiten an anderen server, person sagen, ok ich bin dein raum, schick mir alles was du hast, oder, ich bin dein raum, aber du sollst folgenden personen direkt zuschicken. oder schick's mir, schick's deinem ip-multicast-proxy, und schicks noch uwe und petra von hand.> was der client dann tut ist wiederrum dem user überlassen.. wenn er petra nicht mag, dann kann er sie "aktiv" ignorieren. so sieht es jedenfalls die reine lehre vor.. total flexibility.

<nopcode> hey bei psyc... wenn man sagt "der raum kann einen reinlassen oder
          nicht, frei programmierbar" aber WER macht das dann ? eine gruppe
          von clients die in dem raum sind ? der home server von dem raum ?
          oder was ?
<BitKoenig> nop: das programm des raumes :)
<nopcode> bitkoenig =) aber WO soll das programm rennen ? auf ner VM im
          raumserver ?
<BitKoenig> nop: sozusagen
<nopcode> bitkoenig mhhh krass :)
<BitKoenig> nop: denkbar ist vieles - z.b. koennte der betreiber des servers
            verschiedene konfigurierbare channelprogramme anbieten
<BitKoenig> sozusagen "standard-channels"
<nopcode> hm ja. hauptsache ist der server machts darum gings
<lynX> die programme als "agenten" in der sandbox eines gastservers zu betreiben
  ist nur eines von *vielen* möglichkeiten einen psyc-raum zu realisieren
<nopcode> lynx: ja aber wohl die flexibelste oder ?
<lynX> das ist sogar eines der kompliziertesten, eventuell auch flexibel
    ja kein zweifel. aber es geht auch ganz banal: du koenntest einen irc-bot
    nehmen und den ein bisschen umschreiben zum psyc-channelmaster.
    bots sind in psyc keine belastung, sondern sinnvolle agenten.
 1. ein programm kann eigenstaendig listen auf port 4404 machen und einen
    channel implementieren, beispielsweise in perl mit der Net::PSYC lib.
 2. ein server kann eine sprache oder methode anbieten raeume zu scripten
    oder zu hosten. der psyced erlaubt jetzt schon programmierbare raeume,
    einfach dadurch, dass sie "inherit standardraum" machen.
    und du anschliessend in LPC deine eigene behaviour reinprogrammierst.
 3. ein server kann fertige programme anbieten die man per /-befehl oder
    web-interface konfiguriert.

Buzzword compatibility in PSYC

PSYC hat ja eine recht ungewohnte Syntax. Warum nicht XML?

XML ist kein Format fuer Protokolle. XML ist parametrisch, was immerhin besser ist als corba zB aber psyc hat auch hierarchien in den methoden und attributsnamen drin, wodurch man "inheritance" auf protokollebene machen kann. Zudem hat XML keine Standardlösung zur Einbettung von Binärdaten (ein GIF etwa). Die Ersatzlösungen sind da eher rechenintensiv und bandbreitenunfreundlich (escapen, uuencoden etc). PSYC kann stattdessen genauso wie HTTP einfach sagen die nächsten n Bytes sind Binärdaten, und schon ist die Sache erledigt. Ironischerweise kann man deshalb XML-Dateien mit PSYC ohne jegliche Änderung übertragen, während man in einem XML-basierten Protokoll sämtliche XML-Sonderzeichen escapen muss. Das kostet Rechenzeit und liest sich dann sicher auch ganz super. Mehr dazu in http://html.pages.de/onXML/. Die ungewohnte Syntax von PSYC wird in den Spezifikationen erklärt. Im Prinzip ergab sie sich recht automatisch daraus die übliche Header-Syntax der meisten Internet-Protokolle (RFC822) erweitern zu wollen um Veränderungen von Werten (+,­ und = statt einfach nur :), sowie das Konzept der Inheritance, welches die Erweiterbarkeit jedes einzelnen Attributs in einem PSYC-Paket erlaubt, und die Kompression von Standardkeywords auf einzelne Bytes, denn ein von Natur aus kompaktes Protokoll ist immer besser als eines, welches nur mit Kompressionsalgorythmen existieren kann.

Wie steht es um strukturierte Daten in PSYC aus?

Dies ist ganz klar die Heimstärke des XML-Formats. Die PSYC-Syntax täte sich damit eher schwer, allerdings sind wir einerseits kaum auf entsprechende Notwendigkeiten gestoßen, hätten andererseits auch keine Hemmungen bei absoluter Notwendigkeit auch mal ein XML Dokument als Payload einer Nachricht zu spezifizieren, aber die tatsächliche PSYC-Strategie in dieser Hinsicht lautet wie folgt: Die feingliederungsfähigen Variablennamen mit Inheritancefähigkeit haben eine vergleichbare Funktion zu XMLs XPath-Darstellung. So wie man ein XML Dokument in eine Tabelle von XPath-Zeigern und Werten umwandeln kann, kann man strukturierte Daten in verschachtelte PSYC Variablen packen. Da dessen NotwendigkeiT der Ausnahmefall ist, sollte sich dieser Ansatz als effizienter ergeben gegenüber XML. Weiterer Vorteil dieses Ansatzes ist, dass es im Vergleich zu XML so gut wie keinen Parsing-Aufwand gibt.

Wie ist das mit IMPP und XMPP? Ist es nicht ein Rückschritt für PSYC zu diesen RFCs compliant zu sein?

IMPP kann kein Multicast, also kann es nicht sinnvoll eine Nachricht an mehrere Leute herausverteilen, wobei Multicast jetzt als Konzept gemeint ist, die technische Umsetzung sollte auswählbar sein und hat derzeit in unserem Falle nichts mit "IP Multicast" zu tun. Wir erfüllen die Ziele von IMPP, auch wenn wir mit dem Multicasting eigentlich höhere Ansprüche stellen. XMPP speziell verwenden wir ja nur im Umgang mit Jabber-Servern.

Konfrontation oder Kooperation mit anderen Technologien

Gibt es auch Gutes an bestehenden Technologien wie IRC und XMPP?

Auf jeden Fall und jede Menge. Dadurch dass es leichter ist Neuerungen zu erklären in dem man sie mit bestehenden Technologien vergleicht, mag der Eindruck entstehen, wir würden über alles vorhandene "lästern." Das ist aber ein Mißverständnis. Wir benutzen IRC-Technologie selbst noch jeden Tag, manche unserer Entwickler haben an IRC selbst mitgewirkt und dort ihren Beitrag geleistet und die netzkulturhistorische Bedeutung von IRC wird womöglich noch in einem Jahrhundert ausser Frage stehen. Lediglich einen Vorwurf machen wir IRC und damit auch uns selbst, dass IRC es versäumt hat, die ultimative Messaging-Technologie des Internets zu werden, und dass in diesem traditionsreichen Segment proprietäre Anbieter nun die Nase vorn haben, und dabei nicht einmal wirklich gute Leistung erbringen. An der Stelle möchten wir unbedingt die Erfolge von XMPP preisen, welches daran arbeitet die Menschen und die Öffentlichkeit für ein freies Open-Source System zu begeistern. PSYC hätte diese Rolle schon viel früher einnehmen wollen, aber da zeigt sich, dass auch Open-Source gutes Marketing nicht schadet, und darauf verzichtet PSYC ja weitgehend.