5 ms·

This sounded like many of the bitcoin projects, specially filecoin and upon reading further I came to know it is by the same guys. Similar projects have been i

by kang 11y ago

This sounded like many of the bitcoin projects, specially filecoin and upon reading further I came to know it is by the same guys. Similar projects have been in development for past few years such as https://github.com/feross/webtorrent https://github.com/feross/webtorrent and zeronet This has same problems as the bitcoin infrastructure though: 1. It is unscalable. A page built on IPFS receiving huge inflow of comments would generate many diffs quickly and as soon as they spread in the network they get outdated, thereby clogging space on people's disks but more importantly clogging the bandwidth where nodes compete to download the quickly changing diffs. 2. This is not completely decentralised because it uses bittorrent trackers to identify the nodes in the network. Taking down the the trackers would take down the system as well. Webtorrent is an already working, fast, alternative to IPFS but still centralised. Think of it this way, can you do a pure peer-to-peer webrtc site without needing a ICE/TURN/STUN server? Peer discovery is the centralised part of the problem.

conceit 11y ago
1. Don't use it for what's basically messaging 2. I thought torrents can work decentralized e.g. using magnet links and DHTs.
- reit 11y ago
  You can still use IPFS for direct messaging though, see http://gateway.ipfs.io/ipfs/QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/example#/ipfs/QmThrNbvLj7afQZhxH72m5Nn1qiVn3eMKWFYV49Zp2mv9B/api/service/readme.md http://gateway.ipfs.io/ipfs/QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsN... The difference being you're addressing to IPFS node IDs, rather than IP addresses. The advantage here is that your IP address could change (moving datacenters etc.), but your node ID never needs to change. Technically you could just use IPFS for routing to between clients and your standard PHP server, which would still be an improvement over the current approach and would guarantee a DNS whoopsie couldn't redirect your site to China, but you'll get better results (less bandwidth required, guaranteed uptime) by decentralizing as much as you can.
- kang 11y ago
  Even DHTs require a server to bootstrap the network, due to a node's unicast nature on the internet.
  - conceit 11y ago
    That's why there's the magnet links, isn't it?
espadrine 11y ago
I concur. On principle, they could let the centralized server propagate the information that the file was updated. They could convert IPFS to a mere cache sharing system between browsers that are close by.
cjbprime 11y ago
> uses bittorrent trackers to identify the nodes in the network It's using a distributed hash table, not trackers. Nothing's completely decentralized; distributed hash tables are pretty good, since you can join them by talking to any participating node at all.
- kang 11y ago
  That is true for the data lookup part where DHTs are replacing DNS in a way put still the peers need to discover each other's ip in some way. I don't know what would be the term for it since it is not completely centralised, as in the nodes collectively form the system without any central coordination, but a new node joining in still needs some information to connect to the network from some source which could be denied-of-service by say a government, so not completely decentralised either.
  - reit 11y ago
    It would be quite difficult to blacklist every bootstrap node. The thing is, every single IPFS node represents a DHT bootstrap node. In a world where everyone is using IPFS you could just turn to the stranger next to you, ask for his IP address, and bootstrap off him. You only need one single node to prise your way into the DHT network, one is enough to build out the rest of the network from.
  - deleted 11y ago
    [deleted]
  - cjbprime 11y ago
    The BitTorrent DHT's never been successfully attacked or blocked as far as I know. It doesn't seem like a big concern. There are millions of nodes and you only need to find out the IP:port of one of them.
Confiks 11y ago
As for your first point, you should really first learn more about how IPFS handles content addressing. If you look at section 3.5 the paper[1], you see that a IPFS object consists of a free-form data field, and an arbitrary amount of links to other IPFS objects. This is a very flexible format that allows for caching. You talk about a page with comments. You could (this is an example) create three 'models': a Page, a PageBody and a Comment (which 'inherit' from IPFSObject). A Page would contain links to one PageBody and multiple Comment objects. Every time a comment is posted, a link is added to the Page object (so its hash changes), but the PageBody (where the majority of the page size presumably is) doesn't have to change. All peers can keep the same PageBody cached, while the latest Page contains all the desired comments. This caching mechanism will also work for unchanged comments. Every time the Page changes, its hash would be published under some IPNS name, so peers will always retrieve the latest version. [1] https://github.com/ipfs/papers/raw/master/ipfs-cap2pfs/ipfs-p2p-file-system.pdf https://github.com/ipfs/papers/raw/master/ipfs-cap2pfs/ipfs-...
- kang 11y ago
  I gave a poor example. What I wanted to say was an ever changing data in a non-centrally managed context. Some nodes hold hashes for the previous version and then they'd compete for resources. The thing from bitcoin is 51% attack where majority of nodes collude to provide the wrong data(they might not be malicious but just serving old version of a data). This can only be prevented by time-stamping in slow scenarios. In case of neocities, a central server is giving you a hash that the nodes would provide you the data for, but without a central management how does IPFS associate correct file to the correct hash? If it only works for a centralised scenario then it is similar to the http://peercdn.com http://peercdn.com project where instead of a server supplying content, your previous visitor browser cache is supplying the content through p2p webrtc and you save server bandwidth.
  - reit 11y ago
    >In case of neocities, a central server is giving you a hash that the nodes would provide you the data for, but without a central management how does IPFS associate correct file to the correct hash? Mathematics[1]. Your hash is based on the content of the file, therefore you can guarantee that the content is the same as what the original author published. Also, IPFS is not a blockchain, there is no 51% attack. https://en.wikipedia.org/wiki/Cryptographic_hash_function https://en.wikipedia.org/wiki/Cryptographic_hash_function

