SimpleX Chat

Freedom of speech needs infrastructure that protects it by design — protocols, governance and funding. v6.5 release brings SimpleX Channels: a new model for online publishing built for participation privacy.👇

It is a one-sided view of the problem. The choice between guarantee via architecture and guarantee via policy is a false binary - both are necessary, as neither alone is sufficient. The core security assumption of many decentralized networks is that participating nodes do not collude and that they are run by independent parties. And unless this assumption is supported by policies or contracts, it doesn't hold as the network grows - there is no architecture that can enforce non-collusion and independence, it can only be enforced via policy. As Eric Hughes wrote (though in a different context) - "code alone doesn't cut it".

@SimpleXChat protocol-level privacy is the only kind that survives governance changes. if the architecture depends on policy, it's a promise, not a guarantee

Freedom of speech needs infrastructure that protects it by design — protocols, governance and funding. v6.5 release brings SimpleX Channels: a new model for online publishing built for participation privacy.👇

v6.5 is the first beta release of channels: - channel owners hold their own channel keys, - each channel uses multiple relays for reliability, - publishers can run their own chat relays, - channels can be added to our SimpleX Directory. Read more at simplex.chat/blog/20260430-…

arti.torproject.org/about/: "In the long run, we believe that this will not only speed up the development of our software but also result in higher quality software." This reads like they are accepting security regressions for the sake of faster development. Why not use C Tor that is at least battle tested and not an experimental Rust code?

@SimpleXChat @jim_havrilla We are using Arti Tor with vanguards and our own custom protocols. Thanks for sharing tho.

Sneak peek

@SecureLegion @jim_havrilla blog.torproject.org/announcing-van… - this is a good blog post to understand the limitations of hidden services on Tor.

Does the average person call their laptop a server? No. “Serverless” doesn’t mean no machines exist. It means there is no centralized, company-controlled infrastructure storing user data, holding message queues, mapping contact graphs, or brokering delivery. Tor relays are not our servers. They route encrypted traffic. They do not hold our users, our messages, our social graph, or our trust model. That distinction matters. We’re not here to put down other messaging apps. We’re here to clarify the technical difference. Different threat models require different infrastructure. And no system is perfect. Not Signal. Not Session. Not us. Not anyone. Even @NSAGov TEMPEST research showed that, under the right conditions, data can be reconstructed from electromagnetic emissions leaking from offline devices. That’s the reality of security. The goal isn’t magic. The goal is to remove unnecessary trust, remove centralized failure points, and make compromise as hard as possible.

@SecureLegion @jim_havrilla Tor is a choice, and it has its own upsides and downsides. It's still somebody else's servers, so it's wrong to call Tor-based network "serverless". In case of Tor you don't know who runs the relays, and it may be equally good and bad for security.

Before debating, one must define the term. In privacy-tech, a “server” refers to centralized infrastructure that stores and forwards user data — not just any computer connected to the internet. Secure: We don’t run servers. We don’t run Tor relays. Zero push servers — zero. Both peers run Tor hidden services. Messages are end-to-end between the two devices, full stop. SimpleX delivers via SimpleX Chat + Flux relays. We do not. That distinction is technical, not semantic.

@SecureLegion @jim_havrilla The problem with "serverless" is that it's a bit of a lie - there are always some servers that are used for mobile devices to communicate.

@SecureLegion @jim_havrilla And how would you avoid using servers, technically? The app chooses servers operated by different parties to deliver messages. By default, it's two independent operators that do not share any metadata - SimpleX Chat and Flux. Neither can see which IP addresses communicate.

It's not that simple. For example, operators may log IP addresses - no protocol design can stop it. Privacy policy does. Same about not sharing any metadata. Etc. That's wrong to think that tech alone can make policy redundant. Protocol design eliminates attacks on encryption, but it cannot eliminate all attacks even theoretically, such as statistical/timing correlation, analysing metadata across multiple nodes, etc. So policy improves threat model in these areas. But it doesn't replace secure protocol design of course - it complements it. This binary thinking - protocol vs policy - is just wrong, because neither alone is sufficient. A secure system must have both.

@SimpleXChat stronger privacy commitments from operators is the baseline encrypted messaging should have started with. the protocol should make the policy redundant

We updated SimpleX Chat Privacy Policy and Conditions: - Stronger privacy commitments from operators and apps. - New one-time links and public addresses. - Public channels released in v6.5 (beta). See all changes via the link in the comment 👇

@nikaido_hiro3 Major UI update is coming in v7 in May/June.

@SimpleXChat Simplex is already very feature-complete, and that’s a result of your hard work. The release of new features should be exciting, and I apologize for my earlier comment. However, I still feel a bit disappointed that there hasn’t been much progress in Simplex’s UI.

@nikaido_hiro3 Why do we need them? What do think needs attention?

@SimpleXChat You still don't have front-end engineers.

We are maintaining it in GitHub, so you can track changes: github.com/simplex-chat/s… The apps will show a notification with this change. The full text is here: simplex.chat/privacy/ Please let us know any questions or suggestions - many amendments were proposed by the users.

Our recommendation is to swap CLI-via-websocket approach to our new nodejs library. It integrates SimpleX Chat library via FFI, avoiding separate process that may crash and unauthenticated websocket connection - neither is critical problem, but requires more complex deployment. With nodejs library you would get a single self-contained process: npmjs.com/package/simple… (beta, will be stable this month)

Reviewed dangoldbj/openclaw-simplex adversarially. Clean design: bridges OpenClaw agents to SimpleX via local simplex-chat WS (localhost-only by default). Invite/QR-based pairing, no public bot ID, full E2EE from SimpleX, OpenClaw policies for allowlists/pairing. Risks are standard, not library-specific: host compromise exposes WS/CLI; unfiltered user msgs enable prompt injection on the AI agent; media support needs agent-side validation. No hardcoded secrets, no obvious injection paths or over-permissive code in the architecture. Strong privacy fit for self-hosted AI chats. Ship it.

That's why SimpleX Network is designed without both user and endpoint IDs - to protect their privacy and security.

@BES_5_FNR @dangoldbj @grok review the library adversarially and tell us what you think.

@SimpleXChat github.com/dangoldbj/open… @dangoldbj

@ElkimXOC It is agents-friendly - there is an npm library that can be used: npmjs.com/package/simple… (beta version, will be stable this month)

@SimpleXChat Any plans to make it more agents-friendly ? :)

@BES_5_FNR cool - share the library or setup :)

@SimpleXChat Been chatting with my OpenClaw today using SimpleX. So great.

@vekilakbey working on it :) Complexity is real - it's inherent in the problem of privacy and security. Making UX simple is hard.

📱"SWEEPING internet controls being put at the tip of a ministerial pen under the banner of preventing “harm” isn’t child protection – it’s a censor’s charter." @silkiecarlo writes about a proposed social media ban as MPs debate this issue today⤵️ telegraph.co.uk/news/2026/04/1…