Thank you @terrytw , that now is truly interesting !
1 Like
Most Chinese users are behind NAT, which means that once the TURN.jami.net server is blocked, most Chinese users cannot use Jami.
And the GFW can not only block this TURN server, but also the entire TURN protocol to block all overseas TURN servers. Just as they have banned all the overseas proxy servers by blocking the protocols.
Available IPv4 is scarce, and it is difficult for personal use to apply to the ISPs.
When IPv6 becomes popular in a few years, NAT may not be needed.
2 Likes
@CrazyBoyFeng , I think not all services in Jami require TURN, and also (see earlier in this post) I understand that once you “initialized” once your Jami instance, connecting to a neighbor for instance, then you don’t necessarily need TURN. But I must say I didn’t test this…
1 Like
Not all services in Jami require TURN, but as I said, Most Chinese users are behind NAT.
This post and official blog both claim that two users behind NAT need to communicate through TURN.
As much as we like to say that Jami is completely without server, sometimes it is not exactly right as we have seen. However, TURN is the perfect compromise for situations where a fully peer-to-peer connection is not possible
And terrytw also raised the issue.
In my own test, if the two clients behind NAT are set to no TURN, they cannot communicate. However, maybe my test is wrong. Hope to be verified by others.
1 Like
Briar works well via bluetooth and wlan. But when chatting remotely, it connects via tor. Almost all public nodes and bridges of tor are blocked. If there are nodes that are not blocked, it must be because they are too new. So it is often difficult to chat remotely with Briar. It is more suitable for use when crowds gather.
With the popularity of IPv6, software such as jami and tox will become more usable.
3 Likes
Thanks @CrazyBoyFeng -that’s the first time I see a meaningfule argument in favor of IPv6!
Don’t you fear that in the same ‘constrained’ environment, also IPv6 could be just blocked too?
1 Like
Maybe blocking bootstrap.jami.net will cause a little trouble. However, everyone can run their own bootstrap nodes if they have public IP(v6).
In extreme cases, ISPs may also block ports and even protocols, making it impossible for everyone to connect. But I think this is not something Jami should deal with. Software like Jami is not originally used to resist censorship. It only needs to achieve its original design purpose, decentralization, which is enough to do a lot of things.
2 Likes
If ipv6 addresses are randomised will Jami users still be able to connect to each other?
1 Like
The DHT network is used to query the IP of the ID. As long as it is connected to the DHT network and can exchange data between nodes, then there is no need to worry about IP changes.
Unless your node is used as a bootstrap node, others must connect to you before they can connect to the DHT network. If your IP changes and you are not using DDNS, then others will not be able to connect to the DHT network. They either change to another bootstrap node, or need you to tell them the current IP in other ways.
1 Like
I am a Jami user in China and I’ve read some of your replies.
First, maybe because of its feature of ‘no server’, Jami’s network connection is NOT stable in China, just now I sent messages to my classmate, at first he could recieve my message but several minutes later wo lost connection. This makes Jami even impossible to become a widely used communication tool in China, even though Jami has a very attractive feature - end-to-end encryption. I think the troublesome using experience is serious than I use RSA to encrypt my message and send the msg through QQ and the other side received my message and then he copied the message and the RSA-pub key to a program to get the real message.
Second, I think it is predictable that the network ecosystem in China will be more blocked. Chinese goverment and the law doesn’t allow a end-to-end encryped communication tool, in case that some msgs are passed, so QQ, Wechat and other communication tools in China all don’t encrypt msgs end-to-endly. Nowadays even the network connection to Github and Steam is not stable because GFW randomly bans connetions to Github using SNI, Pixiv is globally banned using sni. GFW baned ALL ESNI connetion; and In my opinion Jami will be baned one day.
BTW, I use China Mobile and China Telecom.
I saw all your replies are earlier than 2021 May, and I’d REALLY appreciate it if the developer of the software Jami could see me and give me reply.
1 Like
Jami’s bootstrap server has been blocked by some ISPs in China.
In these places, if you want to use Jami stably, I recommend setting up a bootstrap server and TURN server by yourself. If you need push service for mobile devices, you may need to setup DHT proxy.
The setup solution can be obtained from here: Use Jami on a LAN — Jami documentation
Of course, all of this requires you to have a public IP.
In today’s China, public IPv6 is relatively easy to get. However, if you only have public IPv6, then you will not be able to communicate with clients using IPv4.
1 Like
You can’t query IP by jami ID or query jami ID by DHT node ID. Jami only sends IP ( put(key, data) ) in encrypted form when devices need ICE negotiation, and Jami only accepts ICE request from contacts. You can read the source code of jami-daemon.
for (const auto& addr : ice->getLocalCandidates(1)) {
icemsg << addr << "\n";
JAMI_DBG() << "Added local ICE candidate " << addr;
}
// Prepare connection request as a DHT message
PeerConnectionRequest val;
val.id = vid; /* Random id for the message unicity */
val.ice_msg = icemsg.str();
val.connType = connType;
auto value = std::make_shared<dht::Value>(std::move(val));
value->user_type = "peer_request";
// Send connection request through DHT
JAMI_DBG() << "Request connection to " << deviceId;
dht()->putEncrypted(dht::InfoHash::get(PeerConnectionRequest::key_prefix
+ devicePk->getId().toString()),
devicePk,
value,
[deviceId](bool ok) {
JAMI_DEBUG("Sent connection request to {:s}. Put encrypted {:s}",
deviceId.toString(),
(ok ? "ok" : "failed"));
});
for (const auto& addr : ice.getLocalCandidates(1)) {
icemsg << addr << "\n";
}
// Send PeerConnection response
PeerConnectionRequest val;
val.id = id;
val.ice_msg = icemsg.str();
val.isAnswer = true;
auto value = std::make_shared<dht::Value>(std::move(val));
value->user_type = "peer_request";
JAMI_DBG() << "[CNX] connection accepted, DHT reply to " << from->getLongId();
dht()->putEncrypted(dht::InfoHash::get(PeerConnectionRequest::key_prefix
+ from->getId().toString()),
from,
value,
[from](bool ok) {
JAMI_DEBUG("Answer to connection request from {:s}. Put encrypted {:s}",
from->getLongId().toString(),
(ok ? "ok" : "failed"));
});
How do these ISPs block bootstrap? DNS tampering or IP filtering?
For android client built with UnifiedPush support, you can run your own UnifiedPush instance, then use it with default DHT proxy, or also run DHT proxy.
For iOS client and android client built with FCM support, these two services (APNs and FCM) can’t be self-hosted.
1 Like
If we can create a DHT node simply and quickly, and we can easily send the address to our contacts, and the contacts can easily add the DHT node to their own accounts, then we can easily use JAMI in some of the harshest network environments, I think it is not difficult
-
I’m sorry I haven’t looked into Jami’s code. Since it uses DHT network, I thought it is like BT to find the IP of the communication object through DHT network and then do P2P communication.
So, Jami is not P2P communication. Messages are passed through random intermediate nodes, right? -
In my travels, I found that Shaanxi CMCC and Shandong CMCC could not resolve
bootstrap.jami.netto IP, while Tibet Telecom and Jilin Telecom might have implemented IP filtering. But it could also be due to poor connection quality. Fujian coastal cities have implemented a whitelisting system, which only allows communication with a few foreign IPs. I don’t know much about the other ISPs.
Of course, we may need to use some third-party software for this process, but I don’t think this has much impact on security.
- Some messages are sent via DHT (e.g. conversation request, ICE messages). Messages in swarm (includes one-to-one swarm) are sent via peer-to-peer connection.
- Thank you.
Encrypted DNS and DNS using a non-standard port may help.
You can get more information from logs.
Today swarm and SIP channel need TCP connection, and some users in China can’t use default TURN server, so you need to check everything can break peer-to-peer connectivity… e.g. router which is provided by ISP (may contain a IPv6 firewall can’t be controlled)
2 Likes
You could build a public municipal wireless network using Super WiFi, HaLow or LPWAN radio technologies and extend the range through peer-based mesh protocols… 
HolePunch technology is faster and more reliable than STUN/TURN servers – it is more secure, reduces latency and risk of data loss.
Personal P2P chat relay on Raspberry Pi
“Holepunch building blocks for you to build your own powerful P2P apps…”
Hypercore = P2P Data Streams
Hyperdrive = P2P File System
Hyperbee = P2P Database
Autobase = P2P Collaboration
Here are some of the things you could build as a hobby or business with Holepunch…
1 Like
If we can create a DHT node simply and quickly, and we can easily send the address to our contacts, and the contacts can easily add the DHT node to their own accounts, then we can easily use JAMI in some of the harshest network environments, I think it is not difficult.
1 Like