by kang 11y ago

conceit 11y ago

1. Don't use it for what's basically messaging 2. I thought torrents can work decentralized e.g. using magnet links and DHTs.

reit 11y ago
You can still use IPFS for direct messaging though, see http://gateway.ipfs.io/ipfs/QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/example#/ipfs/QmThrNbvLj7afQZhxH72m5Nn1qiVn3eMKWFYV49Zp2mv9B/api/service/readme.md http://gateway.ipfs.io/ipfs/QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsN... The difference being you're addressing to IPFS node IDs, rather than IP addresses. The advantage here is that your IP address could change (moving datacenters etc.), but your node ID never needs to change. Technically you could just use IPFS for routing to between clients and your standard PHP server, which would still be an improvement over the current approach and would guarantee a DNS whoopsie couldn't redirect your site to China, but you'll get better results (less bandwidth required, guaranteed uptime) by decentralizing as much as you can.
kang 11y ago
Even DHTs require a server to bootstrap the network, due to a node's unicast nature on the internet.
- conceit 11y ago
  That's why there's the magnet links, isn't it?

espadrine 11y ago

I concur. On principle, they could let the centralized server propagate the information that the file was updated. They could convert IPFS to a mere cache sharing system between browsers that are close by.

cjbprime 11y ago

> uses bittorrent trackers to identify the nodes in the network It's using a distributed hash table, not trackers. Nothing's completely decentralized; distributed hash tables are pretty good, since you can join them by talking to any participating node at all.

kang 11y ago
That is true for the data lookup part where DHTs are replacing DNS in a way put still the peers need to discover each other's ip in some way. I don't know what would be the term for it since it is not completely centralised, as in the nodes collectively form the system without any central coordination, but a new node joining in still needs some information to connect to the network from some source which could be denied-of-service by say a government, so not completely decentralised either.
- reit 11y ago
  It would be quite difficult to blacklist every bootstrap node. The thing is, every single IPFS node represents a DHT bootstrap node. In a world where everyone is using IPFS you could just turn to the stranger next to you, ask for his IP address, and bootstrap off him. You only need one single node to prise your way into the DHT network, one is enough to build out the rest of the network from.
- deleted 11y ago
  [deleted]
- cjbprime 11y ago
  The BitTorrent DHT's never been successfully attacked or blocked as far as I know. It doesn't seem like a big concern. There are millions of nodes and you only need to find out the IP:port of one of them.

Confiks 11y ago

As for your first point, you should really first learn more about how IPFS handles content addressing. If you look at section 3.5 the paper[1], you see that a IPFS object consists of a free-form data field, and an arbitrary amount of links to other IPFS objects. This is a very flexible format that allows for caching. You talk about a page with comments. You could (this is an example) create three 'models': a Page, a PageBody and a Comment (which 'inherit' from IPFSObject). A Page would contain links to one PageBody and multiple Comment objects. Every time a comment is posted, a link is added to the Page object (so its hash changes), but the PageBody (where the majority of the page size presumably is) doesn't have to change. All peers can keep the same PageBody cached, while the latest Page contains all the desired comments. This caching mechanism will also work for unchanged comments. Every time the Page changes, its hash would be published under some IPNS name, so peers will always retrieve the latest version. [1] https://github.com/ipfs/papers/raw/master/ipfs-cap2pfs/ipfs-p2p-file-system.pdf https://github.com/ipfs/papers/raw/master/ipfs-cap2pfs/ipfs-...

kang 11y ago
I gave a poor example. What I wanted to say was an ever changing data in a non-centrally managed context. Some nodes hold hashes for the previous version and then they'd compete for resources. The thing from bitcoin is 51% attack where majority of nodes collude to provide the wrong data(they might not be malicious but just serving old version of a data). This can only be prevented by time-stamping in slow scenarios. In case of neocities, a central server is giving you a hash that the nodes would provide you the data for, but without a central management how does IPFS associate correct file to the correct hash? If it only works for a centralised scenario then it is similar to the http://peercdn.com http://peercdn.com project where instead of a server supplying content, your previous visitor browser cache is supplying the content through p2p webrtc and you save server bandwidth.
- reit 11y ago
  >In case of neocities, a central server is giving you a hash that the nodes would provide you the data for, but without a central management how does IPFS associate correct file to the correct hash? Mathematics[1]. Your hash is based on the content of the file, therefore you can guarantee that the content is the same as what the original author published. Also, IPFS is not a blockchain, there is no 51% attack. https://en.wikipedia.org/wiki/Cryptographic_hash_function https://en.wikipedia.org/wiki/Cryptographic_hash_function