| |
The Echo protocol is used, for example, by Goldbug (desktop client) and Smoke (Android client), and is a key component of the “Comparison of the 7 major (open source) messenger systems”. The project is run exclusively by volunteers and is not funded by third parties.
In short: Very interesting, comprehensive, coherent. Unfortunately, however, there are many special and technical terms; many abstract and also strange terms in the explanations (molecules, prison blues, …); at first glance, it seems very technical, confusing, and complicated for beginners. Not designed as a replacement for everyday messengers, but for independence, resilience, and privacy.
GoldBug is essentially an interface for the “Spot-On” program core. The German Marjorie Wiki (external) describes Goldbug as follows:
GoldBug is an open source secure messenger and email client as well as also an internet or URL database search engine based on the network protocol called Echo and the program core Spot-on (spot-on.sf.net). The two basic functions of the Internet and its users - communication and web search - are thus represented by this application.
There is no German translation of the project page - but a very detailed German user manual (see below). In Smoke and Spot-On there are standard chatrooms (“channel”) which are called “Fire” and “Buzz” respectively. A “Buzz” is a “echoed IRC Channel” (e*IRC) room.
The Spot-On (external) Encryption Suite is an open source software project for encryption and messaging with many years of development experience as a pioneer in decentralized communication. It enables encrypted messaging, file transfers, and web searches without relying on centralized servers.
Spot-On introduced chat over HTTPS before MIT offered an HTTP chat client with Matrix ~and revolutionized XMPP~, defined Echo and the name in a communication client before Amazon launched its Echo devices, established chat rooms based on hash links before MS Teams introduced video chat based on cryptographic values, and Spot-On introduced chat via POPTASTIC email servers before DeltaChat and Spice Chat took over via email servers. Note: Deletion of Free Messengers
Spot-On (open source) has integrated an entire encryption suite with various encryption types and, since 2025, has offered “encrypted Git chat,” which enables chatting via Git or Git servers such as GitHub.
The main goal is to provide a decentralized communication method that is not based on central servers.
The feature is called “Prison Blues” because the chat always works when no chat server is available and does not require a running kernel in the Spot-On user interface. It was introduced in response to restrictive environments—which can feel like a prison—and is intended to enable “fun dancing in serverless IT environments.”
Developers use Git or Git servers such as Github as a version control system for files to securely store changes and make them available to participants. What if messages were exchanged instead of files? That’s exactly what is done here:
The conversation partners have a shared “Git repository” where they store their Spot-on-encrypted messages. Only those involved who have a (digital) key have access to it. The contact simply retrieves the latest version of the conversation history (stored in the repository), decrypts the new messages with their “token,” and the message is there, without the need for a large central chat server.
Configuring Prison Blues requires careful management of GIT access permissions. Important: Access to the desired repository should be restricted to contacts who are actually authorized to read and write there.
This may sound complicated, but it is very helpful for places or scenarios where normal communication is censored or unreliable. Examples include journalists in areas where freedom of the press is restricted, activists who need to organize discreetly, or simply private individuals who value their privacy and want to retain control over their own data.
The GitHub repository of the developer “Textbrowser” shows an example (external) with GIT-uploaded encrypted messages.
The process is as follows:
Source, among others: YouTube video (external) and comments
Some interpretations of the Echo from the developper
The Echo is not a strict protocol. It itself does not specify a protocol. It is not contractual.
There are several implementations of the Echo: Smoke, SmokeStack, Spot-On, and Spot-On-Lite. Smoke, as an example, implements a TCP-like protocol through the Echo for file sharing. What does this mean? It means that two participants may share a file in a reliable manner without being connected directly.
[A] <—–> [B] <—–> [C] <- … -> [X]. So, A publishes a file for X and Smoke guarantees that the transfer completes. The Steam protocol works within the Echo. It is TCP implemented through a network of applications (nodes). The [K] nodes may be Smoke, SmokeStack, Spot-On, Spot-On-Lite or something else capable of Echoing.
Spot-On-Lite introduced cryptographic routing so that specific Smoke clients receive their intended data. SO-Lite does this through inspecting special digests which Smoke clients attach to their messages. When a
message is published, a non-secret digest is attached to it. This digest instructs SO-Lite nodes to direct their inbound packets to their intended destinations. If a Smoke client attaches to an SO-Lite node, it provides the node with its pseudo-identity. The SO-Lite node shares this identity through the network so that other nodes are capable of addressing messages to their correct destinations.
Spot-On introduced the concept of the Adaptive Echo. Without too much detail, this subset of the Echo allows SO nodes to be programmed with secrets so that data from a Spot-On node is only forwarded to nodes which are aware of the secrets. This arrangement creates an exclusive sub-network.
Spot-On also introduced streaming of application data through itself. A sort of private proxy. For example, it is possible to transfer a file through SO using an application which does not offer TLS by configuring two so nodes such that both nodes are aware of the same secret. One application can write data to a local SO node while the counterpart SO node in some other network receives the ciphertext and writes the plaintext to a separate and local application.
Smoke and SmokeStack are exclusive to Android. SO and SO-Lite are available for just about any platform.
Further explanations from the developer (alias ‘textbrowser’):
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.
An analogy to encryption in the Echo protocol:
The cryptography of the Echo Protocol can be compared to giving and receiving surprise eggs. Bob gives Alice a surprise egg, Alice opens it and eats the chocolate, finds the plastic capsule inside the surprise egg, and tries to open it and assemble the parts inside to make a toy, a Smurf. However, she is unable to assemble it; the Smurf cannot be formed, so she puts the individual parts back into the plastic capsule, pours new chocolate around it, and passes the egg on to her neighbor, who also tries to assemble a Smurf from the parts. Alice doesn’t know who will be able to successfully assemble the surprise egg or the Smurf, so she copies it (what a miracle, Alice has a surprise egg copying machine) and passes a copy to all her friends. (Unpack, assemble, look at, pack up, give away, and unpack again, assemble, look at, pack up, give away, and so on… From the perspective of the instances (kernels) represented in the network, the network would have become a Kinder Egg paradise in this scenario if congestion control had not reduced the assembly processes again. Once crafting parts are known, they are not assembled a second time). Alice crafts until she can recognize a Smurf with a red cap; she has received the Papa Smurf figure intended for her and her message.
Offline messages are implemented via the “Poptastic” function, which requires an email account with IMAP or POP3. Alternatively, there is also the option of chatting via Git.
Question: How do offline messages work?
Answer:
Smoke has “SmokeStacks” and “Ozones.” Ozones are addresses. One or more stacks can be aware of identical ozones. Let’s assume the ozone is blue and say 10 stacks are aware of this ozone. In Smoke, I share my keys and it transmits them via the keys generated by Blue. A friend does the same. Our messages are then recorded on these accessible stacks. Spot-On has institutions, but the process is not that simple.
Question: Is a server required for offline messages? On both sides?
Answer:
SmokeStacks can be both clients and servers. When they are clients, they connect to things. So no. For example, I am on Mars and my friend is on Venus. The stacks can be on Pluto, the sun, and Earth. If the electrons from our devices can reach these stacks, everything works as expected. I don’t need my own stack, and neither does my friend. We also don’t need to know the details of the upstream connection. Imagine someone configuring a series of stacks and entering an echo network.
German user manual: https://de.wikibooks.org/wiki/Goldbug (external)
German wiki: https://marjorie-wiki.de/wiki/GoldBug_(Instant_Messenger)/ (external)
English user manual: https://compendio.github.io/goldbug-manual/ (external)\
Goldbug source code at Sourceforge: https://sourceforge.net/projects/goldbug/ (external)
Android client (F-Droid): Smoke (external)\
Project page: http://goldbug.sf.net/ (external)
Community page with detailed information: https://sammysupport.github.io/spot-on (external)
Spot-On documentation: https://textbrowser.github.io/spot-on (external)
Demonstration of serverless communication: »Video« (external) (STUN not required)
Spot-On source code on GitHub: https://github.com/textbrowser/spot-on (external)