Hacker News Reader

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-...

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 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.

>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

I am not native english speaker so perhaps was misunderstood again. You searched for a content by an author, and the network gives you multiple hashes, which one do you trust, without a central authority telling you?

As with my comment above: you trust the content that is ultimately (up the hierarchy) signed in an IPNS object with a valid signature.

And there must indeed by some central authority giving 'ultimate trust'. This is Zooko's triangle. By default IPNS gives you 'decentralized' and 'secure', but you can also opt to tie an IPNS name to a DNS TXT record, and lose 'decentralized' (at least for the initial lookup) but gain 'human-meaningful'.

I think there is a level where DNS -> IPNS ID is even then still better than DNS -> IP address. For DNS -> IPNS you could have a facility in there saying 'This DNS TXT record should not change, if it does something is wrong'. You could lock down the record for a period of time, such as the duration of the lease from the registrar.

Besides, the idea is that IPFS could happily support Namecoin[1], so there's the decentralized, secure, and human-meaningful DNS service. The only 'non-secure' aspect there is the unlikely event of a 51% attack.

[1] https://namecoin.info

A 51% attack will let you double spend and roll back transactions. If one wanted to steal an established name on Namecoin, they'd need to either roll back to before it's registration, roll back to before it's previous renewal and force an expiration, or mine past it's next renewal to force expiration. Renewal limit is 36,000 blocks. For a name that consistently renews early every 18,000 blocks a 51% attack would need to go on for months to steal it. Still possible, but very difficult.

Namecoin is merge-mined with Bitcoin by many miners, so if you wanted to 51% it you'd need a pretty large chunk of Bitcoin's hash power. An evil pool could do this, however it would be visible on the Bitcoin blockchain that they were doing it (although not what transactions are present/not present in the attack chain).

I think the fundamental misunderstanding here is that you can't search by author. You can fetch by IPFS hash or IPNS pubkey (which is tied to a hash). You can also use existing name services (such as DNS or namecoin) to tie human-meaningful names to a pubkey or hash. (but probably a pubkey)

I don't really see how your 'competing for resources' scenario would work. New peers that try to fetch the new content at some IPNS name would see a new IPFS object hash, and search the DHT for that new hash. Nodes that have an old version won't be involved (unless of course the object 'hierarchy' contains cached data, which will only speed things up). At first the only peer having the new content will probably be the creator, but this will quickly spread across the network.

As long as peers do not decide to keep the data (by pinning the hash), the old content will simply be deleted and replaced with new content. Pinning is extremely cheap, so you can imagine that you would want to auto-pin pages as you visit them. This is not on by default though, and I think that's a good thing.

> [B]ut without a central management how does IPFS associate correct file to the correct hash?

It does so using cryptographic identities. In IPFS every peer has a private/public keypair, and the PeerId is the hash of its public key. When publishing content under an IPNS name (which always has the PeerId at its root), you must prove that you 'own' the PeerID by signing the object with your private key. Other nodes will not 'mirror' your IPNS object unless the signature matches (which makes a nice consensus).

The paper calls this self-certified names: you can distribute the objects, and let them be provided by third parties without losing authenticity. See section 3.7.

> 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.

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.

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.

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.

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.

1. Don't use it for what's basically messaging

2. I thought torrents can work decentralized e.g. using magnet links and DHTs.

You can still use IPFS for direct messaging though, see 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.

Even DHTs require a server to bootstrap the network, due to a node's unicast nature on the internet.

That's why there's the magnet links, isn't it?