Suggestions on Nostr's "censorship-resistance"

[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！

[staab]

1/2. Nothing's stopping you from doing it, but it won't be widely supported. Onion urls are another example, and don't tend to work well. Alternative transport protocols should probably be supported outside of the protocol, or via a new NIP.
3. Matrix's protocol is probably not the best option, but there's been talk about using MLS, OMEMO, etc. It just takes someone to specify and build a reference implementation.
4. I don't personally know much about IPFS, but the consensus seems to be that it isn't a good fit for high-reliability, low-latency file discoverability. Various solutions are being worked on, including NIP 95 and blossom. I think blossom is promising, but lots of work to do in this area.
5. Nostr doesn't use WebRTC. IP obfuscation can be done using VPNs.

[redian11]

1/2 I understand what you mean, but there is a situation that you may not have thought of: when the entire country's external network ports are blocked from overseas connections for a certain period, and VPNs and onion networks are physically isolated, how can a group of people form a verifed network and communicate together?I don't like to talk about politics or hot topics, but blockdown do happen before for short period.Frankly I'm just a user and don't have good programming skills. It would be great if someone can implement it, maybe a new nip will be formed later to implement it.
According to my daily observation, Bt can connect and share download files within a country. I don’t know how they achieved.
5.It better not.When using vpn,webrtc can still expose where the real ip is.

[mikedilger]

Nostr unfortunately doesn't separate the content protocol (events, requests, etc) from the transport. I wish it did, and we had multiple underlying transports. Then nostr events could be transmitted via obfuscated transports like you mention. Right now it is only WebSockets and people who suggested making an alternate REST based transport were shot down. This was for simplicity, and making sure devs didn't have to implement every possibility... but in the case of transport I don't think adding new transports requires devs to do yet another thing, so I don't know why multiple transports are not a thing.

[kellybell]

• Real Talk: this means nostr isn't going to maybe be the best method to use to "tweet* the (next) revolution" if you're doing it from a stationary and unsecured IP address, which is unfortunate, tbh. That spontaneous activist utility ("Arab Spring", Black Lives Matter protests, etc) really was one of the biggest benefits to humanity that Twitter, unforeseen by the founders, and it's what made Twitter RELEVANT far beyond the usual. One would hope nostr's founders would be sensitive to the need for location privacy as a "critical path" feature.

On the other hand, Twitter didn't have this feature, nor does X, so... Personally I'm just grateful nostr exists and folx have taken the time to come up with an open source solution to our problem that actually works. Thanks everyone.

As for sensitive documents and image transfer, I guess Signal will (still) have to do.

*for lack of a better word