Some suggestions on"censorship-resistance" function

[redian11]

Are any of these points already implemented or currently being worked on? If they are new points, then these can be considered as suggestions. These suggestions are all centered around being censorship-resistant. Hope Nostr developers can provide tell me some info. Thank you!

1. The step of adding a relay in Nostr ought to support both plaintext servers (wss://example.com) and string formats like magnet:?xt=urn:btih:W4FUYVUCU.

2. Relays can accept various protocols and obfuscation. The client can initiate communication with the relay, disguising it as BitTorrent, a normal HTTPS connection, or raw Nostr.

Note:
The internet infrastructure relies on public DNS, which is generally trustworthy in most network situations, with at most some annoying Ads insertions. However, in certain regions with network control with DPI inspection, censorship, and blocking (like the GFW, Great Firewall of China), and even global DNS pollution. DNS and SNI queries are in plaintext, and DoH would be blocked in such here. My suggestion is that Nostr should have its own "domain name system" as a backup when the public DNS is blocked or untrusted. The domain names and access addresses should be encrypted in RAM (to prevent censors from extracting addresses from storage; this RAM encryption technique is commonly used in commercial product key activation) and gradually supported by nostr clients. When querying the public DNS becomes untrustworthy or blocked, this Nostr domain name system can be enabled as backup. It would then provide domain names and IP addresses to query the relay addresses, allowing connection to the relays. Multiple sites could "verify" each other at this point. If the Nostr domain name system's specific domain names are still "inaccessible," then IP access can be used, similar to BitTorrent. Of course, when connecting to the server, key and certificate verification is necessary to ensure trust, as the country's public DNS could potentially redirect to a phishing honeypot server. Nostr clients and servers should have some trusted site certificates built-in and often updated, especially when outside the censored region. The Nostr community should guide developers to gradually implement support for things above.Additionally, local static files and in-memory dynamic storage encryption should be supported (aiming for censor-resistance and preventing analysis, like commercial product key activation in RAM).

I hope the "Nostr domain name system" can operate independently, so that in the worst-case scenario, a group of people can only connect and communicate information within the scope of a single country when they cannot connect to websites in Europe, America, or the rest of the world EVEN IF VPN cannot work at times during some periods.

3. Can Nostr use Matrix's Double Ratchet Algorithm and support for ahead encryption?

4. Nostr ought to support IPFS to store and spread files.

5. What measures does Nostr take to avoid WebRTC leaks, especially when "bad guys" want to use it to detect real IPs and ports?

   Any replies are appreciated！ Thanks in advance！

[basantagoswami]

1 - Relays can have .onion addresses instead of domain names or IP addresses. They will be much harder to censor, unless a nation state censors TOR entirely. But we can probably make a more decentralized version of IP too. Fiatjaf has talked about it before. There is also something called cjdns that I found interesting, but the founders of it now seem to be busy peddling in some shitcoin called PKT.

3 - There is a new NIP proposal for better DMs now

4 - There is blossom which will probably be a better alternative to IPFS

5 - Nostr doesn't directly use WebRTC, but for video calls and stuff, we can use it alongside nostr. SimpleX, one of the privacy first messaging apps use WebRTC ICE servers for audio and video calls, so it's not too big of an issue if the ICE server is trustworthy.