So nobody should have done anything and we collectively should have just let Turkey censor Wikipedia with zero alternatives, that's the better solution here?
"Ignore the plight of a few websites now, to protect millions of websites in five years," is sorta-kinda the point everyone is making. You have to let Luke Skywalker get old enough to actually have a chance of defeating Darth Vader before giving him a lightsaber and letting him hare off across the galaxy; otherwise you just get a dead Luke and the Empire wins.
But that's not even the true compromise in this case, because you could have used any other, less network-fragile tool to accomplish the same goal. You could have called up Obi Wan (Freenet) or Yoda (Tor), but instead you handed the job to the ten-year-old kid.
What a poor choice of analogy. This is not a hollywood movie this is the real world with actual people in an emergency situation right now.
Your house is on fire and the firemen tell you they will not come to help because if they do they may not be able to deal with potential houses on fire in a not so distant hypothetical future ?
That is like 100% not was said. I will re-explain it in simpler terms.
We don't currently have a censorship-resistant way to get Wikipedia to Turkey, at all. IPFS is not it, because there's no reason for Turkey not to censor all of IPFS. There is no alternative to IPFS that Turkey won't censor, either.
If IPFS wants to become it (which is a good goal that we should pursue), it first needs to become used / useful enough that Turkey won't be able to censor all of IPFS without significant economic damage to the country.
There are people in turkey replicating this snapshot right now. people browsing locally get it there. Even if all connections to outside the country get shut down it can be distributed locally.
But it won't grow unless others can download IPFS software to continue hosting it and there is no reason to believe they could not simply block it internally as well to prevent spreading.
As said before, it needs to be used/useful to many normal people (like a previous example of GitHub) before there it requires too much political will to effectively block.
Installing software from a USB drive is within the reach of most normal teens and young adults in the developing world. So, sneakernet -> IPFS -> Wikipedia is a viable path so long as blocking the IPFS protocol, over all reasonable transports, is hard enough to do.
Responding to 0xCPM (sibling comment). IPFS was not designed to hide the sources but thanks to versatility of transports (you can ever run it on cjdns or mesh network) and possibility of using it offline it is not easy to censor.
The person I was responding to was talking about people getting the IPFS software via IPFS or in person delivery of media. This is not a promising method for distributing anything to normal people, even if it later lets you view Wikipedia.
What prevents Turkish ISPs from blocking peer-to-peer IPFS connections within the country?
(I'm having trouble figuring out exactly how IPFS presents itself at the network layer, and whether an IPFS connection over TCP/IP is noticeably different from some other normal connection type, so I genuinely don't know the answer to this question. It looks like it uses SPDY over TLS, but maybe something in the certificate gives it away?)
I was wondering the same, but knowing the kind of DPI equipment that has been sold to Syria, Lybia and other countries I assume that it possible to detect, monitor, tamper and block pretty much any kind of traffic, including IPFS.
I don't know how to make this work with IPFS' P2P approach: a request for www.google.com with a destination IP of some residential Turkey customer looks awfully suspicious. I suppose it's workable if App Engine has a colo inside Turkey.
There's a circuit switching relay protocol [1] in the works which will allow multi-hop connections. This is generally useful for situations where two nodes can't directly connect to each other, be it because of NAT, censorship, or simply because they don't have a transport protocol in common (e.g. js-ipfs in the browser).
That means nodes can soon use the Websockets transport to connect to a domain-fronted node (this part already works), which then acts as a relay.
Connections over the libp2p-tcp transport are trivial to spot, but there's more transports available (Websockets, WebRTC, UTP), and even more in the works (Onion, QUIC, FlyWeb).
No, he's just saying they probably announced this at a point where their network is (presently) too weak to achieve what they want, so they may be shooting themselves in the foot a little bit.
> their network is (presently) too weak to achieve what they want
That's certainly a plausible hypothesis, but without evidence, definitions of words like "weak" and a proper wash through the scientific method, I'm not convinced we can make conclusions like that at this point in time.
That's not a conclusion, it's a claim by a human in a discussion. It is certainly not the case that you need a double-blind study before you can have any opinion on a subject (and, I'd argue, a complete misunderstanding of the scientific method).
It's certainly a more defensible claim than the completely irrelevant ad hominem you made about Keybase being "docile in the face of evil". Why was the commenter's employer relevant to the discussion?
You not being convinced is no excuse for derailing the discussion.
Behavior like this makes people think twice about even trying to engage with the crypto-loving, privacy conscious, free-speech market segment, because even trying to do anything in that direction is met with abuse.
I think the original comment was more about the style and wording of the announcement, not about whether this ipfs group should or should not have done this.
If IPFS is blocked and the people that need anti-censorship tools can't use it then they might as well not have bothered.