7 ms·

That's a great initiative. I was hoping IPFS would be the de facto way to publish uncensorable websites, but I have grown more and more disappointed in it, as i

That's a great initiative. I was hoping IPFS would be the de facto way to publish uncensorable websites, but I have grown more and more disappointed in it, as it fails a lot for me in its most basic purpose (fetching files). Hopefully one of the other competitors will do better, but IPFS got a bunch of theoretical stuff right, in my opinion (mainly immutability of objects).

dmix 7y ago
Why does it have trouble fetching files?
- neuralzen 7y ago
  Maybe OP is talking about IPNS? Which is unfortunately quite slow... I had to fuss with my TXT entries in DNS a bit to speed things up to an acceptable level (and reference the site via IPFS instead of IPNS)
  - StavrosK 7y ago
    Unfortunately even normal fetching is iffy. Content I add to some content isn't discovered by other nodes quickly.
    - tylersmith 7y ago
      Yeah that's IPNS as the GP suspected. It's definitely the hardest part of working on top of the IPFS ecosystem. Direct IPFS lookups are much, much better. On the OpenBazaar project we're experimenting with a centralized IPNS record server that is used to provide a fast response while a real IPNS lookup is done in the background to ensure we're not censoring. Because records are signed the only thing we could do is censor newer IPNS records and serve old ones, but then nodes just revert back to the slower-to-update records like they had before.
      - StavrosK 7y ago
        I'm not talking about IPNS, I'm talking about normal IPFS lookups. Hopefully this will improve (maybe has improved, I haven't tested lately), but it used to be bad, to the point where some gateways wouldn't discover content that already existed on other gateways.
- StavrosK 7y ago
  I'm not sure why, but if you have a node that has been running for a while and you add some files to it, some gateways will find them right away and others will keep timing out for many minutes. Discovery seems to be very hit-or-miss, and it's the most important component of IPFS...
PureParadigm 7y ago
From what I can tell, one of the main goals of IPFS is decentralization. Anyone can be hosting the file you want and it will download from any of the peers. Does OnionShare do this? As you mentioned, I've also found IPFS to be fragile, particularly in that it is unlikely for stuff to stay up reliably, as ironic as that is. If I'm trying to host a website with not too much traffic (nobody else replicating), I have to keep my computer online or it will become inaccessible.
- shadowgovt 7y ago
  > Does OnionShare do this? IIUC, it's onion-routing request traffic to your computer, but your computer is still acting as the sole server of the website. Turning off your machine gives incoming requests nowhere to resolve to.
  - p4bl0 7y ago
    In practice it is the case for IPFS too most of the time.
- icebraining 7y ago
  > it is unlikely for stuff to stay up reliably, as ironic as that is Well, it's kinda inevitable with these systems, since there's limited available space. Freenet lets you "insert" data into the network (copy to other nodes) and disconnect your computer, but if nobody requests that data, it'll also eventually disappear from every node.
- momack2 7y ago
  There's an annoying misconception that IPFS is "free storage" - it's not. If you care about something sticking around on the network, you need to take action to ensure that happens: either as an individual pinning it to a persistent node you run, as a developer paying a distributed pinning service to host your dapp data, or as a community creating a social agreement to all peer their nodes to replicate each other's data. All these solutions are doable today, but you shouldn't expect others to host your content for free (if it isn't popular enough for other people to be proactively caching it). IPFS is the distributed network for addressing files, you have to bring, buy, or share your own storage - anything else (ex forced hosting of content you don't choose) would have problematic liabilities!
jmeyer2k 7y ago
I've worked with IPFS and I completely agree with you here. There are so many basic bugs that haven't been fixed because of the over abstraction of LibP2P. Currently, it connects to bootstrap nodes and tries to discover peers asynchronously. Obviously, it doesn't handshake with the bootstrap nodes in time for it to start discovering peers so it waits another 1-5 minutes depending on the setting to try discovering again. Startup usually takes a few minutes due to this trivial problem and an issue has been open for it since May: https://github.com/ipfs/go-ipfs/issues/5953 https://github.com/ipfs/go-ipfs/issues/5953
- momack2 7y ago
  IPFS person here - there are a ton of improvements to the libp2p DHT in the works (many which also relate to bootstrapping efficiency), but a key component of shipping these to an active 100K+ node network like IPFS is testing and validation, so it's taking us longer to ship these improvements while we build a testground able to simulate network conditions to increase network _reliability_ as well as performance. IPFS is still actively WIP and directly focused on improving performance, reliability, and usability - so feedback and collaborators welcome to help us address these issues head-on. =]
  - rosybox 7y ago
    I like where IPFS is going and I think it's an important bit of software, so it's good to hear you're working on it. I do have a question though on the immutability, how do you address problems where people contribute harmful content, such as revenge porn pictures, or doxing someone? If the content is immutable, it means these things would always exist and never be removable? Is there any moderation that can stop this kind of stuff? Just wondering, I still like the idea, it's just a question I have been thinking about.
    - pault 7y ago
      Unfortunately if you want an uncensorable network you won't be able to censor the nasty stuff either.
    - 7y ago
dooglius 7y ago
IPFS has built-in denylists so it isn't very uncensorable.
- momack2 7y ago
  Not sure where you got that info, but AFAIK that is incorrect. While everyone running their own infra has the responsibility to comply with local laws (or face local consequences) - there is no central network allow/denylist. Every single node has the power to decide what content they pin and make accessible to other nodes in the network, or how to consume content coming from other nodes (ex they might choose to filter out certain types of content). There is no central ipfs authority involved in any of that. If an individual node wanted to opt-in to a collaborative denylist (ex to block spam, etc), this is the most recent proposal for how that might work: https://github.com/ianjdarrow/content-decider https://github.com/ianjdarrow/content-decider (still in design phase)
  - dooglius 7y ago
    https://github.com/ipfs/faq/issues/36#issuecomment-140567411 https://github.com/ipfs/faq/issues/36#issuecomment-140567411 My understanding is that it is not possible for Tor nodes to block (or even know about) what you are accessing.
    - deleted 7y ago
      [deleted]
    - schoen 7y ago
      A Tor exit node can block destinations openly by declaring limitations in its exit policy (in principle by IP address or port, although I don't know if any exit policies use IP address this way) or by simply firewalling connections from itself to particular destinations. In the latter case, the node may be marked as a BadExit if a scanner detects that it intentionally blocked a connection that it offered to relay. A node in an earlier position in a circuit can't know the ultimate destination of the circuit, or the content exchanged over it, although it could in theory blacklist individual nodes as a next hop (which doesn't typically really accomplish anything for content-blocking purposes, and could also be detected if it were a pervasive practice). I think in HSv2 (the old hidden services protocol) there were a number of different opportunities for relays to selectively disrupt hidden service connections, while in HSv3 (the new revision) there are fewer. A difference between Tor and IPFS in regard to what you're mentioning above is that in Tor, a specific entity (a specific clearnet or hidden service site operator) has to continue actively hosting a resource in order for it to remain accessible at its original location, while in IPFS, it's more like that there need to be some participants who haven't actively declined to host it, but they don't have to be the same as the original publisher.
JoshuaMulliken 7y ago
Unfortunately, I think projects like this that make it easy to create onion resources are quite dangerous. The reduction of friction to host material online in a completely anonymous way only enables adverse actions like the sharing of CP or other illegal content. Please look here for a good explaination of friction in this space -> https://stratechery.com/2019/child-sexual-abuse-material-online-the-problem-with-community-towards-more-friction/ https://stratechery.com/2019/child-sexual-abuse-material-onl... If it is used by political or marginalized communities, then this project is also not useful. It does not have the support or attention required to enable it to be secure enough like the TOR project does. This application opens up legitimate users to incredible risk. If I were a dissident, I would take my time and do the research required to set up a system like this in the correct way. This project may give people a sense of false security.
- DuskStar 7y ago
  Ah, yes. The good old "don't make that tool because bad people might use it" argument. Similarly, we should ban sharing information on hacking/security because bad people might use it, and require that all communications be visible to the government to prevent abuse.
  - JoshuaMulliken 7y ago
    That is not the argument being made. It is an argument that having friction in the process to do something that may have dangerous outcomes is sometimes positive. It is much the same as arguments that there should be gun training required to purchase a firearm. Adding friction to a process sometimes provides positive benefits.
    - DuskStar 7y ago
      > That is not the argument being made. It is an argument that having friction in the process to do something that may have dangerous outcomes is sometimes positive. The argument being made, as far as I can tell, is that this tool will make doing bad things easier, and thus this tool should not be made. As any tool to resist censorship will also enable said bad things, I do not find this to be a valid concern. (And since some governments would list censorship resistance itself as one of those bad things, this is always going to be true) > It is much the same as arguments that there should be gun training required to purchase a firearm. I think the tech equivalent to this would be mandating a "don't sexually exploit children" class before allowing purchase of a computer. (As you might guess, I'm not a fan) > Adding friction to a process sometimes provides positive benefits. Sure, but you have to make sure the collateral damage is minimized AND that you're actually catching the offending segment of the population. Mandating gun training before purchase is actually a great comparison here - the vast majority of gun crime in the US is committed with illegally acquired weapons (which would be unaffected by the mandate), just like I imagine that the majority of CSE imagery shared on the internet uses something more robust than OnionShare. So in both cases you'd have high collateral damage with minimal impact to the population you actually care about affecting...
Erlich_Bachman 7y ago
Does IPFS even try to provide anonymity? Even if it would be technically "censorship-resistant", what good is it when everyone can see who hosts the content, track them down, and subpoena/arrest them?
- derefr 7y ago
  No, anonymity isn't a goal of IPFS. If you add anonymity (for both consumers and publishers) to IPFS, you get the design of its older sibling: FreeNet.

dmix 7y ago

Why does it have trouble fetching files?

neuralzen 7y ago
Maybe OP is talking about IPNS? Which is unfortunately quite slow... I had to fuss with my TXT entries in DNS a bit to speed things up to an acceptable level (and reference the site via IPFS instead of IPNS)
- StavrosK 7y ago
  Unfortunately even normal fetching is iffy. Content I add to some content isn't discovered by other nodes quickly.
  - tylersmith 7y ago
    Yeah that's IPNS as the GP suspected. It's definitely the hardest part of working on top of the IPFS ecosystem. Direct IPFS lookups are much, much better. On the OpenBazaar project we're experimenting with a centralized IPNS record server that is used to provide a fast response while a real IPNS lookup is done in the background to ensure we're not censoring. Because records are signed the only thing we could do is censor newer IPNS records and serve old ones, but then nodes just revert back to the slower-to-update records like they had before.
    - StavrosK 7y ago
      I'm not talking about IPNS, I'm talking about normal IPFS lookups. Hopefully this will improve (maybe has improved, I haven't tested lately), but it used to be bad, to the point where some gateways wouldn't discover content that already existed on other gateways.
StavrosK 7y ago
I'm not sure why, but if you have a node that has been running for a while and you add some files to it, some gateways will find them right away and others will keep timing out for many minutes. Discovery seems to be very hit-or-miss, and it's the most important component of IPFS...

PureParadigm 7y ago

From what I can tell, one of the main goals of IPFS is decentralization. Anyone can be hosting the file you want and it will download from any of the peers. Does OnionShare do this? As you mentioned, I've also found IPFS to be fragile, particularly in that it is unlikely for stuff to stay up reliably, as ironic as that is. If I'm trying to host a website with not too much traffic (nobody else replicating), I have to keep my computer online or it will become inaccessible.

shadowgovt 7y ago
> Does OnionShare do this? IIUC, it's onion-routing request traffic to your computer, but your computer is still acting as the sole server of the website. Turning off your machine gives incoming requests nowhere to resolve to.
- p4bl0 7y ago
  In practice it is the case for IPFS too most of the time.
icebraining 7y ago
> it is unlikely for stuff to stay up reliably, as ironic as that is Well, it's kinda inevitable with these systems, since there's limited available space. Freenet lets you "insert" data into the network (copy to other nodes) and disconnect your computer, but if nobody requests that data, it'll also eventually disappear from every node.
momack2 7y ago
There's an annoying misconception that IPFS is "free storage" - it's not. If you care about something sticking around on the network, you need to take action to ensure that happens: either as an individual pinning it to a persistent node you run, as a developer paying a distributed pinning service to host your dapp data, or as a community creating a social agreement to all peer their nodes to replicate each other's data. All these solutions are doable today, but you shouldn't expect others to host your content for free (if it isn't popular enough for other people to be proactively caching it). IPFS is the distributed network for addressing files, you have to bring, buy, or share your own storage - anything else (ex forced hosting of content you don't choose) would have problematic liabilities!

jmeyer2k 7y ago

I've worked with IPFS and I completely agree with you here. There are so many basic bugs that haven't been fixed because of the over abstraction of LibP2P. Currently, it connects to bootstrap nodes and tries to discover peers asynchronously. Obviously, it doesn't handshake with the bootstrap nodes in time for it to start discovering peers so it waits another 1-5 minutes depending on the setting to try discovering again. Startup usually takes a few minutes due to this trivial problem and an issue has been open for it since May: https://github.com/ipfs/go-ipfs/issues/5953 https://github.com/ipfs/go-ipfs/issues/5953

momack2 7y ago
IPFS person here - there are a ton of improvements to the libp2p DHT in the works (many which also relate to bootstrapping efficiency), but a key component of shipping these to an active 100K+ node network like IPFS is testing and validation, so it's taking us longer to ship these improvements while we build a testground able to simulate network conditions to increase network _reliability_ as well as performance. IPFS is still actively WIP and directly focused on improving performance, reliability, and usability - so feedback and collaborators welcome to help us address these issues head-on. =]
- rosybox 7y ago
  I like where IPFS is going and I think it's an important bit of software, so it's good to hear you're working on it. I do have a question though on the immutability, how do you address problems where people contribute harmful content, such as revenge porn pictures, or doxing someone? If the content is immutable, it means these things would always exist and never be removable? Is there any moderation that can stop this kind of stuff? Just wondering, I still like the idea, it's just a question I have been thinking about.
  - pault 7y ago
    Unfortunately if you want an uncensorable network you won't be able to censor the nasty stuff either.
  - 7y ago

dooglius 7y ago

IPFS has built-in denylists so it isn't very uncensorable.

momack2 7y ago
Not sure where you got that info, but AFAIK that is incorrect. While everyone running their own infra has the responsibility to comply with local laws (or face local consequences) - there is no central network allow/denylist. Every single node has the power to decide what content they pin and make accessible to other nodes in the network, or how to consume content coming from other nodes (ex they might choose to filter out certain types of content). There is no central ipfs authority involved in any of that. If an individual node wanted to opt-in to a collaborative denylist (ex to block spam, etc), this is the most recent proposal for how that might work: https://github.com/ianjdarrow/content-decider https://github.com/ianjdarrow/content-decider (still in design phase)
- dooglius 7y ago
  https://github.com/ipfs/faq/issues/36#issuecomment-140567411 https://github.com/ipfs/faq/issues/36#issuecomment-140567411 My understanding is that it is not possible for Tor nodes to block (or even know about) what you are accessing.
  - deleted 7y ago
    [deleted]
  - schoen 7y ago
    A Tor exit node can block destinations openly by declaring limitations in its exit policy (in principle by IP address or port, although I don't know if any exit policies use IP address this way) or by simply firewalling connections from itself to particular destinations. In the latter case, the node may be marked as a BadExit if a scanner detects that it intentionally blocked a connection that it offered to relay. A node in an earlier position in a circuit can't know the ultimate destination of the circuit, or the content exchanged over it, although it could in theory blacklist individual nodes as a next hop (which doesn't typically really accomplish anything for content-blocking purposes, and could also be detected if it were a pervasive practice). I think in HSv2 (the old hidden services protocol) there were a number of different opportunities for relays to selectively disrupt hidden service connections, while in HSv3 (the new revision) there are fewer. A difference between Tor and IPFS in regard to what you're mentioning above is that in Tor, a specific entity (a specific clearnet or hidden service site operator) has to continue actively hosting a resource in order for it to remain accessible at its original location, while in IPFS, it's more like that there need to be some participants who haven't actively declined to host it, but they don't have to be the same as the original publisher.

JoshuaMulliken 7y ago

Unfortunately, I think projects like this that make it easy to create onion resources are quite dangerous. The reduction of friction to host material online in a completely anonymous way only enables adverse actions like the sharing of CP or other illegal content. Please look here for a good explaination of friction in this space -> https://stratechery.com/2019/child-sexual-abuse-material-online-the-problem-with-community-towards-more-friction/ https://stratechery.com/2019/child-sexual-abuse-material-onl... If it is used by political or marginalized communities, then this project is also not useful. It does not have the support or attention required to enable it to be secure enough like the TOR project does. This application opens up legitimate users to incredible risk. If I were a dissident, I would take my time and do the research required to set up a system like this in the correct way. This project may give people a sense of false security.

DuskStar 7y ago
Ah, yes. The good old "don't make that tool because bad people might use it" argument. Similarly, we should ban sharing information on hacking/security because bad people might use it, and require that all communications be visible to the government to prevent abuse.
- JoshuaMulliken 7y ago
  That is not the argument being made. It is an argument that having friction in the process to do something that may have dangerous outcomes is sometimes positive. It is much the same as arguments that there should be gun training required to purchase a firearm. Adding friction to a process sometimes provides positive benefits.
  - DuskStar 7y ago
    > That is not the argument being made. It is an argument that having friction in the process to do something that may have dangerous outcomes is sometimes positive. The argument being made, as far as I can tell, is that this tool will make doing bad things easier, and thus this tool should not be made. As any tool to resist censorship will also enable said bad things, I do not find this to be a valid concern. (And since some governments would list censorship resistance itself as one of those bad things, this is always going to be true) > It is much the same as arguments that there should be gun training required to purchase a firearm. I think the tech equivalent to this would be mandating a "don't sexually exploit children" class before allowing purchase of a computer. (As you might guess, I'm not a fan) > Adding friction to a process sometimes provides positive benefits. Sure, but you have to make sure the collateral damage is minimized AND that you're actually catching the offending segment of the population. Mandating gun training before purchase is actually a great comparison here - the vast majority of gun crime in the US is committed with illegally acquired weapons (which would be unaffected by the mandate), just like I imagine that the majority of CSE imagery shared on the internet uses something more robust than OnionShare. So in both cases you'd have high collateral damage with minimal impact to the population you actually care about affecting...

Erlich_Bachman 7y ago

Does IPFS even try to provide anonymity? Even if it would be technically "censorship-resistant", what good is it when everyone can see who hosts the content, track them down, and subpoena/arrest them?

derefr 7y ago
No, anonymity isn't a goal of IPFS. If you add anonymity (for both consumers and publishers) to IPFS, you get the design of its older sibling: FreeNet.