Protocol efficiency & practical applications.

[macbugs]

There are so many apps in the arena of decentralized messaging that it becomes necessary to explain to the user why he should choose a particular one. So here is another that I am currently studying:

https://simplex.chat/

The documentation raises some valid issues, I think:

• P2P networks use some variant of DHT to route messages/requests through the network. DHT implementations have to balance reliability, delivery guarantee and latency.
• P2P does not solve MITM attack problem.
• P2P can be blocked by some Internet providers (as BitTorrent is blocked).
• P2P networks are vulnerable to Sybil attack, because each node is discoverable. To reduce the probability of the Sybil attack requires a centralized component or expensive proof of work.

• https://github.com/simplex-chat/simplex-chat/blob/stable/docs/SIMPLEX.md
• https://github.com/simplex-chat/simplex-chat/blob/stable/README.md
• https://github.com/simplex-chat/simplexmq/blob/stable/protocol/overview-tjr.md
• https://github.com/simplex-chat/simplexmq/blob/stable/protocol/simplex-messaging.md

---

COMPARISON

“Offline messages are implemented using the ‘Poptastic’ function, which requires an e-mail account.”

“in the echo network, each connection node sends each message to each connected neighbor.”

“SimpleX Chat stores all user data only on client devices using a portable encrypted database format that can be exported and transferred to any supported device. The end-to-end encrypted messages are held temporarily on SimpleX relay servers until received, then they are permanently deleted. Unlike federated networks servers (email, XMPP or Matrix), SimpleX servers dont store user accounts, they only relay messages, protecting the privacy of both parties. There are no identifiers or ciphertext in common between sent & received server traffic — if anybody is observing it, they cannot easily determine who communicates, even if TLS is compromised.”

Bitmessage addresses this problem by duplicating traffic… but I think it is not an ideal solution. So you are extending the Bitmessage protocol to support offline (asychronous) messaging through SMTP servers? —I think the developer of SimpleX has a good point about why we should avoid SMTP. And broadcasting to many peers is not ideal for mobile devices because of the energy usage & ‘data cap’. It also might generate too much traffic on community wireless mesh networks. So perhaps the SimpleX method is a more efficient use of network resources. But I am still evaluating a variety of alternative messaging platforms. Decentralized & secure messaging is a complex problem (…and making it both user-friendly & adequately-secure is also difficult.) BitMessage provides “security through obscurity” (i.e. broadcasting spurious traffic), while SimpleX achieves obscurity through out-of-band signaling.

[textbrowser]

Echo is not an extension of BM.

Poptastic was born from my inability to communicate with people outside of work. E-mail ports are generally allowed in every environment as are 80 and 443. That's the rationale of communicating through e-mail.

Smoke introduced Cryptographic Discovery in 2017 and was discussed in 2016. Around that time. It was discovered and implemented exactly for that purpose: limited-resource environments. Spot-On-Lite was created for that purpose too and without the need of Android.

[textbrowser]

Poptastic is like having GPG in e-mail but without GPG and with the benefit of it being near real-time.

[textbrowser]

Smoke transfers to one or more neighbors. Neighbors coordinate where messages should be delivered. This results in your device receiving messages intended for it.

[textbrowser]

I'm not pursuing communications projects. If I have an idea, I may implement it. I maintain the projects for continuity, corrections, porting. I've left that environment.

And if people have suggestions, corrections, interest.

[textbrowser]

For example, I documented and implemented future-proofing concepts in Smoke and SO-Lite. I think I started in SO too. Lots of work.

[textbrowser]

SmokeStack is a server application that resides on Android devices (and Android laptops). Stack offers message redundancy, for example, if a client is offline. Smoke does not have persistence. Stack offers persistence through Ozones.

[textbrowser]

Smoke and Stack instances are not discoverable by IP addresses. Through Cryptographic Discovery, it's necessary to share some sort of information about yourself on a network since messages have to be coordinated. This clearly offers information.

[textbrowser]

The servers are not required to adhere to discovery. So, you can connect to Spot-On and Spot-On will forward messages to you even if those messages are not desired. The Echo doesn't have rigid protocols.

[textbrowser]

Smoke utilizes aliases. Two participants are paired via aliases. Aliases may be exchanged in person, privately through other mediums, or publicly. If they are exchanged in a public medium, Smoke includes a zero-knowledge verification mechanism.

[textbrowser]

