@sammacbeth had the following tip:

I found that discovery-swarm-webrtc (with a turn server) works better for difficult networks, and as a bonus it can use ipv6.

if we want to go down this TURN-server approach, since it seems implausible that regular clients with unconfigured firewalls and random NATs will be holepunchable in a significant amount of cases, (and cjdns sadly does not magically solve this problem either) maybe the following approach could work:

long-lived cabal peers become TURN servers, and they broadcast their existence on a predefined hyperswarm topic. newly started clients (with internet) that cannot connect (or: have not historically connected) to anyone on a given cabal key within <timeout> proceed to query the hyperswarm TURN topic to find a TURN-server. since the TURN server does not know the cabal key, the contents that are being ferried through it are not readable by it.

for peers to deterministically end up at the same TURN server, the cabal key is used, somehow.

so, the long-lived super peers (i.e. peers which others can connect to) of one cabal help peers of cabals without super peers by ferrying encrypted traffic for them (i.e. becoming TURN servers, but maybe another technique is possible using the same idea)

peers should be able to turn off the automatic usage of TURN-after-timeout.