Contact #13
-
|
Hi - is there a possibility to get in contact with the developer? I don't find an email anywhere... Background: So if you/somebody would/could help - please contact me ...
This would be great because with more information I could add "Echo" to https://www.freie-messenger.de/systemvergleich/ . Sorry for using the discussion function for this. Thanks a lot! PS: |
Beta Was this translation helpful? Give feedback.
Replies: 12 comments 10 replies
-
|
Hello. What would you like to know? "Hello. I'll provide some interpretations of the Echo. 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. Hope this helps." |
Beta Was this translation helpful? Give feedback.
-
|
Correction. The implementations are bounded. The Echo? No one knows. |
Beta Was this translation helpful? Give feedback.
-
Sure - more than one (system, server, german contacts, offline messages, ...) -> I'll send you an email. |
Beta Was this translation helpful? Give feedback.
-
|
Please include the questions here as this medium provides transparency. |
Beta Was this translation helpful? Give feedback.
-
|
...
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
1.mp42.mp4 |
Beta Was this translation helpful? Give feedback.
-
|
More cats. 3.movnetstat -ant | grep 471 Four listeners. All listening. 4710 has two clients, Spot-On and socat. 4711 has one client, Spot-On (57582). It’s also connected to 4712. 4712 has one client, socat (4711). It’s also connected to 4713. 4713 has one client, socat (4712). It’s also connected to 4710. test-a ↔ 4710 ↔ 4713 ↔ 4712 ↔ 4711 ↔ test-b Or something like that. Two SO nodes communicating through a network of cats. |
Beta Was this translation helpful? Give feedback.
-
|
The cats are spot-less. :) |
Beta Was this translation helpful? Give feedback.
-
|
This can be achieved through a mixture of SmokeStack, Smoke (it includes non-listening Echoing), SO-Lite, SO, socat, ncat, whatever. |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps Smoke will be able to also include the following scenario: non-listening (without accept()) devices connecting to each other. I was able to perform this with another project written in C++. b8d85c2#diff-f20b44aff67c14cb0127e62994457ef2bca6c4d0e5e3f84f0970fc8e1089b3a2 |
Beta Was this translation helpful? Give feedback.
-
|
textbrowser/qtchess@2d30132#diff-0e570ca6fabe24f94e52c1833f3ffd25567022beb826fa16891f3322051bc221 |
Beta Was this translation helpful? Give feedback.
-
|
Server-less (without listeners / without accept()) peers in Spot-On. |
Beta Was this translation helpful? Give feedback.
-
|
Server-less demonstration. STUN not required. server-less-spot-on.mp4 |
Beta Was this translation helpful? Give feedback.
-
|
Please clarify some of the information on your site. For example, the ideas behind server-less projects. Consider Jami as an example. **Jami works as a server and gets new ports for each connections (randomly binded). These are the ranges that can be used for each component: dht: UDP [4000, 8888] This documentation states that Jami works as a server. So, it is a distributed system where peers are both clients and servers. Servers exist. What is pure P2P? The very name suggests that nothing issues accept() nor listen(). However, that is unlikely. Most implementations I've seen of P2P have nodes which behave as clients (they connect to things) and servers (they accept() and listen() for connections). The definitions are intentionally ambiguous. A peer is defined as something that cannot be connected to while a server is something that things connect to. In P2P networks, this is most likely the behavior regardless of the model (coordinated or distributed or whatever (perhaps magic cosmic dust)). P2P: clients accept() / listen() and / or connect(). Those are hybrid peers. Some are pure peers because they only connect(). As this is not my investigation, I would inquire about the specifics of the projects you list. Above is an implementation which will be released soon demonstrating a model where two clients connect to each other without issuing accept() and listen(). They both bind to local addresses and repeatedly issue connect() every millisecond. |
Beta Was this translation helpful? Give feedback.
-
|
Silence. More news! The true P2P mechanism also features TLS! It's totally optional too. Two clients can establish a TLS session by coordinating client and server modes. Diagram. SO Client A <- TLS -> SO Client B. Zero listeners, zero servers, infinite joy. |
Beta Was this translation helpful? Give feedback.
-
|
https://www.freie-messenger.de/sys_email/ Spot-On introduced e-mail texting long before Delta and others. It's called Poptastic and has been available since 2014. |
Beta Was this translation helpful? Give feedback.
-
|
Poptastic includes SMP, forward secrecy, key-renewal, and status information. |
Beta Was this translation helpful? Give feedback.
-
|
Released Prison Blues in February of 2025. This allows communications over GIT. Works with GPG and Spot-on and Smoke. In GitHub, private tokens allow access to repositories. A bunch of people can create some repositories and exchange private tokens. Then, they can anonymously post to one or more GIT repositories GPG messages (or other messages). Spot-On will then push and pull; GIT as a free platform for communicating. GPG attachments work. |
Beta Was this translation helpful? Give feedback.
Silence.
More news! The true P2P mechanism also features TLS! It's totally optional too. Two clients can establish a TLS session by coordinating client and server modes.
Diagram.
SO Client A <- TLS -> SO Client B. Zero listeners, zero servers, infinite joy.