Stack also acts as a public-key server. A person may intentionally record their public keys and have another person retrieve them. Stacks are hidden behind Ozones. Smoke does not have the concept of connection requests nor do Stacks. Pairing requires knowledge of aliases. I pair with you if you and I both have knowledge of our aliases. If we are impersonated because of our aliases being too common or publicly shared, we can identify ourselves through zero-knowledge proofs. How? Well, we can ask questions such as: "Do you recall the time we had biscuits? Send me the name of the shop in lowercase."

[textbrowser]

Multiple Stacks can share Ozones. A stack may reside in your office for example sitting on your desk. Or, you can carry it around and charge it whenever. You'd be a traveling server. It could be a private key server, a private server, a public server, or combinations. Messages are encrypted by it and by the original parties.

[textbrowser]

You can configure multiple neighbors in Smoke and the device you're connected to may be Spot-On, Stack, or SO-Lite. It may even be a forwarding service. Depending on what you're connected to, Cryptographic Discovery may be or may not be available. If that is important to you, then you need some basic service knowledge about that server.

[textbrowser]

Smoke offers reliable file sharing with other Smoke instances. It also has a feature of sharing a file with Unix utilities. Steams may also be shared by a person receiving them with other people as they are being received.

[textbrowser]

Smoke and Stack are complex and their interfaces are not stylistic. They are fun projects.

[textbrowser]

There are so many apps in the arena of decentralized messaging that it becomes necessary to explain to the user why he should choose a particular one. So here is another that I am currently studying:

https://simplex.chat/ The documentation raises some valid issues, I think:

* P2P networks use some variant of DHT to route messages/requests through the network. DHT implementations have to balance reliability, delivery guarantee and latency.

* P2P does not solve MITM attack problem.

* P2P can be blocked by some Internet providers (as BitTorrent is blocked).

* P2P networks are vulnerable to Sybil attack, because each node is discoverable. To reduce the probability of the Sybil attack requires a centralized component or expensive proof of work.


* https://github.com/simplex-chat/simplex-chat/blob/stable/docs/SIMPLEX.md

* https://github.com/simplex-chat/simplex-chat/blob/stable/README.md

* https://github.com/simplex-chat/simplexmq/blob/stable/protocol/overview-tjr.md

* https://github.com/simplex-chat/simplexmq/blob/stable/protocol/simplex-messaging.md

COMPARISON

“Offline messages are implemented using the ‘Poptastic’ function, which requires an e-mail account.”

“in the echo network, each connection node sends each message to each connected neighbor.” “SimpleX Chat stores all user data only on client devices using a portable encrypted database format that can be exported and transferred to any supported device. The end-to-end encrypted messages are held temporarily on SimpleX relay servers until received, then they are permanently deleted. Unlike federated networks servers (email, XMPP or Matrix), SimpleX servers dont store user accounts, they only relay messages, protecting the privacy of both parties. There are no identifiers or ciphertext in common between sent & received server traffic — if anybody is observing it, they cannot easily determine who communicates, even if TLS is compromised.”

Bitmessage addresses this problem by duplicating traffic… but I think it is not an ideal solution. So you are extending the Bitmessage protocol to support offline (asychronous) messaging through SMTP servers? —I think the developer of SimpleX has a good point about why we should avoid SMTP. And broadcasting to many peers is not ideal for mobile devices because of the energy usage & ‘data cap’. It also might generate too much traffic on community wireless mesh networks. So perhaps the SimpleX method is a more efficient use of network resources. But I am still evaluating a variety of alternative messaging platforms. Decentralized & secure messaging is a complex problem (…and making it both user-friendly & adequately-secure is also difficult.) BitMessage provides “security through obscurity” (i.e. broadcasting spurious traffic), while SimpleX achieves obscurity through out-of-band signaling.

https://github.com/simplex-chat/simplexmq/blob/stable/protocol/simplex-messaging.md#appendix-a

Appendix A suggests that there is a required trust of the server.

Smoke does not have this requirement.

[textbrowser]

"Users trust their contacts and the servers they chose."

With Smoke, this is not necessary. A zero-knowledge mechanism exists but trust is not required.

[textbrowser]

"The protocol does not protect against attacks targeted at particular users with known identities - e.g., if the attacker wants to prove that two known users are communicating, they can achieve it. At the same time, it substantially complicates large-scale traffic correlation, making determining the real user identities much less effective."

So are identifiers required or not?

[textbrowser]

textbrowser/smoke#13

[textbrowser]

I think projects that create communities are as important as projects which create small private groups although I prefer physical meetings between people.

[textbrowser]

https://www.freie-messenger.de/en/sys_p2p/#echo-protokoll

[textbrowser]

Here is an image for an active connection and a duration of 3929 minutes.

[textbrowser]