Replies: 20 comments 2 replies
-
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. |
Beta Was this translation helpful? Give feedback.
-
Poptastic is like having GPG in e-mail but without GPG and with the benefit of it being near real-time. |
Beta Was this translation helpful? Give feedback.
-
Smoke transfers to one or more neighbors. Neighbors coordinate where messages should be delivered. This results in your device receiving messages intended for it. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
For example, I documented and implemented future-proofing concepts in Smoke and SO-Lite. I think I started in SO too. Lots of work. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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." |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
Smoke and Stack are complex and their interfaces are not stylistic. They are fun projects. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
"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. |
Beta Was this translation helpful? Give feedback.
-
"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? |
Beta Was this translation helpful? Give feedback.
-
I think projects that create communities are as important as projects which create small private groups although I prefer physical meetings between people. |
Beta Was this translation helpful? Give feedback.
-
Here is an image for an active connection and a duration of 3929 minutes. |
Beta Was this translation helpful? Give feedback.
-
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:
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.
Beta Was this translation helpful? Give feedback.
All reactions