+
+The web has a long history of [trading privacy](https://www.engadget.com/from-its-start-gmail-conditioned-us-to-trade-privacy-for-free-services-120009741.html) for “free” services. Traditionally, these services have also been centralized, closed-source, non-transparent, and profit-oriented. The companies behind these apps and services became prolific because of their disregard of privacy rights, which normalized lucrative surveillance capitalism. There is such an extensive global monopoly that in Africa, only 1 of the 5 biggest messaging apps in Africa isn't owned by Meta, notoriously known for spying not just through its own apps but even through [its competitors](https://qz.com/project-ghostbusters-facebook-meta-wiretap-snapchat-1851366814), – relentless, massive data harvesting that stretches far beyond its own walled gardens:
+
+Some of the world’s top engineers often go to these companies because of the benefits and financial opportunities. We can question their ethics all day long, but we also need to question if the web would look significantly different if there were as many opportunities at privacy-first companies with purpose and strong, proven moral boundaries, set up in a way that can guarantee operational independence from any shareholders and VCs.
+
+SimpleX could have taken the route of other companies in the privacy space, whether it’s Skiff which rushed to take a large amount of [VC money](https://techcrunch.com/2022/03/30/skiff-series-a-encrypted-workspaces/) only to [shutter its doors](https://www.techradar.com/computing/cyber-security/skiff-gets-bought-by-notion-raising-privacy-concerns) after an acquisition, leaving its users hanging with many unanswered questions, or giving up control of the company, which would puts its future solely in the hands of VCs with majority ownership. SimpleX aims to prevent this, and in fact has left money on the table to ensure that it does not occur. Had it not been for this information, I would not have joined, and I would have remained a user of the product, albeit a very cautious one, constantly wondering whether it will be sold or corrupted.
+
+It’s worth noting that some private foundations operate on the VC model in supporting nonprofits, either by requiring Board seats or requesting that their funding be used towards very specific objectives not always in alignment with the organization’s values and mission. It’s also worth noting that [some nonprofits](https://www.engadget.com/2019-05-31-sex-lies-and-surveillance-fosta-privacy.html) actually operate on the models of surveillance and censorship. Therefore, whether an organization or company is VC-backed or a nonprofit should not be the sole factor in deciding whether or not it is trustworthy. Actions are important, with full transparency being one of the most critical factors, and being fully open source being another to attract valid criticisms and audits to ensure any product or protocol lives up to its privacy and security promise. SimpleX Chat prides itself on being both transparent and open, on top of also being fully decentralized. If you’re new to it and eager to know more, you can start with [this overview](https://github.com/simplex-chat/simplexmq/blob/stable/protocol/overview-tjr.md).
+
+Another important consideration is that the SimpleX network does have a plan that would rely on users' payments for specific or tailored services, and not on some other sources of revenue or funds (ads, etc.). Building anything that users would be willing to pay for requires substantially more time and resources, hence the VC route to establish a business model that doesn’t translate to the user being the product. But any business services need to be separate from SimpleX as a public interest technology. As outlined in this [recent post](./20240323-simplex-network-privacy-non-profit-v5-6-quantum-resistant-e2e-encryption-simple-migration.md), I’ll be using my background in nonprofit governance structures to ensure that the SimpleX network protocols evolve under the stewardship of nonprofit entities in various jurisdictions, so that its continued evolution aligns more closely with the vision of community-driven, independent and decentralized governance. This would help create a necessary balance between different structures, in the same way many tech nonprofits also have for-profit subsidiaries to attract fee-for-service agreements to sustain their operations.
+
+In summary: My decision to join Simplex Chat, despite my deep-rooted beliefs and skepticism towards VC funding, reflects a broader realization: that the fight for privacy, security, and decentralization in today’s web is multifaceted and sometimes requires us to depart from our comfort zones to explore sustainable paths for continuous growth and impact so that open source privacy tools and protocols are no longer “niche”, but universally accessible standards. As long as nothing in this journey compromises our moral principles and integrity, this will remain a very worthwhile goal to pursue.
diff --git a/blog/20240416-dangers-of-metadata-in-messengers.md b/blog/20240416-dangers-of-metadata-in-messengers.md
new file mode 100644
index 0000000000..3b30003798
--- /dev/null
+++ b/blog/20240416-dangers-of-metadata-in-messengers.md
@@ -0,0 +1,52 @@
+---
+layout: layouts/article.html
+title: "The dangers of metadata in messengers"
+date: 2024-04-16
+previewBody: blog_previews/20240416.html
+image: images/20240416-metadata.png
+imageWide: true
+permalink: "/blog/20240416-dangers-of-metadata-in-messengers.html"
+---
+
+# The dangers of metadata in messengers
+
+**Published:** Apr 16, 2024
+
+_By [Esra'a al Shafei](https://mastodon.social/@alshafei)_
+
+In many countries around the world, phone numbers are attached to biometrics data and personal IDs. Telecommunications companies are either government owned or are heavily regulated, privately owned monopolies who comply with most government requests for backdoors or user data. The idea that today, we still need to give out our phone numbers as primary identifiers to be able to use the leading messaging apps should be frowned upon and actively challenged. It’s necessary to advocate for private alternatives in messaging that do not rely on user IDs of any kind - and yes, it’s possible.
+
+Messaging is still not where it needs to be. Privacy is confused with security, when both are not synonymous, and there are major gaps in helping users understand the fundamental differences.
+
+
+
+For example, while WhatsApp messages are [end-to-end encrypted](https://faq.whatsapp.com/820124435853543), let’s consider what you give up when you use it, per its own listings in app stores:
+
+- App activity (app interactions, in-app search history, and other user-generated content)
+- Location
+- Financial information (user payment info and payment history)
+- Contacts and their phone numbers
+- Groups you’re a member of
+- When you use the app and how often you use it
+- Device and other IDs
+- Personal info (email address, user IDs, phone number)
+
+This is called [metadata](https://en.wikipedia.org/wiki/Metadata). It reveals a wealth of information about you and your connections, and in the hands of a centralized monopoly, this can and does get misused in incredibly dangerous ways. Once such metadata is logged, it can create very detailed profiles about who you are, everywhere you’ve been, and everyone you’ve ever spoken to. In settling for apps that normalize this while giving you the illusion of privacy in their marketing, we are doing ourselves a disservice by accepting this as the default. Collectively, we aren’t doing enough to protect ourselves and our social graph from this invasive overreach.
+
+When stored, aggregated and analyzed, this metadata provides ample information that could potentially incriminate someone or be submitted to authorities. When WhatsApp and Facebook Messenger enabled end-to-end encryption for messages, of course it was a welcome and widely celebrated change. But it’s important to remember that not all end-to-end encryption utilizes the same standards, [some implementations are more secure](https://simplex.chat/blog/20240314-simplex-chat-v5-6-quantum-resistance-signal-double-ratchet-algorithm.html#how-secure-is-end-to-end-encryption-in-different-messengers) than others, so it’s something that shouldn’t necessarily be accepted at face value. More importantly: collecting and storing an obscene amount of metadata should invite global scrutiny, considering this data is often combined with whatever other information companies like Meta harvest about your identity (which is [a lot](https://www.vox.com/recode/23172691/meta-tracking-privacy-hospitals).)
+
+
+
+This is one of the many reasons why we need to resist giving out our phone numbers just to access an app, especially to do something as personal and intimate as private messaging. Even though users can sometimes mask their numbers with a username, their identity on the app is still fundamentally tied to their phone number. App operators have access to this, as well as user contacts. Additionally, with a simple modification to the app's source code, the contacts may also gain access in some cases. This should raise more concerns about privacy, and it makes the need for anonymity difficult to achieve.
+
+Everyone has a different threat model (and if you don’t yet, now is a good time to [create one](https://www.privacyguides.org/en/basics/threat-modeling/#creating-your-threat-model)). For many users today, WhatsApp and other apps may be sufficient for their specific needs, especially in connecting with families and friends who are already on the app and unlikely to migrate elsewhere. If that suits your life and needs, and if you’re aware and consciously accept the risks, great.
+
+But we also need to acknowledge that the world is becoming increasingly dangerous in the way AI is being used to [supercharge surveillance](https://www.forbes.com/sites/forbestechcouncil/2024/02/02/artificial-intelligence-the-new-eyes-of-surveillance/?sh=cd57bc214f27), and we need to be educated and aware of the risks this is already having on our lives and what it subjects others in your network to when you choose metadata-heavy apps as your primary form of communication. Having alternatives will always be important, even if it’s not what you default to for everyday messaging. Recognize who in your social circles might require the extra privacy, anonymity and security, so that you can play a role in protecting vulnerable individuals who need it most. The messaging app you choose implicates others as well, not just yourself, and while you personally may not require complete privacy, others might have their lives depend on it.
+
+End-to-end encryption is a solid start, but it's just the beginning of our pursuit for true privacy and security. True privacy means that even when legal demands come knocking, there's no useful metadata to hand over. It's not enough to just protect the content of messages; we need consistent innovation in protecting metadata too.
+
+Changing ingrained habits is tough, but your privacy is always worth the fight. Although giants like WhatsApp and Telegram may dominate global messaging for now, increasing concerns about data harvesting and AI-driven surveillance are fueling demand for alternatives. SimpleX Chat aims to be one of those strong alternatives, hence its radical focus on a decentralized framework with no user identifiers (in other words, nothing that uniquely identifies users on the protocol level to their contacts or to the relays) and extra optionality (self-hosting an [SMP server](https://simplex.chat/docs/server.html) or [XFTP server](https://simplex.chat/docs/xftp-server.html), access via Tor, [chat profiles](https://simplex.chat/docs/guide/chat-profiles.html) with incognito mode, etc.)
+
+As of today, most messaging alternatives, including SimpleX, will have some limitations. But with the limited resources we have, we are committed to daily progress towards creating a truly private messenger that anyone can use while maintaining the features that users have come to know and love in messaging interfaces. We want to be the prime example of a messenger that achieves genuine privacy without compromising it for convenience. We need to be able to reliably move away from small and niche use cases to endorsing and enforcing global standards for privacy and making it accessible for all users regardless of their technical expertise.
+
+We’re grateful for the users and [donors](https://github.com/simplex-chat/simplex-chat#help-us-with-donations) who have been following along on this journey thus far and helping with feedback, anything from bug reports to identifying potential risks. Building in the open has always been a necessity for transparency and ongoing [auditability](https://simplex.chat/blog/20221108-simplex-chat-v4.2-security-audit-new-website.html), because we don’t want anyone to just take our word for it. [See for yourself](https://github.com/simplex-chat) and engage in the discussions. We fully expect you to hold us accountable to our word.
diff --git a/blog/README.md b/blog/README.md
index 7f27c46c76..78cd0709ad 100644
--- a/blog/README.md
+++ b/blog/README.md
@@ -1,5 +1,21 @@
# Blog
+Apr 16. 2024 [The dangers of metadata in messengers](./20240416-dangers-of-metadata-in-messengers.md)
+
+_By [Esra'a al Shafei](https://mastodon.social/@alshafei)_
+
+It's important not to be complacent with the current standards of messaging, where metadata aggregation is still normalized in apps falsely and dangerously marketed as "private". This is a post exploring the fundamental differences between privacy and security.
+
+---
+
+Apr 4. 2024 [Why I joined SimpleX Chat](./20240404-why-i-joined-simplex-chat-esraa-al-shafei.md)
+
+_By [Esra'a al Shafei](https://mastodon.social/@alshafei)_
+
+Transitioning from a lifelong career dedicated to nonprofits, including Board roles at organizations like the Wikimedia Foundation, Access Now and Tor, my decision to join SimpleX Chat may come as a surprise to some. But, as I step into this new chapter, I want to share the insights and convictions that have guided me here, shedding light on what I think sets SimpleX Chat apart and why this move feels like an essential learning opportunity.
+
+---
+
Mar 23, 2024 [SimpleX network: real privacy and stable profits, non-profits for protocols, v5.6 released with quantum resistant e2e encryption and simple profile migration](./20240323-simplex-network-privacy-non-profit-v5-6-quantum-resistant-e2e-encryption-simple-migration.md)
SimpleX network: deliver real privacy via a profitable business and non-profit protocol governance:
diff --git a/blog/images/20240404-esraa.png b/blog/images/20240404-esraa.png
new file mode 100644
index 0000000000..baee242023
Binary files /dev/null and b/blog/images/20240404-esraa.png differ
diff --git a/blog/images/20240404-messsaging-apps.png b/blog/images/20240404-messsaging-apps.png
new file mode 100644
index 0000000000..6081a468a1
Binary files /dev/null and b/blog/images/20240404-messsaging-apps.png differ
diff --git a/blog/images/20240416-metadata.png b/blog/images/20240416-metadata.png
new file mode 100644
index 0000000000..743930bf15
Binary files /dev/null and b/blog/images/20240416-metadata.png differ
diff --git a/blog/images/20240416-whatsapp.jpg b/blog/images/20240416-whatsapp.jpg
new file mode 100644
index 0000000000..399235347a
Binary files /dev/null and b/blog/images/20240416-whatsapp.jpg differ
diff --git a/cabal.project b/cabal.project
index 62115c136b..02deb0dbfb 100644
--- a/cabal.project
+++ b/cabal.project
@@ -12,7 +12,7 @@ constraints: zip +disable-bzip2 +disable-zstd
source-repository-package
type: git
location: https://github.com/simplex-chat/simplexmq.git
- tag: 6bc4f6c94e11f59604b0d9c576e62e01bc08b4cd
+ tag: c00c223f3bb295a62d8507e453bbeac61d102e3a
source-repository-package
type: git
diff --git a/docs/ANDROID.md b/docs/ANDROID.md
index fa8921c827..61f81d1a40 100644
--- a/docs/ANDROID.md
+++ b/docs/ANDROID.md
@@ -3,7 +3,7 @@ title: Accessing files in Android app
revision: 07.02.2023
---
-| 07.02.2023 | EN, [CZ](/docs/lang/cs/ANDROID.md), [FR](/docs/lang/fr/ANDROID.md) |
+| 07.02.2023 | EN, [CZ](/docs/lang/cs/ANDROID.md), [FR](/docs/lang/fr/ANDROID.md), [PL](/docs/lang/pl/ANDROID.md) |
# Accessing files in Android app
diff --git a/docs/CLI.md b/docs/CLI.md
index baf79bb3bc..d4f799c7af 100644
--- a/docs/CLI.md
+++ b/docs/CLI.md
@@ -3,7 +3,7 @@ title: Terminal CLI
revision: 31.01.2023
---
-| Updated 31.01.2023 | Languages: EN, [FR](/docs/lang/fr/CLI.md), [CZ](/docs/lang/cs/CLI.md) |
+| Updated 31.01.2023 | Languages: EN, [FR](/docs/lang/fr/CLI.md), [CZ](/docs/lang/cs/CLI.md), [PL](/docs/lang/pl/CLI.md) |
# SimpleX Chat terminal (console) app for Linux/MacOS/Windows
diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md
index aaf452af00..bc013cd7eb 100644
--- a/docs/CONTRIBUTING.md
+++ b/docs/CONTRIBUTING.md
@@ -3,7 +3,7 @@ title: Contributing guide
revision: 31.01.2023
---
-| Updated 31.01.2023 | Languages: EN, [FR](/docs/lang/fr/CONTRIBUTING.md), [CZ](/docs/lang/cs/CONTRIBUTING.md) |
+| Updated 31.01.2023 | Languages: EN, [FR](/docs/lang/fr/CONTRIBUTING.md), [CZ](/docs/lang/cs/CONTRIBUTING.md), [PL](/docs/lang/pl/CONTRIBUTING.md) |
# Contributing guide
diff --git a/docs/DOWNLOADS.md b/docs/DOWNLOADS.md
index b394c9dd27..0432b0f92e 100644
--- a/docs/DOWNLOADS.md
+++ b/docs/DOWNLOADS.md
@@ -19,7 +19,7 @@ You can get the latest beta releases from [GitHub](https://github.com/simplex-ch
-Using the same profile as on mobile device is not yet supported – you need to create a separate profile to use desktop apps.
+You can link your mobile device with desktop to use the same profile remotely, but this is only possible when both devices are connected to the same local network.
**Linux**: [AppImage](https://github.com/simplex-chat/simplex-chat/releases/latest/download/simplex-desktop-x86_64.AppImage) (most Linux distros), [Ubuntu 20.04](https://github.com/simplex-chat/simplex-chat/releases/latest/download/simplex-desktop-ubuntu-20_04-x86_64.deb) (and Debian-based distros), [Ubuntu 22.04](https://github.com/simplex-chat/simplex-chat/releases/latest/download/simplex-desktop-ubuntu-22_04-x86_64.deb).
diff --git a/docs/SERVER.md b/docs/SERVER.md
index e476c7250c..c29a805452 100644
--- a/docs/SERVER.md
+++ b/docs/SERVER.md
@@ -3,7 +3,7 @@ title: Hosting your own SMP Server
revision: 31.07.2023
---
-| Updated 05.06.2023 | Languages: EN, [FR](/docs/lang/fr/SERVER.md), [CZ](/docs/lang/cs/SERVER.md) |
+| Updated 05.06.2023 | Languages: EN, [FR](/docs/lang/fr/SERVER.md), [CZ](/docs/lang/cs/SERVER.md), [PL](/docs/lang/pl/SERVER.md) |
# Hosting your own SMP Server
diff --git a/docs/SIMPLEX.md b/docs/SIMPLEX.md
index 7ed01efa3c..ec25afaf88 100644
--- a/docs/SIMPLEX.md
+++ b/docs/SIMPLEX.md
@@ -3,7 +3,7 @@ title: SimpleX platform
revision: 07.02.2023
---
-| Updated 07.02.2023 | Languages: EN, [FR](/docs/lang/fr/SIMPLEX.md), [CZ](/docs/lang/cs/SIMPLEX.md) |
+| Updated 07.02.2023 | Languages: EN, [FR](/docs/lang/fr/SIMPLEX.md), [CZ](/docs/lang/cs/SIMPLEX.md), [PL](/docs/lang/pl/SIMPLEX.md) |
# SimpleX platform - motivation and comparison
## Problems
diff --git a/docs/TRANSLATIONS.md b/docs/TRANSLATIONS.md
index 85b24b368e..d5c1cdef0b 100644
--- a/docs/TRANSLATIONS.md
+++ b/docs/TRANSLATIONS.md
@@ -3,7 +3,7 @@ title: Contributing translations to SimpleX Chat
revision: 19.03.2023
---
-| 19.03.2023 | EN, [CZ](/docs/lang/cs/TRANSLATIONS.md), [FR](/docs/lang/fr/TRANSLATIONS.md) |
+| 19.03.2023 | EN, [CZ](/docs/lang/cs/TRANSLATIONS.md), [FR](/docs/lang/fr/TRANSLATIONS.md), [PL](/docs/lang/pl/TRANSLATIONS.md) |
# Contributing translations to SimpleX Chat
diff --git a/docs/TRANSPARENCY.md b/docs/TRANSPARENCY.md
new file mode 100644
index 0000000000..55808c83c8
--- /dev/null
+++ b/docs/TRANSPARENCY.md
@@ -0,0 +1,29 @@
+---
+title: Transparency Reports
+permalink: /transparency/index.html
+revision: 09.04.2024
+---
+
+# Transparency Reports
+
+**Updated**: Apr 9, 2024
+
+SimpleX Chat Ltd. is a company registered in the UK – it develops communication software enabling users to operate and communicate via SimpleX network, without user profile identifiers of any kind, and without having their data hosted by any network infrastructure operators.
+
+This page will include any and all reports on requests for user data.
+
+*To date, we received none*.
+
+Our objective is to consistently ensure that no user data and absolute minimum of the metadata required for the network to function is available for disclosure by any infrastructure operators, under any circumstances.
+
+**Helpful resources**:
+- [Privacy policy](https://github.com/simplex-chat/simplex-chat/blob/stable/PRIVACY.md)
+- [Privacy and security: technical details and limitations](https://github.com/simplex-chat/simplex-chat?tab=readme-ov-file#privacy-and-security-technical-details-and-limitations)
+- Whitepaper:
+ - [Trust in servers](https://github.com/simplex-chat/simplexmq/blob/stable/protocol/overview-tjr.md#trust-in-servers)
+ - [Encryption Primitives Used](https://github.com/simplex-chat/simplexmq/blob/stable/protocol/overview-tjr.md#encryption-primitives-used)
+ - [Threat model](https://github.com/simplex-chat/simplexmq/blob/stable/protocol/overview-tjr.md#threat-model)
+
+Have a more specific question? Reach out to us via [SimpleX Chat](https://simplex.chat/contact#/?v=1&smp=smp%3A%2F%2FPQUV2eL0t7OStZOoAsPEV2QYWt4-xilbakvGUGOItUo%3D%40smp6.simplex.im%2FK1rslx-m5bpXVIdMZg9NLUZ_8JBm8xTt%23%2F%3Fv%3D1%26dh%3DMCowBQYDK2VuAyEALDeVe-sG8mRY22LsXlPgiwTNs9dbiLrNuA7f3ZMAJ2w%253D%26srv%3Dbylepyau3ty4czmn77q4fglvperknl4bi2eb2fdy2bh4jxtf32kf73yd.onion) or via email [chat@simplex.chat](mailto:chat@simplex.chat).
+
+For any sensitive questions please use SimpleX Chat or encrypted email messages using the key for this address from [keys.openpgp.org](https://keys.openpgp.org/search?q=chat%40simplex.chat) (its fingerprint is `FB44 AF81 A45B DE32 7319 797C 8510 7E35 7D4A 17FC`) and make your key available for a secure reply.
diff --git a/docs/WEBRTC.md b/docs/WEBRTC.md
index 7978d21ec7..8ce31bf959 100644
--- a/docs/WEBRTC.md
+++ b/docs/WEBRTC.md
@@ -3,7 +3,7 @@ title: Using custom WebRTC ICE servers in SimpleX Chat
revision: 31.01.2023
---
-| Updated 31.01.2023 | Languages: EN, [FR](/docs/lang/fr/WEBRTC.md), [CZ](/docs/lang/cs/WEBRTC.md) |
+| Updated 31.01.2023 | Languages: EN, [FR](/docs/lang/fr/WEBRTC.md), [CZ](/docs/lang/cs/WEBRTC.md), [PL](/docs/lang/pl/WEBRTC.md) |
# Using custom WebRTC ICE servers in SimpleX Chat
diff --git a/docs/lang/cs/ANDROID.md b/docs/lang/cs/ANDROID.md
index 4edfc3018c..3c401f1d1b 100644
--- a/docs/lang/cs/ANDROID.md
+++ b/docs/lang/cs/ANDROID.md
@@ -2,7 +2,7 @@
title: Přístup k souborům v aplikaci Android
revision: 07.02.2023
---
-| Aktualizováno 07.02.2023 | Jazyky: CZ, [EN](/docs/ANDROID.md) |
+| Aktualizováno 07.02.2023 | Jazyky: CZ, [EN](/docs/ANDROID.md), [PL](/docs/lang/pl/ANDROID.md) |
# Přístup k souborům v aplikaci Android
diff --git a/docs/lang/cs/CLI.md b/docs/lang/cs/CLI.md
index aa5a2ba281..9cbce8e6fe 100644
--- a/docs/lang/cs/CLI.md
+++ b/docs/lang/cs/CLI.md
@@ -2,7 +2,7 @@
title: SimpleX Chat terminálová
revision: 31.01.2023
---
-| Aktualizováno 31.01.2023 | Jazyky: CZ, [EN](/docs/CLI.md), [FR](/docs/lang/fr/CLI.md) |
+| Aktualizováno 31.01.2023 | Jazyky: CZ, [EN](/docs/CLI.md), [FR](/docs/lang/fr/CLI.md), [PL](/docs/lang/pl/CLI.md) |
# SimpleX Chat terminálová (konzolová) aplikace pro Linux/MacOS/Windows
diff --git a/docs/lang/cs/CONTRIBUTING.md b/docs/lang/cs/CONTRIBUTING.md
index 26c746e7d2..17574bed4a 100644
--- a/docs/lang/cs/CONTRIBUTING.md
+++ b/docs/lang/cs/CONTRIBUTING.md
@@ -2,7 +2,7 @@
title: Průvodce přispíváním
revision: 31.01.2023
---
-| Aktualizováno 31.01.2023 | Jazyky: CZ, [EN](/docs/CONTRIBUTING.md), [FR](/docs/lang/fr/CONTRIBUTING.md) |
+| Aktualizováno 31.01.2023 | Jazyky: CZ, [EN](/docs/CONTRIBUTING.md), [FR](/docs/lang/fr/CONTRIBUTING.md), [PL](/docs/lang/pl/CONTRIBUTING.md) |
# Průvodce přispíváním
diff --git a/docs/lang/cs/README.md b/docs/lang/cs/README.md
index 9423cc96b8..764499cdae 100644
--- a/docs/lang/cs/README.md
+++ b/docs/lang/cs/README.md
@@ -1,4 +1,4 @@
-| Aktualizováno 07.02.2023 | Jazyky: CZ, [EN](/docs/README.md), [FR](/docs/lang/fr/README.md) |
+| Aktualizováno 07.02.2023 | Jazyky: CZ, [EN](/docs/README.md), [FR](/docs/lang/fr/README.md), [PL](/docs/lang/pl/README.md) |
](http://simplex.chat/blog/20221108-simplex-chat-v4.2-security-audit-new-website.html) [
](https://www.privacyguides.org/en/real-time-communication/#simplex-chat) [
](https://www.kuketz-blog.de/simplex-eindruecke-vom-messenger-ohne-identifier/)
+
+## Witamy w SimpleX Chat!
+
+1. 📲 [Zainstaluj aplikację](#zainstaluj-aplikację).
+2. ↔️ [Połącz się z naszym zespołem](#połącz-się-z-naszym-zespołem), [dołącz do grup użytkowników](#dołącz-do-grup-użytkowników) oraz [śledź nasze aktualizacje](#śledź-nasze-aktualizacje).
+3. 🤝 [Wykonaj prywatne połączenie](#wykonaj-prywatne-połączenie) ze znajomym.
+4. 🔤 [Pomóż w tłumaczeniu SimpleX Chat](#pomóż-nam-przetłumaczyć-simplex-chat).
+5. ⚡️ [Kontrybuuj](#kontrybuuj) i [wesprzyj nas dotacjami](#wesprzyj-nas-dotacjami).
+
+[Dowiedz się więcej na temat SimpleX Chat](#informacje).
+
+## Zainstaluj aplikację
+
+[
+
+Po wykonaniu połączenia możesz [zweryfikować kod bezpieczeństwa połączenia](./blog/20230103-simplex-chat-v4.4-disappearing-messages.md#connection-security-verification).
+
+## Poradnik dla użytkownika (NOWE)
+
+Przeczytaj o funkcjach i ustawieniach aplikacji w nowym [Przewodniku użytkownika](./docs/guide/README.md).
+
+## Pomóż nam przetłumaczyć SimpleX Chat
+
+Dzięki naszym użytkownikom i [Weblate](https://hosted.weblate.org/engage/simplex-chat/), aplikacje SimpleX Chat, strona internetowa i dokumenty są tłumaczone na wiele innych języków.
+
+Dołącz do naszych tłumaczy, aby pomóc SimpleX w rozwoju!
+
+|region|język |kontrybutor|[Android](https://play.google.com/store/apps/details?id=chat.simplex.app) i [iOS](https://apps.apple.com/us/app/simplex-chat/id1605771084)|[strona](https://simplex.chat)|dokumenty na GitHubie|
+|:----:|:-------:|:---------:|:---------:|:---------:|:---------:|
+|🇬🇧 en|English | |✓|✓|✓|✓|
+|ar|العربية |[jermanuts](https://github.com/jermanuts)|[](https://hosted.weblate.org/projects/simplex-chat/android/ar/)
diff --git a/docs/lang/pl/SIMPLEX.md b/docs/lang/pl/SIMPLEX.md
new file mode 100644
index 0000000000..ff7106d84c
--- /dev/null
+++ b/docs/lang/pl/SIMPLEX.md
@@ -0,0 +1,102 @@
+---
+title: Platfoma SimpleX
+revision: 07.02.2023
+---
+
+| Updated 07.02.2023 | Języki: PL, [EN](/docs/SIMPLEX.md), [FR](/docs/lang/fr/SIMPLEX.md), [CZ](/docs/lang/cs/SIMPLEX.md) |
+# Platfoma SimpleX - motywacja i porównanie
+
+## Problemy
+
+Istniejące komunikatory oraz protokoły borykają się ze wszystkimi lub kilkoma podanymi problemami:
+
+- Brak zachowania prywatności profilu i kontaktów użytkownika (zachowanie poufności metadanych).
+- Brak ochrony (lub jedynie opcjonalna ochrona) przed atakami MITM przez dostawcę usług przy użyciu szyfrowania [end to end](1)
+- Niechciane wiadomości (spam i nadużycia).
+- Brak własności danych i ich ochrony.
+- Dla nietechnicznych użytkowników używanie niescentralizowanych protokołów jest skomplikowane.
+
+Koncentracja komunikacji na niewielkiej liczbie scentralizowanych platform sprawia, że rozwiązanie tych problemów jest dość trudne.
+
+## Proponowane rozwiązanie
+
+Proponowany zestaw protokołów pozwala rozwiązać te problemy poprzez przechowywanie zarówno wiadomości, jak i kontaktów wyłącznie na urządzeniach klienckich, redukując rolę serwerów do zwykłych przekaźników wiadomości. Wymagają one jedynie autoryzacji wiadomości wysyłanych do kolejek, ale NIE wymagają uwierzytelniania użytkowników - dzięki temu chronione są nie tylko wiadomości, ale także metadane, ponieważ użytkownicy nie mają przypisanych do siebie żadnych identyfikatorów - w przeciwieństwie do innych platform.
+
+Zobacz [whitepaper](https://github.com/simplex-chat/simplexmq/blob/master/protocol/overview-tjr.md) po więcej informacji o zadaniach platformy oraz by dowiedzieć się jak wygląda koncepcja techniczna modelu.
+
+## Dlaczego SimpleX
+
+## SimpleX podchodzi do problemu prywatności i bezpieczeństwa w unikalny sposób
+
+Każdy powinien zwracać uwagę na prywatność i bezpieczeństwo swojej komunikacji - nawet zwykłe rozmowy mogą narazić Cię na niebezpieczeństwo.
+
+### Pełna prywatność Twojej tożsamości, profilu, kontaktu i metadanych
+
+**W przeciwieństwie do innych komunikatorów, SimpleX nie posiada żadnych identyfikatorów przypisanych do użytkowników** - nie wymaga użycia numeru telefonu (jak Signal czy Whatsapp), adresu opartego o domenę (jak email, XMPP czy Matrix), nazw użytkownika (jak Telegram), kluczy publicznych czy nawet losowych numerów (jak pozostałe komunikatory) do identyfikowania użytkowników - nie wiemy nawet ile osób używa SimpleX.
+
+Do dostarczania wiadomości zamiast identyfikatorów użytkowników, których używają wszystkie inne platformy, SimpleX wykorzystuje adresy jednokierunkowych (simpleksowych) kolejek wiadomości. Korzystanie z SimpleX jest jak posiadanie innego adresu e-mail lub numeru telefonu dla każdego kontaktu, ale bez kłopotów z zarządzaniem tymi wszystkimi adresami. W niedalekiej przyszłości aplikacje SimpleX będą również automatycznie zmieniać kolejki wiadomości, przenosząc konwersacje z jednego serwera na drugi, aby zapewnić użytkownikom jeszcze lepszą prywatność.
+
+Takie podejście chroni prywatność tego, z kim się komunikujesz, ukrywając jego tożsamość oraz fakt komunikacji przed serwerami platformy SimpleX i wszelkimi obserwatorami. Prywatność komunikacji można dodatkowo zwiększyć, konfigurując dostęp do sieci w taki sposób, by łączyć się z serwerami SimpleX za pośrednictwem sieci transportowej typu overlay, np. sieci Tor.
+
+### Najlepsza ochrona przed spamem i nadużyciami
+
+Ponieważ nie masz żadnego identyfikatora na platformie SimpleX, nie można się z Tobą skontaktować, chyba że udostępnisz jednorazowy link z zaproszeniem lub opcjonalny tymczasowy adres użytkownika. Nawet przy użyciu opcjonalnych adresów użytkownika, które mogą być wykorzystywane do wysyłania spamu z prośbami o kontakt, można je zmienić lub całkowicie usunąć bez utraty jakichkolwiek połączeń (kontaktów).
+
+### Pełna kontrola i bezpieczeństwo Twoich danych
+
+SimpleX przechowuje wszystkie dane użytkownika na urządzeniach klienckich, wiadomości są przetrzymywane tylko tymczasowo na serwerach przekaźnikowych SimpleX do momentu ich odebrania, po czym są trwale usuwane.
+
+Używamy przenośnego formatu bazy danych, który może być używany na wszystkich obsługiwanych urządzeniach - wkrótce dodamy możliwość eksportu bazy danych czatu z aplikacji mobilnej, aby można było jej używać na innym urządzeniu.
+
+W przeciwieństwie do serwerów sieci federowanych (e-mail, XMPP lub Matrix), serwery SimpleX nie przechowują kont użytkowników, a jedynie przekazują wiadomości do odbiorców, chroniąc prywatność obu stron. Nie ma żadnych identyfikatorów ani zaszyfrowanych wiadomości występujących wspólnie z wysłanym i odbieranym ruchem serwera, dzięki dodatkowej warstwie szyfrowania dostarczanych wiadomości. Jeśli więc ktoś obserwuje ruch na serwerze, nie może łatwo określić, kto komunikuje się z kim (sprawdź [SimpleX whitepaper](https://github.com/simplex-chat/simplexmq/blob/master/protocol/overview-tjr.md) by dowiedzieć się o znanych atakach korelacji ruchu).
+
+### Użytkownicy są właścicielami sieci SimpleX
+
+Możesz używać SimpleX na własnych serwerach i nadal komunikować się z ludźmi za pomocą serwerów, które są wstępnie skonfigurowane w aplikacjach lub z dowolnymi innymi serwerami SimpleX.
+
+Platforma SimpleX korzysta z otwartego protokołu i zapewnia zestaw SDK do tworzenia czatbotów, umożliwiając implementację usług, z którymi użytkownicy mogą wchodzić w interakcje za pośrednictwem aplikacji SimpleX Chat - naprawdę nie możemy się doczekać, aby zobaczyć, jakie usługi oparte o SimpleX można stworzyć.
+
+Jeśli rozważasz stworzenie czegoś w oparciu o platformę SimpleX, niezależnie od tego, czy chodzi o usługi czatbotów dla użytkowników aplikacji SimpleX, czy też integrację biblioteki SimpleX Chat z aplikacjami mobilnymi, skontaktuj się z nami, aby uzyskać porady i wsparcie.
+
+## Porównanie z innymi protokołami
+
+| | SimpleX Chat | Signal, duże platformy | XMPP, Matrix | Protokoły P2P |
+| :---------------------------------------------------------- | :----------------------: | :--------------------: | :-------------: | :-------------: |
+| Wymaga identyfikatorów użytkownika | Nie = prywatny | Tak1 | Tak2 | Tak3 |
+| Możliwość ataku MITM | Nie = bezpieczny | Tak4 | Tak | Tak |
+| Polega na DNS | Nie = odporny na cenzurę | Tak | Tak | Nie |
+| Pojedynczy operator lub sieć | Nie = zdecentralizowany | Tak | Nie | Tak5 |
+| Scentralizowanie lub możliwość ataku obejmującego całą sieć | Nie = odporny na cenzurę | Tak | Tak2 | Tak6 |
+
+1. Zwykle opiera się na numerze telefonu, w niektórych przypadkach na nazwie użytkownika.
+2. Bazuje na DNS.
+3. Klucz publiczny lub inny globalnie unikalny identyfikator.
+4. Jeśli serwery operatora zostaną przejęte.
+5. Mimo że sieci P2P i sieci oparte na kryptowalutach są rozproszone, nie są w pełni zdecentralizowane - działają jako pojedyncza sieć, z pojedynczą przestrzenią nazw adresów użytkowników.
+6. Sieci P2P albo mają jakiś centralny serwer, albo cała sieć może zostać przejęta - patrz następna sekcja.
+
+## Porównanie z komunikatorami [P2P][9]
+
+Istnieje kilka protokołów czatu/wiadomości P2P i implementacji, które mają na celu rozwiązanie problemu prywatności i centralizacji, ale mają one swój własny szereg problemów, które sprawiają, że są mniej niezawodne niż proponowany projekt, są bardziej skomplikowane w implementacji i analizie oraz są bardziej podatne na ataki.
+
+1. Sieci [P2P][9] korzystają z jakiegoś rodzaju [DHT][10] do routowania wiadomości/zapytań po sieci. Implementacje DHT mają złożone konstrukcje, muszą równoważyć niezawodność, gwarancję dostawy i czas oczekiwania. Proponowany model zapewnia zarówno większą gwarancję dostarczalności, jak i mniejsze opóźnienia (wiadomość jest przekazywana wiele razy równolegle, za każdym razem przez jeden węzeł, przy użyciu serwerów wybranych przez odbiorcę, podczas gdy w sieciach P2P wiadomość jest przekazywana przez `O(log N)` węzłów sekwencyjnie, przy użyciu węzłów wybranych przez algorytm).
+
+2. Proponowany model, w przeciwieństwie do większości sieci P2P, nie posiada żadnych globalnych identyfikatorów użytkowników, nawet tymczasowych.
+
+3. P2P samo w sobie nie rozwiązuje problemu [ataku MITM][2], a większość istniejących rozwiązań nie wykorzystuje komunikacji out-of-band do początkowej wymiany kluczy. Proponowany projekt wykorzystuje wiadomości out-of-band lub (w niektórych przypadkach) istniejące wcześniej bezpieczne i zaufane połączenia do początkowej wymiany kluczy.
+
+4. Implementacje P2P mogą być blokowane przez niektórych dostawców Internetu (tak jak [BitTorrent][11]). Proponowany model jest niezależny od rodzaju transmisji - może działać na standardowych protokołach sieciowych, a serwery mogą działać na tych samych domenach, co strony internetowe.
+
+5. Wszystkie znane sieci P2P mogą być podatne na [atak typu Sybil][12], ponieważ każdy węzeł jest wykrywalny, a sieć działa jako całość. Znane środki mające na celu zmniejszenie prawdopodobieństwa ataku typu Sybil wymagają zastosowania scentralizowanego komponentu lub kosztownego [proof of work][13]. Proponowany model, przeciwnie, nie ma możliwości wykrycia serwera - serwery nie są połączone, nie są znane sobie nawzajem i wszystkim klientom. Sieć SimpleX jest pofragmentowana i działa jako wiele odizolowanych połączeń. Uniemożliwia to ataki na całą sieć SimpleX - nawet jeśli niektóre serwery są zagrożone, inne części sieci mogą działać normalnie, a dotknięci atakiem użytkownicy mogą przełączyć się na inne serwery bez utraty kontaktów lub wiadomości.
+
+6. Sieci P2P są prawdopodobnie [podatne][14] na [atak DRDoS][15]. W proponowanym modelu klienci przekazują tylko ruch ze znanych zaufanych połączeń i nie mogą być wykorzystywani do odbijania i wzmacniania ruchu w całej sieci.
+
+[1]: https://pl.wikipedia.org/wiki/Szyfrowanie_od_ko%C5%84ca_do_ko%C5%84ca
+[2]: https://pl.wikipedia.org/wiki/Atak_man_in_the_middle
+[9]: https://pl.wikipedia.org/wiki/Peer-to-peer
+[10]: https://pl.wikipedia.org/wiki/Rozproszona_tablica_mieszaj%C4%85ca
+[11]: https://pl.wikipedia.org/wiki/BitTorrent
+[12]: https://en.wikipedia.org/wiki/Sybil_attack
+[13]: https://pl.wikipedia.org/wiki/Proof_of_Work
+[14]: https://www.usenix.org/conference/woot15/workshop-program/presentation/p2p-file-sharing-hell-exploiting-bittorrent
+[15]: https://pl.wikipedia.org/wiki/DRDoS
diff --git a/docs/lang/pl/TRANSLATIONS.md b/docs/lang/pl/TRANSLATIONS.md
new file mode 100644
index 0000000000..36daa5a148
--- /dev/null
+++ b/docs/lang/pl/TRANSLATIONS.md
@@ -0,0 +1,104 @@
+---
+title: Współtworzenie tłumaczenia SimpleX Chat
+revision: 19.03.2023
+---
+
+| 19.03.2023 | PL, [EN](/docs/TRANSLATIONS.md), [CZ](/docs/lang/cs/TRANSLATIONS.md), [FR](/docs/lang/fr/TRANSLATIONS.md)|
+
+# Współtworzenie tłumaczenia SimpleX Chat
+
+Dziękujemy za zainteresowanie się tłumaczeniem SimpleX Chat - to bardzo pomaga w uczynieniu go dostępnym dla szerszego grona użytkowników i naprawdę doceniamy Twoją pomoc.
+
+Wymaga to znacznej inwestycji czasu - większość ludzi tego początkowo nie docenia - oraz stałej opieki w miarę rozwoju aplikacji.
+
+Ten dokument został stworzony, po to by przyspieszyć ten proces i podzielić się kilkoma ważnymi "gafami", które odkryliśmy podczas pracy z Weblate - platformą, której używamy do tłumaczeń interfejsu.
+
+## Zanim rozpoczniesz tłumaczenie
+
+1. Utwórz konto w Weblate, używając tego samego adresu e-mail, którego używasz na platformie GitHub - dzięki temu Twój wkład będzie powiązany z kontem GitHub, co może okazać się dla Ciebie przydatne w niektórych przypadkach. Gdy tłumaczenie zostanie udostępnione użytkownikom, dodamy nazwę twojego konta do [listy tłumaczy] (https://github.com/simplex-chat/simplex-chat#translate-the-apps), chyba że poprosisz nas, abyśmy tego nie robili.
+
+2. Przed rozpoczęciem tłumaczenia należy podpisać prostą umowę licencyjną za pośrednictwem Weblate - ma to na celu uniknięcie konfliktów związanych z prawami własności intelektualnej. Kopia tej umowy jest również [dostępna tutaj](https://github.com/simplex-chat/cla/blob/master/CLA.md).
+
+3. Możemy również dodać Cię do grupy tłumaczy w przypadku jakichkolwiek pytań i aktualizacji - skontaktuj się z programistami za pośrednictwem czatu (po zainstalowaniu aplikacji lub później, poprzez "Wyślij pytania i pomysły" w ustawieniach aplikacji).
+
+## Proces tłumaczenia
+
+Najłatwiej jest najpierw przetłumaczyć aplikację na Androida, a dopiero później aplikację na iOS, ponieważ przetłumaczone ciągi Androidowej aplikacji są skonfigurowane jako słownik dla iOS.
+
+Kroki są następujące:
+
+1. [Tłumaczysz aplikację na Androida](#translating-android-app) w Weblate.
+2. [Sprawdzamy i publikujemy tłumaczenia aplikacji na Androida](#releasing-android-app-translations).
+3. Sprawdzasz tłumaczenia w aplikacji i poprawiasz ewentualne błędy.
+4. [Tłumaczysz aplikację iOS w Weblate](#translating-ios-app).
+5. Sprawdzamy i publikujemy tłumaczenia aplikacji iOS.
+
+### Tłumaczenie aplikacji na Androida
+
+1. Zacznij od [aplikacji na Androida](https://hosted.weblate.org/projects/simplex-chat/android/), zarówno podczas wykonywania najbardziej czasochłonnego tłumaczenia wstępnego, jak i dodawania ciągów później. Ze względu na to, że po pierwsze, ciągi w systemie iOS mogą pojawiać się w Weblate z pewnym opóźnieniem, ponieważ wymagają ręcznego zatwierdzenia z naszej strony, zanim będą widoczne, a po drugie, aplikacja na Androida jest skonfigurowana jako słownik dla aplikacji na iOS. 2/3 wszystkich ciągów wymaga tylko kliknięcia, aby przenieść je z Androida na iOS (nadal zajmuje to trochę czasu, Weblate niestety tego nie automatyzuje).
+
+2. Niektóre ciągi nie wymagają tłumaczenia, ale nadal trzeba je skopiować - w interfejsie użytkownika weblate znajduje się odpowiedni przycisk:
+
+
+
+3. Weblate posiada również automatyczne sugestie, które mogą przyspieszyć ten proces. Czasami mogą być używane w niezmienionej formie, a czasami wymagają edycji - kliknij, aby użyć ich w tłumaczeniach.
+
+4. Zwróć również uwagę na Klucz ciągu (znajduje się po prawej stronie ekranu) - może on dać ci podpowiedź, co ten ciąg oznacza, gdy jego znaczenie jest niejasne. Przykładowo, klucz dla " Dodatkowy akcent" ( nie wiadomo) to "color_primary_variant" (nieco bardziej jasne, że odnosi się do koloru używanego w aplikacji).
+
+5. Gdy wszystkie ciągi w aplikacji na Androida zostaną przetłumaczone, przejrzyj je, aby zapewnić spójny styl i język, tak aby te same słowa były konsekwentnie używane do podobnych działań użytkownika, tak samo jak w języku angielskim. Czasami będziesz musiał użyć różnych słów w przypadkach, gdy angielski ma tylko jedno, spróbuj użyć tych wyborów spójnie w podobnych kontekstach, aby uprościć obsługę użytkownikom końcowym.
+
+Prosimy również o sprawdzenie tłumaczeń przy użyciu przeglądarki Chrome i funkcji *Tłumacz na angielski* w trybie _Przeglądaj_ w weblate - tak będziemy sprawdzać tłumaczenia przed ich opublikowaniem. Popraw wszelkie błędy i dodaj komentarze w przypadkach, gdy uzasadnione jest użycie różnych tłumaczeń - znacznie przyspieszy to weryfikację.
+
+### Udostępnianie tłumaczeń dla aplikacji na Androida
+
+Gdy aplikacja na Androida zostanie przetłumaczona, poinformuj nas o tym.
+
+My wtedy:
+ - przejrzymy wszystkie tłumaczenia i zasugerujemy ewentualne poprawki - to również zajmie trochę czasu :)
+ - scalimy je z kodem źródłowym - w tym czasie weblate będzie ustawiony na blokadę zmian.
+ - stworzymy wersje beta aplikacji na iOS i Androida - możemy również dodać Cię do wewnętrznych grup testerów, abyś mógł zainstalować aplikacje przed innymi.
+ - udostępnimy ją naszym użytkownikom korzystającym z wersji beta - już ponad tysiąc osób korzysta z wersji beta.
+ - wydamy aplikację i uwzględnimy nowy język w ogłoszeniu.
+
+### Tłumaczenie aplikacji iOS
+
+1. Podczas tłumaczenia [aplikacji iOS](https://hosted.weblate.org/projects/simplex-chat/ios/) duża część ciągów jest dokładnie taka sama - można je skopiować jednym kliknięciem w sekcji słowniczka. Wskazówką jest podświetlenie całego ciągu źródłowego na żółto. Wiele innych ciągów jest bardzo do siebie podobnych, różnią się jedynie składnią lub sposobem pogrubienia czcionki - wymagają one minimalnej edycji. Istnieją jednak pewne ciągi które są unikalne dla platformy iOS - należy je przetłumaczyć osobno
+
+2. Przejrzyj tłumaczenia na iOS w taki sam sposób jak na Androida i daj nam znać, kiedy będą gotowe do sprawdzenia - powtórzymy ten sam proces dla aplikacji na iOS.
+
+Serdecznie dziękujemy! To ogromny wysiłek i wielka pomoc dla rozwoju sieci SimpleX.
+
+
+
+## Częste błędy w tłumaczeniu
+
+1. Słowo "chat" jest używane w kilku znaczeniach, w zależności od kontekstu. Może ono oznaczać "aplikację SimpleX Chat" (np. w opcji Rozpocznij/zatrzymaj czat) lub "pojedynczą rozmowę". Jeśli nie jest to jasne, zapytaj się nas, a my dodamy więcej uwag dotyczących tłumaczenia.
+
+2. Prosimy o używanie liczby mnogiej i pojedynczej tak jak w oryginalnych ciągach, w przeciwnym razie może to zmienić ich znaczenie. Przykładowo, niektóre ustawienia mają zastosowanie do wszystkich kontaktów, a niektóre tylko do jednego kontaktu, będzie to mylące dla użytkownika, jeśli użyjesz liczby mnogiej w obu przypadkach.
+
+3. Aplikacja używa "Passcode" do zapewnienia dostępu, a nie "hasła" ("password") - w wielu językach jest to tłumaczone jako "kod dostępu". Baza danych używa "Passphrase" - w wielu językach jest to tłumaczone jako "hasło". Prosimy o spójne używanie tych słów.
+
+4. "Rola" użytkownika. To słowo odnosi się do zestawu uprawnień posiadanych przez użytkownika, może to być "właściciel", "administrator", "członek" lub "obserwator" (najniższe uprawnienie, które pozwala tylko na czytanie wiadomości i dodawanie reakcji na wiadomości). Tłumaczenie tego jako "tożsamość" lub "funkcja" może być nieprawidłowe.
+
+5. "Moderate" / "moderated" ("moderować" / "zmoderowany"). Te słowa oznaczają odpowiednio "usunięcie wiadomości innego użytkownika" i "usunięcie przez administratora". Ta funkcja jest używana, gdy członek wysyła wiadomość, która nie jest odpowiednia dla grupy. Wiele języków ma podobne słowa.
+
+## Jak sprawdzamy tłumaczenia
+
+Aby zweryfikować poprawność tłumaczeń, sprawdzamy tłumaczenia poprzez przeglądanie stron Weblate w przeglądarce Google Chrome w trybie "Tłumacz na angielski". Na przykład, aby sprawdzić niemieckie tłumaczenia interfejsu Androida, ktoś z naszego zespołu przewinął [te 68 stron] (https://hosted.weblate.org/browse/simplex-chat/android/de/).
+
+Nie oczekujemy, że odwrócone tłumaczenie będzie dokładnie takie samo jak oryginał, rzadko się to zdarza, ale że będzie ogólnie poprawne.
+
+Znacznie ułatwiłoby to recenzję, gdybyś mógł wcześniej sprawdzić to w ten sam sposób i skomentować wszystkie przypadki, w których odwrócone tłumaczenia są zupełnie inne (mogą istnieć uzasadnione przypadki).
+
+## Co dalej
+
+1. W miarę aktualizowania aplikacji będziemy publikować aktualizacje w grupie tłumaczy. Nie masz absolutnie żadnego obowiązku tłumaczenia tych dodatkowych ciągów. Niemniej jednak bardzo docenimy, jeśli to zrobisz, ponieważ sprawia to, że użytkownicy mają o wiele lepsze wrażenia, gdy polegają na Twoich tłumaczeniach, niż gdyby jakaś nowa część aplikacji nie została przetłumaczona.
+
+2. Możesz jeszcze bardziej pomóc w popularyzacji SimpleX w swoim kraju / grupie językowej, tłumacząc [naszą stronę internetową](https://simplex.chat) (również [przez weblate](https://hosted.weblate.org/projects/simplex-chat/website/)) i/lub [dokumenty GitHub](https://github.com/simplex-chat/simplex-chat/tree/master/docs/lang) (jest to możliwe tylko przez git)!
+
+3. Ponadto, jeśli chcesz być moderatorem / administratorem grupy użytkowników w swoim języku, po przetłumaczeniu aplikacji możemy hostować taką grupę - przygotowujemy wytyczne dla społeczności i dodajemy kilka narzędzi moderacyjnych do aplikacji, która zostanie wydana w wersji 4.6 w marcu.
+
+
+Jeszcze raz bardzo dziękujemy za pomoc w rozwoju SimpleX Chat!
+
+Evgeny, założyciel SimpleX Chat.
diff --git a/docs/lang/pl/WEBRTC.md b/docs/lang/pl/WEBRTC.md
new file mode 100644
index 0000000000..d279491fb8
--- /dev/null
+++ b/docs/lang/pl/WEBRTC.md
@@ -0,0 +1,158 @@
+---
+title: Korzystanie z niestandardowych serwerów WebRTC ICE w SimpleX Chat
+revision: 31.01.2023
+---
+
+| Updated 31.01.2023 | Języki: PL, [EN](/docs/WEBRTC.md), [FR](/docs/lang/fr/WEBRTC.md), [CZ](/docs/lang/cs/WEBRTC.md) |
+
+# Korzystanie z niestandardowych serwerów WebRTC ICE w SimpleX Chat
+
+## Instalacja serwera STUN/TURN
+
+W tym poradniku będziemy używać najbardziej funkcjonalnej i przetestowanej w boju implementacji serwera STUN/TURN - [`coturn`](https://github.com/coturn/coturn) i [Ubuntu 20.04 LTS`](https://ubuntu.com/download/server) dystrybucji Linuksa.
+
+0. Uzyskaj certyfikaty `stun.$TWOJA_DOMENA` i `turn.$TWOJA_DOMENA`.
+
+ Używamy [Let's Encrypt](https://letsencrypt.org/getting-started/).
+
+1. Zainstaluj pakiet `coturn` z głównego repozytorium.
+
+```sh
+apt update && apt install coturn`
+```
+
+2. Odkomentuj `TURNSERVER_ENABLED=1` z `/etc/default/coturn`:
+
+```sh
+sed -i '/TURN/s/^#//g' /etc/default/coturn
+```
+
+3. Skonfiguruj `coturn` w `/etc/turnserver.conf`:
+
+ Zobacz również komentarze dotyczące poszczególnych opcji.
+
+```sh
+# Nasłuchuj również na porcie 443 dla tls
+alt-tls-listening-port=443
+# Używaj odcisków palców w komunikatach TURN
+fingerprint
+# Użyj mechanizmu poświadczeń długoterminowych
+lt-cred-mech
+# Twoje poświadczenia
+user=$YOUR_LOGIN:$YOUR_PASSWORD
+# Domena Twojego serwera
+server-name=$YOUR_DOMAIN
+# Domyślny obszar, który ma być używany dla użytkowników, gdy nie znaleziono wyraźnej relacji pochodzenie/obszar
+realm=$YOUR_DOMAIN
+# Ścieżka do Twoich certyfikatów. Upewnij się, że są one czytelne dla użytkownika/grupy procesu cotun.
+cert=/var/lib/turn/cert.pem
+pkey=/var/lib/turn/key.pem
+# Użyj predefiniowanego klucza DH TLS o długości 2066 bitów
+dh2066
+# Logowanie do journalctl
+syslog
+# Użytkownik/grupa, która będzie uruchamiać usługę coturn
+proc-user=turnserver
+proc-group=turnserver
+# Wyłącz słabe szyfrowanie
+no-tlsv1
+no-tlsv1_1
+no-tlsv1_2
+```
+
+4. Uruchom i włącz serwis `coturn`:
+
+```sh
+systemctl enable coturn && systemctl start coturn
+```
+
+5. Opcjonalnie, jeśli używasz firewalla `ufw`, otwórz odpowiednie porty:
+
+- **3478** – "czysty" TURN/STUN;
+- **5349** – TURN/STUN over TLS;
+- **443** – TURN/STUN over TLS, który może omijać firewalle;
+- **49152:65535** – zakres portów, który Coturn będzie domyślnie wykorzystywał dla przekaźnika TURN.
+
+```sh
+# Dla Ubuntu
+sudo ufw allow 3478 && \
+sudo ufw allow 443 && \
+sudo ufw allow 5349 && \
+sudo ufw allow 49152:65535/tcp && \
+sudo ufw allow 49152:65535/udp
+
+# Dla Fedory
+sudo firewall-cmd --permanent --add-port=443/tcp && \
+sudo firewall-cmd --permanent --add-port=443/udp && \
+sudo firewall-cmd --permanent --add-port=5349/tcp && \
+sudo firewall-cmd --permanent --add-port=5349/udp && \
+sudo firewall-cmd --permanent --add-port=49152:65535/tcp && \
+sudo firewall-cmd --permanent --add-port=49152:65535/udp && \
+sudo firewall-cmd --reload
+```
+
+## Konfiguracja aplikacji mobilnych
+
+Aby skonfigurować aplikację mobilną do korzystania z serwera:
+
+1. Otwórz `Ustawienia / Sieć i serwery / Serwery WebRTC ICE` i przełącz przełącznik `Konfiguruj serwery ICE`.
+
+2. Wprowadź wszystkie adresy serwerów w polu, po jednym na linię, na przykład jeśli serwery znajdują się na porcie 5349:
+
+```
+stun:stun.example.com:5349
+turn:username:password@turn.example.com:5349
+```
+
+To tyle - teraz możesz wykonywać połączenia audio i wideo za pośrednictwem własnego serwera, bez udostępniania jakichkolwiek danych naszym serwerom (poza wymianą kluczy z kontaktem w szyfrowanych wiadomościach E2E).
+
+## Rozwiązywanie problemów
+
+- **Określ czy Twój serwer jest dostępny**:
+
+ Uruchom to polecenie w terminalu:
+
+ ```sh
+ ping
+
+ - `STUN: stun:
+
+ 4. W sekcji **Results** powinieneś zobaczyć coś takiego:
+
+
+
+ Jeśli wyniki pokazują `srflx` i `relay`, wszystko jest skonfigurowane poprawnie!
+
diff --git a/docs/rfcs/2024-04-01-super-peers-2.md b/docs/rfcs/2024-04-01-super-peers-2.md
new file mode 100644
index 0000000000..1ebd72bc41
--- /dev/null
+++ b/docs/rfcs/2024-04-01-super-peers-2.md
@@ -0,0 +1,262 @@
+# Large public grups / channels
+
+This document describes specific design elements for the MVP of [the groups based on super-peers](./2024-03-14-super-peers.md).
+
+## Super-peer members
+
+There are two possible design approaches for super-peer members:
+
+1. Separate non-participating members that can only be added as a super-peers and do not have their own roles in the group, can't send their own messages or administer the group.
+
+2. Super-peer being a function of any member, irrespective of their role.
+
+While approach 1 can be simpler, it has its downsides:
+- more complex migration of the existing groups - e.g., directory service cannot become a super-peer while remaining group admin (or moderator, if we add a new role).
+- less usable clients - users can have desktop clients with good internet connectivity and sufficient computing resources to effectively host several medium size groups, even with SQLite database.
+- it makes super-peers more like servers, being both unusable as clients and also requiring larger concurrency, and therefore increasing centralization.
+
+Therefore, the approach 2 looks more attractive, when super-peers must have some role in the group, and the super peers that cannot send messages will have observer role.
+
+As a side note, it also implies that it is beneficial to see the permission to moderate messages not as a role somewhere between Member and Admin, but as a separate privilege that admins and owners have by default for the messages from the members up to their role, but in general it's a separate member profile setting that allows to moderate messages up to a certain role. That approach would help automatic moderation as well, when moderators may be allowed to moderate messages of admins, without being able to remove members.
+
+Proposed protocol modifications:
+
+```haskell
+-- this type is used in XGrpMemNew, XGrpMemIntro and XGrpMemFwd for member introductions
+data MemberInfo = MemberInfo
+ { memberId :: MemberId,
+ memberRole :: GroupMemberRole,
+ rank :: Maybe Word8, -- new field, 0 for usual members, 1 for super-peers, allows to build additional distribution hierarhies if needed.
+ perms :: Maybe MemberPermissions, -- new field
+ v :: Maybe ChatVersionRange,
+ profile :: Profile
+ }
+
+-- this type is used in XGrpInv (in GroupInvitation) and XGrpLinkInv (in GroupLinkInvitation)
+-- to invite members to the group
+data MemberIdRole = MemberIdRole
+ { memberId :: MemberId,
+ memberRole :: GroupMemberRole,
+ rank :: Maybe Word8, -- new field
+ perms :: Maybe MemberPermissions -- new field
+ }
+
+-- new type
+data MemberPermissions = MemberPermissions
+ { moderate :: MemberPermissionTarget -- could be extended to array in the future
+ }
+
+-- new type
+data MemberPermissionTarget = MemberPermissionTarget
+ { maxRole :: Maybe GroupMemberRole -- if absent, can moderate all messages
+ }
+```
+
+For backwards compatibility, `admin` role implies `{moderate: {maxRole: admin}}` permission and `owner` - `{moderate: {maxRole: owner}}`, which probably can be overridden with `{moderate: {maxRole: observer}}`.
+
+It is also proposed to migrate `memberId` and `memberRole` to `id` and `role` in the parser (in a forward/backward compatible way), without changing serializers.
+
+## Group routing mode
+
+Irrespective of the presense of super peers in the group, the group itself has to be switched to super-peers routing at some point via a group profile update.
+
+```haskell
+data GroupProfile = GroupProfile
+ { displayName :: GroupName,
+ fullName :: Text,
+ description :: Maybe Text,
+ image :: Maybe ImageData,
+ groupPreferences :: Maybe GroupPreferences,
+ rank :: Maybe Int, -- new field, 0 for flat groups, 1 for groups with super peers
+ redundancy :: Maybe GroupRedundancy, -- new field, only used when rank > 0
+ consensus :: Maybe GroupConsensus -- new field, see below in
+ }
+
+-- each field defines an average number of super-peers that will deliver messages (events) related to a specific scope,
+-- by default all super peers will deliver the events in that scope.
+data GroupRedundancy = GroupRedundancy
+ { messages :: Maybe Double, -- messages and message changes, including reactions and comments
+ members :: Maybe Double, -- member additions and permission changes
+ group :: Maybe Double -- group profile and other changes
+ }
+```
+
+## Decisions about message or another event delivery
+
+In groups with rank 0 (current groups) all members aim to establish connections with all other members, making it hard to scale. Admins who added the members play a temporary role of forwarding messages, but only until members are connected.
+
+In groups with rank 1 super-peers connect to all members, but each message or event may be delivered by some rather than by all super-peers, to avoid substantial traffic increase. E.g., in groups with 2 super-peers it would be desirable to deliver each message 1.33 (4/3) times on average, while for groups with 3 super peers it can be 2 or 1.667 (5/3) times.
+
+The decision whether a given super peer should deliver the message would depend on these factors:
+- deterministic (see below) message hash, `h`.
+- receiving member ID, `r`.
+- super-peer member ID, `s`.
+- target message redundancy `d` (the desired number of super-peers to deliver the message).
+- number of super-peers connected to member `r` (and known as connected to super-peer making the decision), `n`.
+- 0-based index of the current super-peer in the sorted array of known super peer IDs, `i`. It does not require sorting all peer IDs, it's enough to count how many peers have smaller or larger IDs.
+
+The assumption here is that member ID is unique within the group, and that message hashes are also unique. Also, message hashes rather than sending member IDs are used to ensure that the decision is made differently for the same sender/recipient pairs, allowing recipients to identify integrity violations (e.g., if some of the super-peers decides to change the messages or fail to deliver it).
+
+For simplicity, all parameters are normalized to 0..1 range from their respective binary ranges.
+
+The algorithm to decide whether the message should be delivered by a given super-peer:
+
+```
+if (d >= n || n == 1) deliver;
+else
+ prob = d/n ; delivery probability based on target delivery redundancy
+ point = (h + r)/2 ; as member ID and message hash are uniformly random in 0..1 range, `point` will also be uniformly random in 0..1 range
+ start = (1 - prob) * i / (n - 1) ; `start` for the peer with `i == 0` will be `0` and with `i == n - 1` will be `1 - prob`
+ end = start + prob ; `end` for peer 0 will be `prob` and for peer `n - 1` will be 1
+ ; for all peers the range `start..end` will have width `prob`
+ if (point >= start && point < end) deliver
+ else skip;
+```
+
+This algorithm can be proven to result in target average delivery redundancy.
+
+It also requires all super peers to inform other super peers about:
+- establishing or losing the connection with other members (e.g., when AUTH is received).
+- informing about their decision to stop being super peers in advance.
+- most likely using delivery receipts in communications between super-peers that would include message hashes in RCVD info.
+
+## Authorising administrative changes
+
+As members no longer send messages directly to other members, in addition to the risk of the initial MITM by admin (which is now mitigated by having multiple super-peers) there is a risk of super-peers being compromised at a later stage, and in case of administrative changes (member or group level changes) we have these options:
+
+1. have all members postpone these changes until they are communicated by a sufficient number of super-peers (that would require configuring consensus on the group level).
+2. have admins and owners sign administrative changes with the public key included in their profile during member introduction.
+
+The downside of approach 1 is that administrative actions will be delayed and have to be executed not at the time the message is delivered, but at the time message is confirmed by other super-peers. That is separate and in addition to member consensus for some changes (see below). That also means that groups with one super-peer will have no defence mechanism against super-peer being compromised. That also means that groups with two super-peers will either also have no such defence (in case required consensus level is 1) or will require that both super-peers are available, and no administrative actions will be executed unless both super-peers are available.
+
+The downside of approach 2 is the lack of repudiation, in fact, there is a non-repudiation quality of such administrative changes as role changes, member additions and deletions, and group changes.
+
+Overall, while repudiation of sent messages appears as important, it seems much less important for administrative changes, and signing member and group changes while relying on Merkle DAG for message history integrity appears to be an optimal tradeoff.
+
+To support this functionality the `admin` and `owner` members have to add public keys to their profiles and communicate profile updates to all members (before or after group is switched to super-peers, but probably before is better).
+
+The middle ground here is moderation, and trade-off here is more nuanced. Practically, whether message is fully removed or marked as removed is the group policy decision, and it can be made based on whether it's more important to preserve content or to remove undesirable content without trace, and also given that super-peers are likely to be give automatic moderation capabilities anyway, preserving deniability for moderation events and relying on Merkle DAG to identify integrity violation seems a better alternative than signing moderation messages. Although it can also be a part of group policy whether to require signing moderation events.
+
+The change to member profile will be:
+
+```haskell
+data Profile = Profile
+ { displayName :: ContactName,
+ fullName :: Text,
+ image :: Maybe ImageData,
+ contactLink :: Maybe ConnReqContact,
+ preferences :: Maybe Preferences,
+ authKey :: Maybe AuthKey -- new field
+ }
+
+-- this is rather ad hoc and tries to allow two things:
+-- - verify that the member has the private key.
+-- - allow key rotations on profile changes, without signing the whole profile change.
+-- A better option could be to use certificates, although they are much large in size,
+-- and also to simply sign profile changes that include key change (then prevKeySignature won't be needed)
+data AuthKey = AuthKey
+ { key :: PublicKeyEd25519,
+ signature :: SignatureEd25519, -- signature of the key itself
+ prevKeySignature :: Maybe SignatureEd25519
+ }
+```
+
+## Role, rank and moderation permission changes of members and group profile changes
+
+There are two problems with the current approach to changing permission, when a single member makes this decision:
+- member whose role changes may disagree. E.g., the member may not be willing to have owner or admin role in some groups. Even more so, the member may be unable to perform super-peer functions (have rank 1).
+- other owners or admins may disagree with the change or it may have been made by mistake.
+
+With the move to super-peers it is additionally complicated by the fact that super-peers will be forwarding these messages, and they could be compromised, thus disrupting group functioning - this risk currently exists with the existing group directory that plays admin role and in case it is compromised it can remove all members from the group.
+
+Part of this problem is addressed in the previous point by requiring to sign administrative changes.
+
+Another part is about the members agreeing to changes that affect them when additional privileges are granted, and also by requiring the consensus between group owners and admins for any privilege changes.
+
+There are 2 options for proposals/acceptance/approvals flow design:
+1. introduce additional protocol messages for each stage, and for each type of change to complement existing messages.
+2. manage these stages in orthogonal way, by adding these stages on the top level of the protocol.
+
+The option 2 is likely to result in a more concise protocol as it will separate approval from from the events, also allowing to include authorizations in a standardized way. This also fits well in `XGrpMsgForward` event that includes that message inside, so all authorizations will be forwarded.
+
+```haskell
+-- fields are the number of member approvals required for actions with that role.
+-- As target member acceptance is required only for privilege increases it won't be among approvals required for consensus.
+-- For example, for group with consensus = {admin: 3, owners: 2}, a new member can be made admin with the decision of 3 other admins or with the decision of single owner (as owner role is higher), or the group can be removed, a new admin is added or group consensus changed with the decision of 2 admins.
+-- Owners leaving without changing the consensus can result in consensus becoming unreachable - this is not different from losing a single member, and it only prevents accidental or malicious destructive actions, but does not prevent losing access.
+data GroupConsensus = GroupConsensus
+ { admin :: Maybe Word16, -- possibly, this field is not needed
+ owner :: Maybe Word16 -- 1 by default
+ }
+
+-- alternatively, the type could be more flexible than that, but it can be extended if needed.
+
+data ChatMessage e = ChatMessage
+ { chatVRange :: VersionRangeChat,
+ msgId :: Maybe SharedMsgId,
+ chatMsgEvent :: ChatMsgEvent e,
+ stage :: Maybe MessageStage, -- new field, Nothing for broadcasted messages
+ bcast :: Maybe MessageBroadcast, -- new field instructing super-peers how to broadcast the message
+ auth :: Maybe (Either MemberApproval [MemberApproval]) -- approvals for broadcasted messages from members, Either won't be in encoding
+ }
+
+data MessageStage = MSProposed | MSApproved
+
+-- possibly, this could include approval stage but it is implied by the context, message needs to be approved by:
+-- - the sender with the sufficient permissions
+-- - the target of the change when privileges are granted
+-- - other admins or owners as required by `consensus` property in group profile.
+data MemberApproval = MemberApproval
+ { memberId :: MemberId, -- can be encoded as id?
+ auth :: SignatureEd25519
+ }
+
+data MessageBroadcast = MessageBroadcast
+ { from :: Maybe MessageFrom, -- MFSender by default
+ auth :: Maybe Bool, -- whether to keep auth if present, True by default, False means to validate and remove auth
+ schedule :: Maybe MessageSchedule
+ }
+
+data MessageFrom = MFSender | MFApprovers
+
+data MessageSchedule = MessageSchedule
+ { deliverAt :: Maybe UTCTime, -- when received by super-peer by default
+ minDelay :: Maybe Int, -- seconds, added to start, 0 by default
+ maxDelay :: Maybe Int -- seconds, added to start, 0 by default
+ }
+
+-- e.g., to deliver at least 2 hours after received by super-peer, the MessageSchedule would be {minDelay :: 7200}
+-- or, to deliver all messages 20-40 seconds after it is received, to complicate traffic correlation it would be {minDelay: 20, maxDelay: 40}
+-- or, to deliver at a scheduled time {deliverAt: "2024-04-01T00:00:00Z"}
+```
+
+The signature is computed over deterministic message hash excluding `auth` property. This structure would also allow asking super-peers to forward the message as originating from multiple owners or admins without showing who originated the message, as long as necessary approvals are present.
+
+That will require extending `XGrpMsgForward` to support array of MemberId and allow UI to show multiple senders of the message:
+
+```haskell
+ | XGrpMsgForward :: [MemberId] -> ChatMessage 'Json -> UTCTime -> ChatMsgEvent 'Json
+```
+
+The messages send from multiple owners can have the benefit of avoiding targeted attacks on the member who originated it - it will only be known to other members sending the message, but not to other members, creating mutual responsibility for some changes and/or announcements.
+
+## Choosing MVP scope
+
+With all these ideas for improvements, the challenge is to choose some valuable MVP shippable in the shortest time.
+
+From the UX point of view, the most lacking parts are:
+
+- broadcasting messages via super-peers, including:
+ - protocol to accept and approve role changes is necessary, as it should not be possible to unilaterally appoint some member to be a super-peer.
+ - computing deterministic message hashes and signatures (and only member with the key in profile can be made super-peer).
+ - protocol to communicate connections with members between super-peers, yet TBD.
+ - algorithm to make decision whether to deliver message.
+- an equivalent of Telegram channels - groups where members can only send comments and set reactions, but cannot send messages. Protocol extensions yet TBD.
+
+Optionally, we could include:
+- Merkle tree integrity validation.
+- Owners/admins consensus.
+- Messages from multiple members (don't have to be owners, can be any members, irrespective of the need for consensus).
+- Delayed messages.
+
+None of this optional list is required to launch.
diff --git a/docs/rfcs/2024-04-16-ip-address-protection.md b/docs/rfcs/2024-04-16-ip-address-protection.md
new file mode 100644
index 0000000000..0019ad87ca
--- /dev/null
+++ b/docs/rfcs/2024-04-16-ip-address-protection.md
@@ -0,0 +1,81 @@
+# IP address protection, support for SMP sending proxies
+
+## Problem
+
+IP addresses of senders being visible to recipients' chosen servers, which in case of self-hosting makes it visible to recipients themselves. In case of XFTP files the issue is reversed, with IP addresses of recipients being visible to senders' chosen servers.
+
+## Solution
+
+### SMP
+
+- Agent to support sending proxies
+- New network settings configuration "Use SMP proxies"
+ - Can be set to "always", "never", "for unknown servers"
+ - Currently configured servers to be considered as "known", including those disabled for new connections
+ - Initial default is "never" to allow opt-in for testing, to be changed to "for unknown servers" later
+ - Support in UI
+- No alerts about unknown servers are required in UI
+- Tor setting to not affect agent decision to use SMP proxy for each given server
+
+``` haskell
+data UseSMPProxies
+ = SMPPAlways
+ | SMPPNever
+ | SMPPUnknown
+ deriving (Eq, Show)
+
+data NetworkConfig = NetworkConfig
+ { ...
+ useSMPProxies :: UseSMPProxies,
+ ...
+ }
+```
+
+### XFTP
+
+Some considerations:
+
+- XFTP proxying is not planned to be implemented initially
+ - In future it could be done via open socket and with no persistance, and would be required only for FGET command
+- Currently XFTP files are automatically set for reception in some cases:
+ - Images and voice messages
+ - In background (via "set to receive")
+- Agent resumes file reception (download) after app re-start, in case they weren't fully downloaded
+- User may change tor setting between and during app sessions, so a file can be "accepted" when app is connected via tor, but resumed when it's no longer
+
+Solution:
+
+- Client would make a decision whether to automatically accept file, or alert user about unknown servers
+- Add only_via_tor flag to agent rcv_files + pass through APIs:
+ - add Bool to `ReceiveFile` (with False meaning user hasn't indicated any intent regarding unknown servers)
+ - can either be automatically accepted, or require alerting user and asking for confirmation (see below)
+ - add `onlyViaTor` to `xftpReceiveFile`
+- Possible scenarios:
+ 1. XFTP file chunks are fully available on known servers
+ - Do not show alert, accept automatically (images, voice messages) or without approval (other files)
+ - `onlyViaTor` is False
+ 2. Some file chunks are on unknown servers, tor is not enabled
+ - User accepts manually, show alert to user
+ - User confirms, indicating it's Ok to proceed even though IP would be visible to unknown servers
+ - `onlyViaTor` is False
+ - \* Additional user preference to never ask? -> behavior same as now
+ 3. Some file chunks are on unknown servers, tor is enabled
+ - Do not show alert, accept automatically (images, voice messages) or without approval (other files)
+ - `onlyViaTor` is True
+- On file download:
+ - `onlyViaTor` equal False is ignored
+ - If `onlyViaTor` is True, and tor is not enabled, throw new "permanent" error
+ - Permanent for simplicity as this is an edge case
+ - File record to be removed from agent
+ - Could analyze whether it's remaining (not yet downloaded) chunks are on unknown servers, and only abort in this case (and instead proceed if remaining chunks are on known servers)
+ - This requires changing download to load data for all chunks instead of loading only current chunk
+ - This is another edge case of edge case, as it seems more likely that sender either used only self-hosted servers, or only preset servers
+ - So it seems as unnecessary complication, and it should be Ok to abort simply based on only_via_tor flag + tor setting
+ - Error is RFERR XFTP UNKNOWN_NO_PROXY (new constructor)
+- Chat to differentiate RFERR, and make file available for re-download on UNKNOWN_NO_PROXY error, similar to when file is cancelled
+ - New CIFileStatus - CIFSRcvCancelledNoProxy, to differentiate in UI
+ - Different icon for retry, alert explaining why file was aborted
+
+### Trusted servers
+
+We also considered an idea of trusted servers, but it proved to have unnecessarily complex UX, and in case of XFTP had issues on file download continuation after restart (e.g. server "trusted" flag changing, automatically accepting with tor enabled). It requires additional consideration and may be better suited to concept of "server providers".
diff --git a/package.yaml b/package.yaml
index 3e187c5653..e844c52c26 100644
--- a/package.yaml
+++ b/package.yaml
@@ -1,5 +1,5 @@
name: simplex-chat
-version: 5.6.1.1
+version: 5.7.0.0
#synopsis:
#description:
homepage: https://github.com/simplex-chat/simplex-chat#readme
diff --git a/packages/simplex-chat-webrtc/src/call.ts b/packages/simplex-chat-webrtc/src/call.ts
index accbebb22d..e7788ac723 100644
--- a/packages/simplex-chat-webrtc/src/call.ts
+++ b/packages/simplex-chat-webrtc/src/call.ts
@@ -245,9 +245,10 @@ const processCommand = (function () {
}
const defaultIceServers: RTCIceServer[] = [
+ {urls: ["stuns:stun.simplex.im:443"]},
{urls: ["stun:stun.simplex.im:443"]},
- {urls: ["turn:turn.simplex.im:443?transport=udp"], username: "private", credential: "yleob6AVkiNI87hpR94Z"},
- {urls: ["turn:turn.simplex.im:443?transport=tcp"], username: "private", credential: "yleob6AVkiNI87hpR94Z"},
+ //{urls: ["turns:turn.simplex.im:443?transport=udp"], username: "private2", credential: "Hxuq2QxUjnhj96Zq2r4HjqHRj"},
+ {urls: ["turns:turn.simplex.im:443?transport=tcp"], username: "private2", credential: "Hxuq2QxUjnhj96Zq2r4HjqHRj"},
]
function getCallConfig(encodedInsertableStreams: boolean, iceServers?: RTCIceServer[], relay?: boolean): CallConfig {
@@ -320,7 +321,17 @@ const processCommand = (function () {
}
async function initializeCall(config: CallConfig, mediaType: CallMediaType, aesKey?: string): PromiseTransitioning from a lifelong career dedicated to nonprofits, +including Board roles at organizations like the Wikimedia Foundation, Access Now and Tor, +my decision to join SimpleX Chat may come as a surprise to some. +But, as I step into this new chapter, I want to share the insights and convictions +that have guided me here, shedding light on what I think sets SimpleX Chat apart +and why this move feels like an essential learning opportunity.
diff --git a/website/src/_includes/blog_previews/20240416.html b/website/src/_includes/blog_previews/20240416.html new file mode 100644 index 0000000000..6c6edfb6c1 --- /dev/null +++ b/website/src/_includes/blog_previews/20240416.html @@ -0,0 +1,5 @@ +By Esra'a al Shafei + +It's important not to be complacent with the current standards of messaging, + where metadata aggregation is still normalized in apps falsely and dangerously marketed as "private". + This is a post exploring the fundamental differences between privacy and security.
\ No newline at end of file diff --git a/website/src/call/call.js b/website/src/call/call.js index b247431f4b..8104470686 100644 --- a/website/src/call/call.js +++ b/website/src/call/call.js @@ -24,8 +24,9 @@ var TransformOperation; let activeCall; const processCommand = (function () { const defaultIceServers = [ + { urls: ["stuns:stun.simplex.im:443"] }, { urls: ["stun:stun.simplex.im:443"] }, - { urls: ["turn:turn.simplex.im:443"], username: "private", credential: "yleob6AVkiNI87hpR94Z" }, + { urls: ["turns:turn.simplex.im:443"], username: "private2", credential: "Hxuq2QxUjnhj96Zq2r4HjqHRj" }, ]; function getCallConfig(encodedInsertableStreams, iceServers, relay) { return {