Echo / Goldbug / Smoke

- Reading time: 8 minutes -


The protocol is used by Goldbug (desktop client) or Smoke (Android client), for example, and is a main component of the “Comparison of the big 7 (open source) messenger systems”. The project is entirely volunteer-driven and is not paid for by third parties.

In a nutshell: Very interesting, comprehensive, coherent. Unfortunately, however, many special and technical terms; many abstract and also strange terms in the explanations (molecules, …) ; seems very technical, confusing and complicated for nomal users at first sight.

GoldBug is quasi an interface (skin/theme) for the program core “Spot-On”. 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 ( 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.

Developer words

some interpretations of the Echo from the developper

Further explanation by 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 the give and take of surprise eggs. Bob gives a surprise egg to Alice, Alice opens it and eats the chocolate and comes across the plastic capsule inside the surprise egg and tries to open it and assemble the parts inside into a toy, a Smurf. However, she does not succeed in assembling it, the Smurf cannot be formed, and 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 make a Smurf out of the parts. Alice doesn’t know who can successfully assemble the surprise egg or Smurf, so she copies it (-what a miracle, Alice has an Ü egg copying machine- ) and gives one copy each to all her friends. (Unwrap it, tinker with it, look at it, wrap it, give it away, and unwrap it again, tinker with it, look at it, wrap it, give it away, and so on…. - From view of the instances (kernels) represented in the network in this picture the net would have become the Ü egg paradise, if not with Congestion control the tinkering procedures were reduced again. Once known tinkering parts are not assembled a second time). Alice tinkers until she can recognize a Smurf with a red cap, she has received the Papa Smurf figure intended for her or her message.

Offline messages

Offline messages are implemented using the “Poptastic” function, which requires an e-mail account with IMAP or POP3.

Question: How do offline messages work?
For Smoke there are “SmokeStacks” and “Ozones”. Ozones are addresses. One or more stacks can have knowledge of identical Ozones. Let’s say the ozone is blue and let’s say 10 stacks know this ozone. In Smoke, I share my keys and he transmits them using the keys generated by Blue. A friend does the same. Our messages are then recorded on these reachable stacks. Spot-On has institutions, but the process is not so simple. (translated by DeepL)

Question: Is a server needed for offline messages? On both sides?
Answer:_ SmokeStacks can be both clients and servers. If they are clients, they connect to things. So no. For example, I’m on Mars and my friend is on Venus. Stacks can be on Pluto, on the Sun, and on Earth. If the electrons from our devices can reach those stacks, everything works as expected. I don’t need my own stack, and neither does my friend. Nor do we need to know the details of the upstream connection. Imagine someone configuring a set of stacks and entering an echo network.”

German user manual: (external)
German wiki: (external)
English user manual: (external)
Demonstration serverless communication: >>Video<< (external) (STUN not required)
Source code: (external)
source code: (external)
Android client (F-Droid): Smoke (external)
Project page: (external)