| |
Das Protokoll wird z.B. von Goldbug (Desktop-Client) oder Smoke (Android-Client) genutzt, und ist Hauptbestandteil vom „Vergleich der großen 7 (quelloffenen) Messengersysteme“. Das Projekt ist wird ausschließlich von Freiwilligen gestemmt und wird nicht von Dritten bezahlt.
In der Kürze: Sehr interessant, umfassend, schlüssig. Leider jedoch viele Spezial- und Fachbegriffe; viele abstrakte und auch merkwürdige Bezeichnungen in den Erklärungen (Moleküle, …) ; wirkt für Nomalnutzer auf den ersten Blick sehr technisch, unübersichtlich und kompliziert.
GoldBug ist quasi eine Oberfläche (skin/theme) für den Programmkern „Spot-On“. Das deutsche Marjorie-Wiki (extern) beschreibt Goldbug wie folgt:
GoldBug ist ein quelloffener sicherer Messenger und E-Mail-Klient sowie auch eine Internet- bzw. URL-Datenbank-Suchmaschine basierend auf dem Netzwerkprotokoll namens Echo und dem Programmkern Spot-on (spot-on.sf.net). Die beiden Grundfunktionen des Internets und seiner Nutzer – Kommunikation und Websuche – werden somit durch diese Applikation abgebildet.
Es gibt zwar keine deutschsprachige Übersetzung der Projektseite - aber ein sehr ausführliches deutsches Benutzerhandbuch (s.u.). In Smoke und Spot-On gibt es Standard-Chaträume („channel“) die dort „Fire“ bzw. „Buzz“ heißen. Ein “Buzz” ist ein “ge-echo-ter IRC Channel” (e*IRC) -Raum.
Weitere Erläuterungen des Entwicklers (Alias ‘textbrowser’):
Ich finde das Echo einfach und großartig. Ich kann einen Server in wenigen Sekunden vorbereiten und zwei Geräte in wenigen Minuten oder weniger miteinander kommunizieren lassen (das hängt von den Geräten ab). Das Echo funktioniert einfach. Ich muss keine Server, Konten usw. konfigurieren. Außerdem ist es sehr flexibel.
Als ich den öffentlichen Server finanziert habe, war meine Schnittstelle von zu Hause aus ein Raspberry Pi. Geräte von zu Hause aus wurden mit diesem verbunden und manchmal auch mit einem separaten Rechner, der mit dem Pi verbunden war. Der Pi stellte dann eine Verbindung zum Remote-Server her. Leider gibt es nicht viele (oder gar keine) Dienste, die auf Raspberry Pis laufen, so dass auch das ein interessanter Test gewesen wäre. Es wurden viele Szenarien getestet, und diese Experimente sind wahrscheinlich nirgends erwähnt. Eine weitere Idee des Echo ist, dass es die Erkundung unterstützt.
Das Echo ist transparent. Es erfordert keine spezielle Software. Es ist natürlich erweiterbar. Ich denke, es braucht Fantasie bei der Implementierung :) Es gibt vier verschiedene und ähnliche Implementierungen: Smoke, SmokeStack, Spot-On, Spot-On-Lite. Sie arbeiten alle zusammen, ungeachtet ihrer Unterschiede. Das ist ein weiteres Konzept des Echo. Dinge, die es implementieren, sollten sich nicht um andere Produkte im Netzwerk kümmern. Natürlich ist es nicht grenzenlos.
Berichtigung. Die Implementierungen sind begrenzt. Das Echo? Keiner weiß es.
Original:
I think the Echo is simple and splendid. I can prepare a server in a few seconds and have two devices communicating with one another in a few minutes or less (depends upon the devices). The Echo just works. I do not have to configure servers, accounts, etc. It’s also quite flexible.
_When I was funding the public server, my interface from home was a Raspberry Pi. Devices from home would connect to it and sometimes to a separate machine connected to the Pi. The Pi would connect to the remote server. Unfortunately, there are not many (or any) services which live on Raspberry Pis so that would have been an interesting test as well. Many scenarios were tested and these experiments are probably not mentioned anywhere. Another idea of the Echo is that it endorses exploration.
The Echo is transparent. It doesn’t require special software. It’s naturally extensible. I think it needs imagination with implementation. :) It has four distinct and similar implementations: Smoke, SmokeStack, Spot-On, Spot-On-Lite. They all work together regardless of their differences. That is another concept of the Echo. Things that implement it should not care about other products in the network. Of course, it’s not boundless.
Correction. The implementations are bounded. The Echo? No one knows.
Eine Analogie zur Verschlüsselung beim Echo-Protokoll:
Die Kryptographie des Echo-Protokolls kann verglichen werden mit dem Geben und Nehmen von Überraschungseiern. Bob gibt ein Überraschungsei an Alice, Alice öffnet es und verzehrt die Schokolade und stößt auf die Plastik-Kapsel im Inneren des Überraschungsei und versucht, diese zu öffnen und die darin befindlichen Teile zu einem Spielzeug, einem Schlumpf, zusammen zu bauen. Der Zusammenbau gelingt ihr aber nicht, der Schlumpf lässt sich nicht bilden und daher packt sie die Einzelteile wieder in die Plastik-Kapsel, gießt neue Schokolade drum rum und gibt das Ei an den Nachbarn weiter, der ebenso versucht, einen Schlumpf aus den Teilen zu basteln. Alice weiß nicht, wer das Überraschungsei bzw. den Schlumpf erfolgreich zusammenbauen kann, daher kopiert sie es (- welch ein Wunder, Alice hat eine Ü-Ei-Kopiermaschine - ) und gibt jeweils eine Kopie an alle ihre Freunde weiter. (Auspacken, basteln, anschauen, einpacken, verschenken und wieder auspacken, basteln, anschauen, einpacken, verschenken, und so fort … - Aus Sicht der im Netzwerk vertretenen Instanzen (Kernels) wäre in diesem Bild das Netz zum Ü-Ei-Paradies geworden, wenn nicht mit Congestion Control die Bastelvorgänge wieder reduziert würden. Einmal bekannte Bastel-Teile werden nicht ein zweites Mal zusammen gebaut). Alice bastelt so lange, bis sie einen Schlumpf mit roter Mütze erkennen kann, sie hat die für sie bestimmte Figur des Papa-Schlumpfs bzw. ihre Nachricht erhalten.
Offline Nachrichten werden über die Funktion „Poptastic“ realisiert, wozu ein E-Mailkonto mit IMAP oder POP3 erforderlich ist.
Frage: Wie funktionieren Offline-Nachrichten?
Antwort:
Für Smoke gibt es „SmokeStacks“ und „Ozones“. Ozones sind Adressen. Ein oder mehrere Stacks können von identischen Ozones Kenntnis haben. Nehmen wir an, die Ozone ist blau und sagen wir, 10 Stacks kennen diese Ozone. In Smoke teile ich meine Schlüssel und er überträgt sie über die von Blue generierten Schlüssel. Ein Freund tut dasselbe. Unsere Nachrichten werden dann auf diesen erreichbaren Stacks aufgezeichnet. Spot-On hat Institutionen, aber der Prozess ist nicht so einfach. (übersetzt mit DeepL)
Frage: Wird für Offline-Nachrichten ein Server benötigt? Auf beiden Seiten?
Antwort:
SmokeStacks können sowohl Clients als auch Server sein. Wenn sie Clients sind, verbinden sie sich mit Dingen. Also nein. Zum Beispiel bin ich auf dem Mars und mein Freund ist auf der Venus. Die Stacks können sich auf dem Pluto, der Sonne und auf der Erde befinden. Wenn die Elektronen von unseren Geräten diese Stacks erreichen können, funktioniert alles wie erwartet. Ich brauche keinen eigenen Stack, und mein Freund auch nicht. Wir müssen auch nicht die Details der Upstream-Verbindung kennen. Stellen Sie sich vor, jemand konfiguriert eine Reihe von Stacks und betritt ein Echo-Netzwerk.
Deutsches Benutzerhandbuch: https://de.wikibooks.org/wiki/Goldbug (extern)
Deutsches Wiki: https://marjorie-wiki.de/wiki/GoldBug_(Instant_Messenger)/ (extern)
Englisches Benutzerhandbuch: https://compendio.github.io/goldbug-manual/ (extern)
Demonstration serverlose Kommunikation: >>Video<< (extern) (STUN nicht erforderlich)
Quellcode: https://sourceforge.net/projects/goldbug/ (extern)
Quellcode: https://textbrowser.github.io/spot-on (extern)
Android-Client (F-Droid): Smoke (extern)
Projektseite: http://goldbug.sf.net/ (extern)