1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Crypto-Messenger: Signal-Server nicht…
  6. Thema

Zeit für echtes OpenSource

Helft uns, die neuen Foren besser zu machen! Unsere kleine Umfrage dauert nur wenige Sekunden!
  1. Thema
  1. 1
  2. 2
  3. 3
  4. 4

Neues Thema Ansicht wechseln


  1. Re: Matrix -> JA

    Autor: Keep The Focus 07.04.21 - 18:30

    > Versuch mal eine Seite mit HTTP/1.0- HTTP/1.1- und HTTP/2.0-Header und dann leite davon ab...

    Ein Zeugnis der Weiterentwicklung

    > Und dann erst: Ja, Matrix-Nachfolgern. Nachfolger des jetzt aktuellen Matrix-Protokolles, welches sicher nicht auch nach 10 Jahren noch exakt so funktioniert wie es 10 Jahre zuvor schon funktioniert hat.

    Nachfolger impliziert ein Ersetzen. Garantiert wird es nicht exakt so funktionieren, aber es wird (wahrscheinlich) immer noch Matrix sein und nicht so wie bei XMPP dann Matrix, was XMPP ersetzt

    > Und insbesondere dann, wenn Firmen das Protokoll adaptieren, die nicht selber zu Matrix gehören

    Matrix ein Protokoll. Eine Firma gehört nicht zum Protokoll.


    > Bei XMPP bestand die Chance zumindest, es wäre 1A möglich gewesen.

    Ernsthaft du träumst nach dem Untergang immer noch davon?


    > Dass die Firmen sich _bewusst_ gegen eine Kompatibilität bei XMPP entschieden haben, ist eine bewusste Entscheidung und _trotz_ des XMPP erfolgt, nicht _weil_.

    Du hast XMPP nicht verstanden

    > Haha, lol, ja sehr gut. Und wie erfolgt das? Durch einen, der es halt macht und alle müssen folgen und jede Implementierung muss sich instantan anpassen oder doch eher über eine ständige Anpassung und Koordinierung durch einen Zusammenschluss ala IETF, W3C, ECMA, etc. wie bei HTTP, JavaScript, WASM, oder... jetzt kommts... wie bei XMPP!?

    Und wo koordiniert das IETF einen nutzbaren Standard wie bei HTTP?
    Es gibt nur einen Haufen Extensions, wo sich die Leute selbst was raussuchen sollen (und wo selbst die "empfohlene Verschlüsselung" noch den Status "experimental" hat)

    Und nein keiner muss sich instantan anpassen. Änderungen passieren nicht von heute auf morgen sondern schriwttweise - wie bei Matrix


    > Jetzt wirds echt lächerlich. Sorry wenn ich das so hart sage, aber überleg doch mal, was du schreibst.

    Gebe ich gern zurück: Realität und deine Träumerei gehen hier stark auseinander

  2. Re: Zeit für echtes OpenSource

    Autor: Keep The Focus 07.04.21 - 19:21

    > .. eine Sammlung an Bausteinen, aus denen man ein gewisses Set implementieren muss, um eine der genormten Compliance Sets zu erfüllen.

    Welche Compliance sets?

    > Weißt du, wie viele Normen alleine einen der vielen genormten Steckertypen ausmachen?

    Nur, dass der Steckertyp nicht dadurch genormt ist, dass man statt der Norm nur eine Liste zusammenhangsloser Normen hinwirft.

    > Des Weiteren ist der Vergleich mit einem Ding, das sich in den letzten zig Jahrzehnten nicht geändert hat, hier wohl eher sehr unpassend. Den Vergleich mit HTML+co. fand ich da schon passender und - oh Wunder - der spricht eher _für_ XMPP als dagegen.

    Passt sehr gut als Vergleich.

    > Ehm, informier dich mal, was HTTP ist. Erstens meinst du sicher eher HTML und nicht HTTP.

    Nö, ich meint HTTP


    > IE6 anyone!? Und warum wohl hat jetzt auch Microsoft aufgegeben, die vor gar nicht mal so langer Zeit (da gab es XMPP schon) führend waren und quasi-Standards im Web vorgegeben haben?

    Und bei XMPP hat die Proprietärität gesiegt

    > Warum haben die nun Chrome für ihr Edge übernommen? Weil alles so gut spezifiziert und einfach zu implementieren ist?

    Kannst dich ja mal informieren - und es hat nichts damit zu tun

    > Das ist kein Beispiel gegen XMPP, das ist ein gutes Beispiel dafür, was man bei XMPP deutlich besser macht.

    XMPP ist (im Vergleich) tot

  3. Re: Matrix -> JA

    Autor: nirgendwer 08.04.21 - 10:34

    Keep The Focus schrieb:
    --------------------------------------------------------------------------------
    > > Versuch mal eine Seite mit HTTP/1.0- HTTP/1.1- und HTTP/2.0-Header und
    > dann leite davon ab...
    >
    > Ein Zeugnis der Weiterentwicklung

    Tada. Und das über eine Fülle an Einzelnormen oder gar externen Entwicklungen, so wie HTTP/2, welches ursprünglich von Goole als SPDY entwickelt wurde, dieses wiederum wurde von verschiedenen anderen Firmen aufgegriffen und erweitert und erst danach als HTTP/2 genormt. Wenn man es korrekt einsetzen will, muss man dabei eine ganz gute Menge von RFCs berücksichtigen. Und das ist nur das Auslieferungsprotokoll. HTML, Javascript, etcpp. kommt da ja noch obendrauf und umfasst eine Fülle an Einzelnormen.

    Dagegen wird ja selbst XMPP ziemlich geradeaus entwickelt.

    > Nachfolger impliziert ein Ersetzen. Garantiert wird es nicht exakt so
    > funktionieren, aber es wird (wahrscheinlich) immer noch Matrix sein und
    > nicht so wie bei XMPP dann Matrix, was XMPP ersetzt

    Träum weiter.

    > > Und insbesondere dann, wenn Firmen das Protokoll adaptieren, die nicht
    > selber zu Matrix gehören
    >
    > Matrix ein Protokoll. Eine Firma gehört nicht zum Protokoll.

    Bei XMPP gibt es einen Prozess, gewünschte Änderungen/Erweiterungen zu standardisieren und eine offizielle ID (XEP) zu vergeben. Wie sieht das bei Matrix aus? Wie können Firmen/Entwickler, die das Protokoll übernehmen und erweitern, sich an der Zukunft von Matrix beteiligen, ihre eigenen Entwicklungen einreichen und standardisieren lassen?

    > > Bei XMPP bestand die Chance zumindest, es wäre 1A möglich gewesen.
    >
    > Ernsthaft du träumst nach dem Untergang immer noch davon?

    Welchem Untergang? Meinst du nur weil DU es nicht nutzt, ist es nicht mehr existent? Selbst die Entwickler selber sprechen nicht davon, etwas ersetzen zu wollen.

    > > Dass die Firmen sich _bewusst_ gegen eine Kompatibilität bei XMPP
    > entschieden haben, ist eine bewusste Entscheidung und _trotz_ des XMPP
    > erfolgt, nicht _weil_.
    >
    > Du hast XMPP nicht verstanden

    re

    >
    > > Haha, lol, ja sehr gut. Und wie erfolgt das? Durch einen, der es halt
    > macht und alle müssen folgen und jede Implementierung muss sich instantan
    > anpassen oder doch eher über eine ständige Anpassung und Koordinierung
    > durch einen Zusammenschluss ala IETF, W3C, ECMA, etc. wie bei HTTP,
    > JavaScript, WASM, oder... jetzt kommts... wie bei XMPP!?
    >
    > Und wo koordiniert das IETF einen nutzbaren Standard wie bei HTTP?

    lol - RFC 7540 der IETF sagt dir was? Oder vielleicht RFC 3920? Oder...

    (Apropos, es gibt mehr RFCs zu HTTP als zu XMPP, so viel zu der Anzahl selber.)

    > Es gibt nur einen Haufen Extensions, wo sich die Leute selbst was
    > raussuchen sollen

    Du hast die Wahl. Bei HTTP gibt es jetzt noch immer zig Server und Clients, die kein HTTP/2 können. Geschweige denn die Fülle an Feinheiten der anderen Web-Standards ala HTML, Javascript, etcpp.

    Warum ist das dort für dich besonders gut, der gleiche Umstand bei XMPP aber zu dessen Nachteil?

    Wichtig ist, dass es einen Plan gibt, die Dinge kompatibel zu halten. So gibt es bei HTTP vielleicht die Versionsnummer. Für Version 2 gilt RFC 7540 als Einstiegspunkt, mit einer Fülle an Abhängigkeiten, die zu erfüllen sind. Bei XMPP ist es aktuell die Suite 2021, die diese Abhängigkeiten listet (RFCs und XEPs). Wo ist der Einstiegspunkt für Entwickler zur Matrix-Protokollspezifikation? Wie komplett ist diese, lassen sich alle Feinheiten und Optionen des Protokolles dort nachlesen?

    Beschäftige dich mal ernsthaft damit, statt einfach nur zu Ranten und Dinge zu behaupten, die überhaupt nicht stimmen.

    Es gibt jeweils zu HTTP entsprechende Compliance Tests und ja, natürlich findest du bzgl. XMPP auch derer welche, wie zu jedem durchdachten Weiterentwicklungsprozess. Wo sind die Compliance-Tests für das Matrix-Protokoll, die ich als Entwickler ausführen kann um die Compliance meiner Implementierung zu testen?

    > (und wo selbst die "empfohlene Verschlüsselung" noch den
    > Status "experimental" hat)

    So ist das halt wenn man einen Normungsprozess durchläuft und nicht einer sagt "das machen wir jetzt so" und wenn das nicht passt zwei Wochen später "jetzt machen wir es anders" hinterherschieben kann. Klar, da sind proprietäre Dinge ala WhatsApp oder Signal und halt vielleicht auch noch Matrix im Vorteil. Man macht es, ändert seine Referenzimplementierung und gut is. Da muss man nichts absprechen oder auf Kompatibilität anderer Implementierungen achten. Das ist genau der Punkt, den Moxie bei Signal hervorhebt, was er da haben will: Alle nutzen _seinen_ Server und _sein_ Client-Binary, in das er jederzeit (auch unbemerkt) Dinge implementieren kann, die kein anderer sieht und an die sich kein anderer anpassen muss. Will man das? Ich nicht. Es bedeutet schließlich 100% Kontrolle des Anbieters und bedarf somit 100% des Vertrauens des Nutzers in diesen Anbieter. Er kann einen Source veröffentlichen wie er will, der muss keineswegs mit dem tatsächlichen Binary, was letztendlich beim Nutzer landet, übereinstimmen. Bei Signal geht es dabei sogar so weit, dass man den Client nicht bei f-droid
    gibt. So schlimm ist es bei Matrix aktuell nicht und man will offener sein.Es gibt eine Referenzimplementierung. Auf der kann man aufsetzen oder Alternativen bauen, die dann auch tatsächlich funktionieren. Von einer offenen Spezifikation ala HTTP oder XMPP ist man aber wohl noch weit entfernt.

    > Und nein keiner muss sich instantan anpassen. Änderungen passieren nicht
    > von heute auf morgen sondern schriwttweise - wie bei Matrix

    Und das soll jetzt in wie fern ein Argument gegen den schrittweisen Entwicklungsprozess um XMPP sein? Dort sehe ich zukünftige Änderungen, z.B. anhand des Experimental-Status zukünftig zu implementierender XEPs. Wo sehe ich als Entwickler einer Alternativimplementierung Änderungen, die in Zukunft in Matrix geplant sind, bevor diese in der Referenzimplementierung mandatory werden?

    > > Jetzt wirds echt lächerlich. Sorry wenn ich das so hart sage, aber
    > überleg doch mal, was du schreibst.
    >
    > Gebe ich gern zurück: Realität und deine Träumerei gehen hier stark
    > auseinander

    lol

  4. Re: Zeit für echtes OpenSource

    Autor: nirgendwer 08.04.21 - 10:37

    Keep The Focus schrieb:
    --------------------------------------------------------------------------------
    > > .. eine Sammlung an Bausteinen, aus denen man ein gewisses Set
    > implementieren muss, um eine der genormten Compliance Sets zu erfüllen.
    >
    > Welche Compliance sets?

    Das aktuelle:
    https://xmpp.org/extensions/xep-0443.html

    Soll ich dir noch erklären wie man eine Internetsuchmaschine bedient?
    https://lmgtfy.app/?q=xmpp+compliance+set

    -> Auf Seite eins die aktuelle Suite 2021 und gleich noch mehrere Compliance Tester und ein genereller Artikel über das Thema. Man muss schon ganz schön ignorant sein, um hier nicht zu verstehen worum es geht und was gemeint war. Ich nutze DuckDuckGo statt Google und da ist die Suite 2021 sogar Treffer 1!

    > > Weißt du, wie viele Normen alleine einen der vielen genormten
    > Steckertypen ausmachen?
    >
    > Nur, dass der Steckertyp nicht dadurch genormt ist, dass man statt der Norm
    > nur eine Liste zusammenhangsloser Normen hinwirft.

    Zum x-ten Mal. "Liste zusammenhangsloser Normen" ist einfach falsch und dein persönlicher Rant. Wenn du nach der x-ten Erklärung weiterhin daran hängen bleibst, akzeptiere ich das. Es ist zwecklos, festgefressenen Ignoranten etwas erklären zu wollen.

    > > Des Weiteren ist der Vergleich mit einem Ding, das sich in den letzten
    > zig Jahrzehnten nicht geändert hat, hier wohl eher sehr unpassend. Den
    > Vergleich mit HTML+co. fand ich da schon passender und - oh Wunder - der
    > spricht eher _für_ XMPP als dagegen.
    >
    > Passt sehr gut als Vergleich.
    >
    > > Ehm, informier dich mal, was HTTP ist. Erstens meinst du sicher eher HTML
    > und nicht HTTP.
    >
    > Nö, ich meint HTTP
    >
    > > IE6 anyone!? Und warum wohl hat jetzt auch Microsoft aufgegeben, die vor
    > gar nicht mal so langer Zeit (da gab es XMPP schon) führend waren und
    > quasi-Standards im Web vorgegeben haben?
    >
    > Und bei XMPP hat die Proprietärität gesiegt

    Wo ist XMPP proprietär? Es ist weit weniger proprietär als Matrix oder gar Signal und andere aktuell gehypte Protokolle.

    > > Warum haben die nun Chrome für ihr Edge übernommen? Weil alles so gut
    > spezifiziert und einfach zu implementieren ist?
    >
    > Kannst dich ja mal informieren - und es hat nichts damit zu tun

    tada

    > > Das ist kein Beispiel gegen XMPP, das ist ein gutes Beispiel dafür, was
    > man bei XMPP deutlich besser macht.
    >
    > XMPP ist (im Vergleich) tot

    Es gibt hunderte Server, Millionen Nutzer, das Protokoll wird weiter entwickelt und es gibt aktuelle, moderne Clients und Server-Implementationen, sicher mehr als für Matrix. Wie kommst du darauf, dass Matrix weniger tot ist, sollte XMPP tot sein?

  5. Re: Zeit für echtes OpenSource

    Autor: nirgendwer 08.04.21 - 11:01

    Da bindet jemand mal nicht Google-Captchas ein und schon gibt es wieder Beschwerden. Man kann nicht einerseits das Monopol Googles und die Verfolgbarkeit Googles ablehnen und sich dann an der Stelle so blöd anstellen.

    Das Captcha kommt vom Serveranbieter konkret, nicht von Gajim oder gar einer XMPP-Organisation. Dein Rant geht hier also gegen... gute Frage... der CCC nutzt zum Beispiel das Captcha. Wo wolltest du einen Account erstellen, gegen den sich nun dein Rant richtet?

    Die Captchas unterscheiden sich, je nachdem welchen Anbieter man aus der Liste auswählt. Es gibt hunderte Jabber-Server und somit bestimmt auch einen, der ein Captcha verwendet, welches auch du schaffst.

    Aber das ist ja sowieso nicht das Ziel, nachdem du schon zu Anfang klarstellst, das sowieso nicht objektiv sehen zu wollen, sondern sowieso nur:

    Iruwen schrieb:
    > [...] über ein weiteres hässliches Stück Gtk-Software zu ranten [...]

    ... würdest du dich wundern, wenn jemand mit dem Ansatz "Iruwens Lieblingssoftware zu Ranten" zu dem Schluss kommt, dass deine Lieblingssoftware scheiße ist? Ich nicht... mich wundert daher auch nicht, dass dir gar nicht aufgefallen ist, dass dein Rant hier nicht gegen Gajim oder XMPP ging, sondern gegen jemanden völlig anderen.

  6. Re: Matrix -> JA

    Autor: Keep The Focus 08.04.21 - 11:03

    > Tada. Und das über eine Fülle an Einzelnormen oder gar externen Entwicklungen, so wie HTTP/2, welches ursprünglich von Goole als SPDY entwickelt wurde, dieses wiederum wurde von verschiedenen anderen Firmen aufgegriffen und erweitert und erst danach als HTTP/2 genormt.

    Das wichtige ist, dass es danach als HTTP genormt wurde. Bei XMPP bliebs bei einer (keinem abgestimmten Subset) Fülle an Einzelnormen

    > Bei XMPP gibt es einen Prozess, gewünschte Änderungen/Erweiterungen zu standardisieren und eine offizielle ID (XEP) zu vergeben. Wie sieht das bei Matrix aus? Wie können Firmen/Entwickler, die das Protokoll übernehmen und erweitern, sich an der Zukunft von Matrix beteiligen, ihre eigenen Entwicklungen einreichen und standardisieren lassen?

    Die Frage ist eher wie Firmen das im Moment bereits machen - lässt sich alles via matrix.org herausfinden


    > lol - RFC 7540 der IETF sagt dir was? Oder vielleicht RFC 3920? Oder...

    jup, aber ich suche das Äquivalent bei XMPP

    > Du hast die Wahl. Bei HTTP gibt es jetzt noch immer zig Server und Clients, die kein HTTP/2 können. Geschweige denn die Fülle an Feinheiten der anderen Web-Standards ala HTML, Javascript, etcpp.

    > Warum ist das dort für dich besonders gut, der gleiche Umstand bei XMPP aber zu dessen Nachteil?

    Es gibt bei XMPP keinen gleichen Umstand. Bei XMPP gibts nur einen wahllosen Haufen von extensions.
    Bei XMPP hast du dieses Problem bei jeder einzelnen Extension


    > Wichtig ist, dass es einen Plan gibt, die Dinge kompatibel zu halten. So gibt es bei HTTP vielleicht die Versionsnummer. Für Version 2 gilt RFC 7540 als Einstiegspunkt, mit einer Fülle an Abhängigkeiten, die zu erfüllen sind. Bei XMPP ist es aktuell die Suite 2021, die diese Abhängigkeiten listet (RFCs und XEPs). Wo ist der Einstiegspunkt für Entwickler zur Matrix-Protokollspezifikation? Wie komplett ist diese, lassen sich alle Feinheiten und Optionen des Protokolles dort nachlesen?
    > Beschäftige dich mal ernsthaft damit, statt einfach nur zu Ranten und Dinge zu behaupten, die überhaupt nicht stimmen.

    Wie wärs wenn du dich mal damit beschäftigst? Du fragst ständig mich statt mal selbst zu recherchieren. die "Suite 2021" ist wieder nur eine optionale Extension

    > So ist das halt wenn man einen Normungsprozess durchläuft und nicht einer sagt "das machen wir jetzt so" und wenn das nicht passt zwei Wochen später "jetzt machen wir es anders" hinterherschieben kann. Klar, da sind proprietäre Dinge ala WhatsApp oder Signal und halt vielleicht auch noch Matrix im Vorteil. Man macht es, ändert seine Referenzimplementierung und gut is. Da muss man nichts absprechen oder auf Kompatibilität anderer Implementierungen achten.

    Das zeigt doch einfach nur wie du keine Ahnung von Matrix hat hast und deshalb so viel Dünnpfiff rauslässt


    > Von einer offenen Spezifikation ala HTTP oder XMPP ist man aber wohl noch weit entfernt.

    Noch mehr Dünnpfiff


    > Und das soll jetzt in wie fern ein Argument gegen den schrittweisen Entwicklungsprozess um XMPP sein?

    Nein, gegen einen ziellos herumirrenden Haufen wie XMPP Extensions

    > Dort sehe ich zukünftige Änderungen, z.B. anhand des Experimental-Status zukünftig zu implementierender XEPs.

    zukünftig zu implementierender?
    ohje - OMEMO singt ein Lied davon. Wenn OMEMO dann also irgandwann in stable landet, müssen die Leute, die OMEMO implementieren wollen, OMEMO implementieren - herrlich

    > Wo sehe ich als Entwickler einer Alternativimplementierung Änderungen, die in Zukunft in Matrix geplant sind, bevor diese in der Referenzimplementierung mandatory werden?

    Mit den XMPPlern ist es ein reines Trauerspiel.
    Statt mal ihre eigene Position zu überdenken oder über den Tellerrand hinwegzuschauen (erkennt man schon am Unwissen über Matrix und fehlendem Interesse sich damit auseinanderzusetzen bevor man sich dagegen auflehnt), wird wehement am gewohnten festgehalten und es verteidigt.
    Ich muss mir mittlerweile sogar anhören, dass XMPP nicht tot ist, weil Jitsi damals XMPP gewählt hat oder Spiele Chat auf Basis von XMPP nutzen. Dass schon alleine die Begründung zeigt wie es um XMPP steht, das verstehen sie nicht.
    Ich hoffe für dich, dass du wenigstens mit XMPP dein Geld verdienst und alt bist. Ansonsten ließe diese Verbissenheit echt tief blicken.

  7. Re: Zeit für echtes OpenSource

    Autor: Keep The Focus 08.04.21 - 11:25

    > Wo ist XMPP proprietär? Es ist weit weniger proprietär als Matrix oder gar Signal und andere aktuell gehypte Protokolle.

    1. Falsch
    2. Du kannst nicht lesen: ich habe geschrieben: proprietär hat gegenüber XMPP gesiegt

    > Es gibt hunderte Server, Millionen Nutzer, das Protokoll wird weiter entwickelt und es gibt aktuelle, moderne Clients und Server-Implementationen, sicher mehr als für Matrix. Wie kommst du darauf, dass Matrix weniger tot ist, sollte XMPP tot sein?

    Kennst du das Problem der Schnecke, welche 1m pro Stunde schafft aber mit jeder Stunde nur noch halb so schnell ist?
    23392865 Tage später: Die Schnecke kriecht immer noch

    Immerhin haben sie mittlerweile (oh wieviele XMPP-Fans haben mir erzählt, dass das so unnötig ist und keiner braucht) erkannt, dass Verifizierung bis jetzt pain war, und sich jetzt mit Hilfe von Matrix-Leuten überlegen, wie sie das Prinzip von Matrix übernehmen können:
    https://www.youtube.com/watch?v=oc5844dyrsc&t=730s

  8. Re: Matrix -> JA

    Autor: nirgendwer 08.04.21 - 13:40

    > > lol - RFC 7540 der IETF sagt dir was? Oder vielleicht RFC 3920? Oder...
    >
    > jup, aber ich suche das Äquivalent bei XMPP

    q.e.d.

    Du steckst in deiner Endlosschleife fest und merkst nicht einmal, wenn du mal auch nur einen Tick nachgucken hätten sollen, worüber du schreibst.

    Du lästerst über Inkompatibilitäten der dutzenden Servern-Implementationen und hunderten Klients in über 20 Jahre XMPP-Entwicklung und dass ein Featureset optional ist und ja leider nicht verpflichtend. Ja wie sollte man denn etwas in der Art überhaupt verpflichtend machen? Du siehst den Wald vor lauter Bäumen nicht. Rausschmeißen und nicht ins Netz lassen in einem offenen, dezentralen, Netz? Oder an was denkst du da? Das ist doch nur noch bedeutungsloses Säbelrasseln von dir, wo klar ist, dass das, was du forderst, sehr wohl dort existiert.

    Matrix ist wesentlich jünger, natürlich gibt es da keinen Client der auf dem Stand vor 20 Jahren hängen geblieben ist, wenn es vor 20 Jahren noch gar kein Matrix gab. Was es gibt sind dennoch auch dort Clients die nicht alles unterstützen, Inkompatibilitäten,etcpp., was so total gar überhaupt nicht bei XMPP geht. Schreib einem Spectral-Nutzer mal eine E2E-verschlüsselte Nachricht und erkundige dich dann mit einem VOIP-Call, ob alles gut angekommen ist. Das sind Dinge, die ich via XMPP ganz normal nutze, sollte ja dann mit Matrix kein Problem sein, wo das doch alles perfekt und unmissverständlich implementiert ist, nicht wahr!?

  9. Re: Matrix -> JA

    Autor: nirgendwer 08.04.21 - 13:55

    PS:

    nirgendwer schrieb:
    --------------------------------------------------------------------------------
    > > > lol - RFC 7540 der IETF sagt dir was? Oder vielleicht RFC 3920?
    > Oder...
    > >
    > > jup, aber ich suche das Äquivalent bei XMPP
    >
    > q.e.d.
    >
    > Du steckst in deiner Endlosschleife fest und merkst nicht einmal, wenn du
    > mal auch nur einen Tick nachgucken hätten sollen, worüber du schreibst.

    Wer nachvollziehen will, worauf ich hier anspreche, muss sich nur den Titel von besagtem RFC 3920 ansehen, zu der Keep The Focus das Äquivalent für XMPP sucht.

    >
    > Du lästerst über Inkompatibilitäten der dutzenden Servern-Implementationen
    > und hunderten Klients in über 20 Jahre XMPP-Entwicklung und dass ein
    > Featureset optional ist und ja leider nicht verpflichtend. Ja wie sollte
    > man denn etwas in der Art überhaupt verpflichtend machen? Du siehst den
    > Wald vor lauter Bäumen nicht. Rausschmeißen und nicht ins Netz lassen in
    > einem offenen, dezentralen, Netz? Oder an was denkst du da? Das ist doch
    > nur noch bedeutungsloses Säbelrasseln von dir, wo klar ist, dass das, was
    > du forderst, sehr wohl dort existiert.

    Nochmal für diejenigen, die dem nicht folgen können: Wenn einem die XEPs an sich zu unzusammenhängend sind und die Forderung im Raum steht, es solle doch eine Spezifikation geben, die angibt, was zu welchem Zeitpunkt doch bitte konkret die Dinge sind, die man implementieren soll, dann ist eine Liste in der Form der "Compliance Suites" genau das, was man fordert.

    Und da es diese schon länger gibt als es Matrix überhaupt gibt, kann das Fehlen einer solchen Spezifikation noch nie ein Argument Pro Matrix bei der Betrachtung Matrix vs. XMPP gewesen sein.

    Darüber hinaus wird das, was hier bei den XEPs seitens Keep The Focus bemängelt wird, nämlich dass es keine harte Forderung gibt und Clients, die diese nicht erfüllen, ausgesperrt werden - sprich die Betrachtung der Suite 2021 als "optionale Extension" - gilt für Matrix ja nicht anders, wie man an den Clients, die nicht alles implementieren, sieht.

  10. Re: Matrix -> JA

    Autor: Keep The Focus 08.04.21 - 14:30

    > q.e.d.

    > Du steckst in deiner Endlosschleife fest und merkst nicht einmal, wenn du mal auch nur einen Tick nachgucken hätten sollen, worüber du schreibst.

    nope, weil du immer noch nicht das Lego-Haus vs Lego-Stückchen verstehst.

    > . Ja wie sollte man denn etwas in der Art überhaupt verpflichtend machen? Du siehst den Wald vor lauter Bäumen nicht.

    Es nicht als Extension deklarieren, sondern fest definieren und keine Alternativen zulassen

    > Rausschmeißen und nicht ins Netz lassen in einem offenen, dezentralen, Netz? Oder an was denkst du da? Das ist doch nur noch bedeutungsloses Säbelrasseln von dir, wo klar ist, dass das, was du forderst, sehr wohl dort existiert.

    Bring doch nicht das Protokoll mit Implementierungen durcheinander. Ersteres ist bei XMPP schon broken by design

    > Matrix ist wesentlich jünger, natürlich gibt es da keinen Client der auf dem Stand vor 20 Jahren hängen geblieben ist

    Ums hängen bleiben geht's gar nicht. Keine Ahnung wie du da auf den Trichter kommst. Auch bei Matrix wirds zwangsweise Implementierungen geben, die wegsterben (z.B. Pattle)

    > Was es gibt sind dennoch auch dort Clients die nicht alles unterstützen, Inkompatibilitäten,etcpp.,

    Hier wirfst du wieder verschiedene Dinge in einen Topf. Inkompatibilitäten und nicht unterstützen. Letzteres passiert bei Matrix höchstens versehentlich, bei XMPP ist das by design.

    > Schreib einem Spectral-Nutzer mal eine E2E-verschlüsselte Nachricht und erkundige dich dann mit einem VOIP-Call, ob alles gut angekommen ist.

    > Name Spectral
    > Description A glossy client for Matrix, written in QtQuick Controls 2 and C++
    > Author b0
    > Maturity Alpha

    Weiter brauche ich gar nicht lesen

    > Das sind Dinge, die ich via XMPP ganz normal nutze, sollte ja dann mit Matrix kein Problem sein, wo das doch alles perfekt und unmissverständlich implementiert ist, nicht wahr!?

    Das will ich sehen wie du mit einem XMPP Client, der keine Videochats unterstützt Videochats nutzen möchtest.
    Wo habe ich behauptet, dass mit Matrix alles perfekt und unmissverständlich implementiert ist? Du argumentierst gegen einen Strohmann

  11. Re: Matrix -> JA

    Autor: nirgendwer 08.04.21 - 15:25

    Keep The Focus schrieb:
    --------------------------------------------------------------------------------
    > > q.e.d.
    >
    > > Du steckst in deiner Endlosschleife fest und merkst nicht einmal, wenn du
    > mal auch nur einen Tick nachgucken hätten sollen, worüber du schreibst.
    >
    > nope, weil du immer noch nicht das Lego-Haus vs Lego-Stückchen verstehst.

    Da gibt es kein "vs". Ein Lego-Haus baut man aus Lego-Steinen. Dass dir Analogien aber nicht so liegen, hatten wir ja schon. Die Anleitung zu den jeweiligen Häusern erhältst du bei XMPP ebenso wie bei Matrix und beide baust du aus einzelnen Steinen und bei beiden finden sich optionale und du brauchst Steine aus anderen Kästen, die nicht direkt mitgeliefert werden.

    > Es nicht als Extension deklarieren, sondern fest definieren und keine
    > Alternativen zulassen

    Wie gesagt, in einem freien, offenen Netz und zig alternativen Implentierungen? Funktioniert nicht. Man kann sagen, dass man da so will und dann zusehen, dass sich doch einige nicht dran halten. Das ändert nichts daran, dass es nicht funktioniert. Ob nun ein "required" in einer Spec ala Matrix und oder Teil einer "Compliance Suite" ala XMPP, ist beides das selbe. Beides drückt aus, was du implementieren _solltest_, um "compliant" zu sein.

    Machst du es in deiner Implementierung nicht, machst du es halt nicht. Passiert bei beiden, wie man in der Praxis sieht.

    > > Rausschmeißen und nicht ins Netz lassen in einem offenen, dezentralen,
    > Netz? Oder an was denkst du da? Das ist doch nur noch bedeutungsloses
    > Säbelrasseln von dir, wo klar ist, dass das, was du forderst, sehr wohl
    > dort existiert.
    >
    > Bring doch nicht das Protokoll mit Implementierungen durcheinander.
    > Ersteres ist bei XMPP schon broken by design

    Behaupten kann man vieles. Aufgezeigt hast du es nicht.

    > > Matrix ist wesentlich jünger, natürlich gibt es da keinen Client der auf
    > dem Stand vor 20 Jahren hängen geblieben ist
    >
    > Ums hängen bleiben geht's gar nicht. Keine Ahnung wie du da auf den
    > Trichter kommst. Auch bei Matrix wirds zwangsweise Implementierungen geben,
    > die wegsterben (z.B. Pattle)

    Tada.

    > > Was es gibt sind dennoch auch dort Clients die nicht alles unterstützen,
    > Inkompatibilitäten,etcpp.,
    >
    > Hier wirfst du wieder verschiedene Dinge in einen Topf. Inkompatibilitäten
    > und nicht unterstützen. Letzteres passiert bei Matrix höchstens
    > versehentlich, bei XMPP ist das by design.

    Ach, versehentlich gibt es aktuell also keinen einzigen, der alles implementiert? So kann man es natürlich auch sehen...

    Wobei das bei Matrix ja doch zumindest für die Referenzimplementation klar machbar wäre. Man spezifiziert einfach nur das, was man dort schon implementiert hat. Weil man alleine selber entscheidet, was spezifiziert wird und man selber die Referenz stellt, wäre das recht einfach möglich. Das gibt es bei XMPP halt nicht, da sind sie klar im Nachteil. Dennoch sieht es selbst da nicht wirklich besser aus.

    > > Schreib einem Spectral-Nutzer mal eine E2E-verschlüsselte Nachricht und
    > erkundige dich dann mit einem VOIP-Call, ob alles gut angekommen ist.
    >
    > > Name Spectral
    > > Description A glossy client for Matrix, written in QtQuick Controls 2 and
    > C++
    > > Author b0
    > > Maturity Alpha
    >
    > Weiter brauche ich gar nicht lesen

    Klar, bei wem kannst du denn da weiterlesen? Demnach gibt es keine Matrix-Clienten oder wie? Mach es bei Fluffy, "Released", kannste die Aufgabe dennoch nicht erfüllen.

    Alles nur "versehen"? Setz mal deine rosa Brille ab.

    > > Das sind Dinge, die ich via XMPP ganz normal nutze, sollte ja dann mit
    > Matrix kein Problem sein, wo das doch alles perfekt und unmissverständlich
    > implementiert ist, nicht wahr!?
    >
    > Das will ich sehen wie du mit einem XMPP Client, der keine Videochats
    > unterstützt Videochats nutzen möchtest.
    > Wo habe ich behauptet, dass mit Matrix alles perfekt und unmissverständlich
    > implementiert ist? Du argumentierst gegen einen Strohmann

    Ach, nicht perfekt!? Du wetterst also gegen XMPP mit Dingen, die bei Matrix nicht anders sind, bzw. noch viel schlechter. Das ist alles andere als ein Strohman. Les dir die Matrix-Specs durch, diverses ist optional, frei, ändert sich und ist bei allen vorhandenen Clienten in völlig unterschiedlichen Ständen implementiert. Nur ein Bruchteil hat überhaupt alles "required" implementiert, wenn überhaupt irgend einer. Aber böses böses XMPP mit seinen XEPs, die nicht alle überall auf gleichem Stand implementiert sind und aktuelle Client-Entwicklungen die noch nicht alles aus der gerade aktuellen Compliance Suite installiert haben. Ja sowas aber auch... neinnein Matrix, da ist das ja was anderes wenn noch nicht jeder alles gleich implementiert hat, die sind ja noch in Entwicklung... bla...

    Du beschwerst dich bzgl. XMPP über Dinge, die du bei Matrix als selbstverständlich hinnimmst. Das ist schon keine rosa Brille mehr, das sind riesige Scheuklappen.

    Und das schon jetzt. Lass Matrix mal 20 Jahre alt sein, mit so vielen Neuerungen, die man jetzt noch nicht voraussehen kann. XMPP hält sich dafür sehr gut. Es funktioniert heute zig Kram, an den man vor 20 Jahren im Leben nicht gedacht hat, ohne am Kern von XMPP irgend etwas zu ändern. Man kann jetzt noch mit einem uralten Clienten ins Netz und das nutzen, was dieser kann. Das will was heißen.

  12. Re: Matrix -> JA

    Autor: Keep The Focus 08.04.21 - 16:11

    > Da gibt es kein "vs". Ein Lego-Haus baut man aus Lego-Steinen. Dass dir Analogien aber nicht so liegen, hatten wir ja schon. Die Anleitung zu den jeweiligen Häusern erhältst du bei XMPP ebenso wie bei Matrix und beide baust du aus einzelnen Steinen und bei beiden finden sich optionale und du brauchst Steine aus anderen Kästen, die nicht direkt mitgeliefert werden.

    Bei Matrix bekommt man das Haus - bei XMPP bekommt man die Legosteine


    > Wie gesagt, in einem freien, offenen Netz und zig alternativen Implentierungen? Funktioniert nicht. Man kann sagen, dass man da so will und dann zusehen, dass sich doch einige nicht dran halten. Das ändert nichts daran, dass es nicht funktioniert. Ob nun ein "required" in einer Spec ala Matrix und oder Teil einer "Compliance Suite" ala XMPP, ist beides das selbe. Beides drückt aus, was du implementieren _solltest_, um "compliant" zu sein.

    Was nicht funktioniert ist die einzelnen legosteine hinzuwerfen, was man ja an XMPP sehen kann.

    Und nein, es ist nicht das selbe, da die Suite schon alleine wieder eine Extension ist.
    Und hast du nicht geschrieben, die gäbs schon länger als Matrix?
    2015 gabs das jedenfalls noch nicht. Matrix gibts seit 2014. Die von 2016 ist nichtmal offiziell geworden: https://xmpp.org/extensions/xep-0375.html und die von 2020 und 2021 ist auch noch nicht fertig (obwohl das Jahr schon rum ist) :D

    Riecht stark danach, dass das erst kam als Matrix es vorgemacht hat.

    > Klar, bei wem kannst du denn da weiterlesen? Demnach gibt es keine Matrix-Clienten oder wie? Mach es bei Fluffy, "Released", kannste die Aufgabe dennoch nicht erfüllen.

    Doch, kann ich - wenn auch nicht so wie du dir das vorstellst, da FluffyChat ebenfalls noch keine Voicecalls implementiert hat.
    Wenn ich das Gegenüber auffordere in FluffyChat eine Konferenz zu initiieren, kann ich das machen.

    Problem liegt ganz klar bei FluffyChat UND NICHT bei Matrix. Achja, mit SchildiChat funktionierts hervorragend.


    > Ach, nicht perfekt!? Du wetterst also gegen XMPP mit Dingen, die bei Matrix nicht anders sind, bzw. noch viel schlechter.

    nein

    > Aber böses böses XMPP mit seinen XEPs, die nicht alle überall auf gleichem Stand implementiert sind und aktuelle Client-Entwicklungen die noch nicht alles aus der gerade aktuellen Compliance Suite installiert haben. Ja sowas aber auch... neinnein Matrix, da ist das ja was anderes wenn noch nicht jeder alles gleich implementiert hat, die sind ja noch in Entwicklung... bla...

    Du verstehst es immer noch nicht: Extensions (inkl. der seit Matrix vorhandenen "Compliance Suite", von welchen noch keine einzige finalisiert worden ist) vs Monolith



    1 mal bearbeitet, zuletzt am 08.04.21 16:12 durch Keep The Focus.

  13. Re: Matrix -> JA

    Autor: nirgendwer 09.04.21 - 09:53

    Keep The Focus schrieb:
    --------------------------------------------------------------------------------
    > > Da gibt es kein "vs". Ein Lego-Haus baut man aus Lego-Steinen. Dass dir
    > Analogien aber nicht so liegen, hatten wir ja schon. Die Anleitung zu den
    > jeweiligen Häusern erhältst du bei XMPP ebenso wie bei Matrix und beide
    > baust du aus einzelnen Steinen und bei beiden finden sich optionale und du
    > brauchst Steine aus anderen Kästen, die nicht direkt mitgeliefert werden.
    >
    > Bei Matrix bekommt man das Haus - bei XMPP bekommt man die Legosteine

    Definitiv nein. Bei beiden bekommt man eine Spec und muss sich die Steine für eine Implementierung selber besorgen, was bei beiden bedeutet, dass man eine Fülle an Spec-Dokumenten berücksichtigen muss aber bei beiden durchaus auch bedeutet, dass man sich bei vorhandenen Open Source Implementierungen bedienen kann. Beide sind sich da wesentlich ähnlicher, als du dir aktuell wohl nicht einmal vorstellen kannst.

    > Was nicht funktioniert ist die einzelnen legosteine hinzuwerfen, was man ja
    > an XMPP sehen kann.

    Dann erklär mal, weshalb es für XMPP zig Clients und Server gibt, die prima miteinander funktionieren. Dass selbst Jahre alte und nicht weiterentwickelte noch immer funktionieren, mit dem was sie implementieren. Und dass die, die heute weit entwickelt sind, featuremäßig der Konkurrenz wie Matrix nicht nachstehen. Wenn die Spec so kaputt ist, wie kommt das dazu? Nein, das spricht sogar für eine sehr gute Spec, wenn das funktioniert.

    Es gibt Clients, die mehr und welche die weniger implementieren, aber alle arbeiten bei dem, was sie implementieren, gut zusammen. Das klingt nach allem anderen als einer schlechten Spec.

    Der Unterschied zwischen Matrix und XMPP ist hier, dass XMPP bei dir - und ja, auch vielen anderen - einen deutlich schlechteren Ruf genießt. DEINE Sicht auf beide völlig unterschiedlich ist. Dir ist bei Matrix klar, dass es einige gibt die mehr und einige die weniger implementiert haben, dass das im gleichen Fall bei XMPP jedoch klar an der Spec liegt. Der Unterschied hier liegt also viel mehr bei DIR und deiner Auffassung, nicht bei den Specs.

    > Und nein, es ist nicht das selbe, da die Suite schon alleine wieder eine
    > Extension ist.
    > Und hast du nicht geschrieben, die gäbs schon länger als Matrix?
    > 2015 gabs das jedenfalls noch nicht. Matrix gibts seit 2014. Die von 2016
    > ist nichtmal offiziell geworden: xmpp.org und die von 2020 und 2021 ist
    > auch noch nicht fertig (obwohl das Jahr schon rum ist) :D

    Erstens: https://xmpp.org/extensions/xep-0270.html
    Zweitens: die Spec lesen und verstehen und nicht drauf los ranten. In der aktuellen XMPP Compliance Suites 2021 ganz groß hervorgehoben: "Implementations are encouraged and the protocol is appropriate for deployment in production systems"

    Man soll sie anwenden und sie wird bereit für prodiktive Systeme gesehen. Das ist exakt das, was bei Matrix zur jeweilig aktuellen Spec gilt. Im Übrigen bei Matrix erst seit 2019 und - wenn man es genau nimmt - noch immer in dieser mittlerweile veralteten Form. (

    Was du machst ist das selbe als würde jemand rumkrakeelen: Version 0.5, 0.1.2, 0-punkt-und-so-weiter...? Bäh... Matrix kann ja noch keiner benutzen, das sind ja noch alles 0er Versionen!!11einself!!

    Apropos, mit dem Verweis auf den ja nicht finalen Status der Compliance Suite 2021 hast du dich - mal wieder - zu weit aus dem Fenster gelehnt und gezeigt, dass du nicht nur XMPP nicht kennst, sondern generell nicht wie so ein Entwicklungsprozess funktioniert. Sonst würdest du nicht - wiedermal - bei XMPP etwas ankreiden, was absolut üblich ist und - ganz nebenbei - bei Matrix daher natürlich auch nicht anders gilt: Die aktuelle stable 1.0 mit Client Spec 0.5 ist inkompatibel zur derzeit eingesetzten 0.6er Version, die aktuell genutzt wird aber sich offiziell noch im Entwicklungsstatus befindet.

    Apropos, XMPP ist wohldefiniert, man findet üblicherweise sehr gut Angaben darüber, welche XEPs von welcher Implementierung unterstützt werden. Wie sieht das bei Matrix aus? Welche Spec-Version wird da von welcher Implementierung nun genau umgesetzt?

    > Riecht stark danach, dass das erst kam als Matrix es vorgemacht hat.

    Du zeigst stark, dass deine subjektive Meinung eine Meinung ist und nicht auf Tatsachen beruht.

    > Doch, kann ich - wenn auch nicht so wie du dir das vorstellst, da
    > FluffyChat ebenfalls noch keine Voicecalls implementiert hat.
    >
    > Wenn ich das Gegenüber auffordere in FluffyChat eine Konferenz zu
    > initiieren, kann ich das machen.
    >
    > Problem liegt ganz klar bei FluffyChat UND NICHT bei Matrix. Achja, mit
    > SchildiChat funktionierts hervorragend.

    Eben, zweierlei Maß. Beim einen liegt es an der Implementierung, beim anderen soll es die Spec sein. Klar. Die Aussage von jemanden, der beides offensichtlich nicht wirklich kennt, ist wertlos.

    > > Ach, nicht perfekt!? Du wetterst also gegen XMPP mit Dingen, die bei
    > Matrix nicht anders sind, bzw. noch viel schlechter.
    >
    > nein

    doch

    > Du verstehst es immer noch nicht: Extensions (inkl. der seit Matrix
    > vorhandenen "Compliance Suite", von welchen noch keine einzige finalisiert
    > worden ist) vs Monolith

    Wie gesagt, deine "Meinung" beruht nicht auf Tatsachen.

    Keine deiner Aussagen da stimmt.

    * "der seit Matrix vorhandenen"
    - falsch. siehe oben.

    * noch keine einzige finalisiert
    - falsch. siehe oben. Die aktuell anzuwendende ist auch klar, siehe oben.

    * vs Monolith
    - falsch. Alleine von matrix.org selber gibt es gleich mehrere Spec-Dokumente in aktuell verschiedensten Versionen. Der Implementationsstatus der aktuellen Referenzimplementation ist dabei meines Wissens nach aktuell _keiner_ der dort offiziellen Specs zuzuordnen, weil Teile im einen und andere Teile im anderen Stand sind. Ein Entwicklungsprozess halt. Des Weiteren verweisen die Matrix-Dokumente selber auf eine Fülle an anderen Standards, Normen und Prozessen, die zu berücksichtigen sind. Von einem Monolith ist man hier nicht weniger weit entfernt als bei XMPP, was auch klar zu begrüßen ist! Niemand will all die Räder, die schon entwickelt wurden, neu erfinden.

    Matrix ist der nächste heiße Scheiß, der durchs Dorf getrieben wird. Das führt aktuell dazu, dass hier _wesentlich_ mehr Arbeit rein gesteckt wird als in die aktuellen XMPP-Implementierungen. Die Referenzimplementierungen der Matrix-Server und Webclient sind in einem sehr guten Zustand. Das kann man gut und gerne hervorheben. Und ich finde das auch gut so. Mir ist Matrix 1000mal lieber als Threema, Signal oder all die anderen. Ne ehrlich, ich betreibe Matrix und XMPP und kenne beides und wenn die Entwicklung so weiter geht, werde ich mich klar auf Matrix konzentrieren.

    Dein Verweis auf die XMPP-Spec an sich ist aber ein Rant ohne Hintergrund von jemandem, der weder bei dem einen noch dem anderen wirklich mal näher hingeschaut hat. Das kannst du dir echt sparen. Leute wie du, die aus den falschen Gründen die eigene Sache hervorheben und mit Unwahrheiten über andere herziehen, das sind die, die ein gutes Produkt kaputt machen können. Das sind die, die dazu beitragen, dass Leute sich über das eigentlich ganz gute Produkt - wie hier Matrix - eine schlechte Meinung bilden, wenn diese aus den falschen Gründen mit Unwahrheiten hervorgehoben werden.

  1. Thema
  1. 1
  2. 2
  3. 3
  4. 4

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. OEDIV KG, Bielefeld
  2. SSI SCHÄFER Automation GmbH, Giebelstadt bei Würzburg
  3. Salo Holding AG, Hamburg
  4. Deutsche Schillergesellschaft e.V., Marbach am Neckar

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 2,49€
  2. für PC, PS4/PS5, Xbox und Switch
  3. 4,25€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Programm für IT-Jobeinstieg: Hoffen auf den Klebeeffekt
Programm für IT-Jobeinstieg
Hoffen auf den Klebeeffekt

Aktuell ist der Jobeinstieg für junge Ingenieure und Informatiker schwer. Um ihnen zu helfen, hat das Land Baden-Württemberg eine interessante Idee: Es macht sich selbst zur Zeitarbeitsfirma.
Ein Bericht von Peter Ilg

  1. Arbeitszeit Das Sechs-Stunden-Experiment bei Sipgate
  2. Neuorientierung im IT-Job Endlich mal machen!
  3. IT-Unternehmen Die richtige Software für ein Projekt finden

Weclapp-CTO Ertan Özdil: Wir dürfen nicht in Schönheit und Perfektion untergehen!
Weclapp-CTO Ertan Özdil
"Wir dürfen nicht in Schönheit und Perfektion untergehen!"

Der CTO von Weclapp träumt von smarter Software, die menschliches Eingreifen in der nächsten ERP-Generation reduziert. Deutschen Perfektionismus hält Ertan Özdil aber für gefährlich.
Ein Interview von Maja Hoock


    Fiat 500 als E-Auto im Test: Kleinstwagen mit großem Potenzial
    Fiat 500 als E-Auto im Test
    Kleinstwagen mit großem Potenzial

    Fiat hat einen neuen 500er entwickelt. Der Kleine fährt elektrisch - und zwar richtig gut.
    Ein Test von Peter Ilg

    1. Vierradlenkung Elektrischer GMC Hummer SUV fährt im Krabbengang seitwärts
    2. MG Cyberster MG B Roadster mit Lasergürtel und Union Jack
    3. Elektroauto E-Auto-Prämie übersteigt in 2021 schon Vorjahressumme