Live data from Hacker News

Show HN: A Decentralized StatusPage on IPFS

dstatuspage.net

111–120 of 130 posts

Re: Show HN: A Decentralized StatusPage on IPFS

#111

Earlier quoted context omitted.

No, if you run ipfs, you only host what you choose to host and things that you have recently requested. Your node doesn't passively accept content from others to host. (Otherwise, a joker would probably saturate the entire network's hosting capacity with /dev/urandom, or everyone would saturate the network's hosting capacity with their own encrypted backups, etc.) I think there must be something wrong with the way ip…

It's likely due to people thinking that "distributed" means "distributed by default". IPFS needs to gear it's docs to make people think in terms of Bittorrent (i.e. pinning, seeding, etc) and not in terms of RAID (i.e. sharding, high availability).

I wonder how much of it is the NSA and GCHQ's of the world trying to scare people away from using IPFS...

Re: Show HN: A Decentralized StatusPage on IPFS

#112
Has anyone here used both IPFS and DAT in-depth?

I am a happy IPFS user, and it seems that it has more traction than DAT. But on the other hand, the Beaker Browser project (which is based on DAT) is very interesting, and doesn't seem to have an equivalent in IPFS. I'm also worried that the IPFS team might get distracted by Filecoin and not invest seriously in the IPFS ecosystem beyond what Filecoin needs.

I'm interested to hear what others think?

Re: Show HN: A Decentralized StatusPage on IPFS

#113

Earlier quoted context omitted.

It supports blacklists now too. The bigger mitigation is that IPFS is a "push" and not a "pull" system, so you only store content you have explicitly requested.

Your blacklist becomes someone else's favorites list. Changing a single byte changes the entire hash, so blacklists aren't a great solution if censorship is what you're after.

Blacklists are double hashed, so they aren't useful for finding 'bad' content.

Re: Show HN: A Decentralized StatusPage on IPFS

#114

Earlier quoted context omitted.

One word: IPNS. It's a DNS-like system, though much slower than DNS due to propagation delays. It points to the latest version (hash) of a document, much like a git branch.

How slow are we talking? Hours, days? Or seconds, minutes?

For IPNS, my experience says it could take up to 30 seconds to publish and up to 10s to resolve.

Re: Show HN: A Decentralized StatusPage on IPFS

#115
Decentralized is the new buzzword in the crypto community and it is used everywhere to justify everything. I lost count how many times people were trying to sell me ideas with "its decentralized, you get it???". I am getting more and more resilient to take anything seriously that is solved with this. For me S3 is a perfect storage and with Cloudfront is decentralized enough for my use cases. As far as I am concerned a node that is not under AWS or my control is not the definition of decentralized it just means that you have less control over a distributed object store that has worse access patterns than for example S3. Bandwidth is one of the problems. If a typical IPFS node is a home computer than it has 10x upload speed compare to the download speed. This is going to limit how somebody can access content from IPFS. And so on. These access patterns are pretty relevant when you are hosting something other than backups on such a system.

Re: Show HN: A Decentralized StatusPage on IPFS

#116
post #62

Earlier quoted context omitted.

IPNS has a huge flaw, as I understand it - there is no way to prove, as a consumer of an IPNS name, that you’ve got the latest data. A malicious node in the network could present you with outdated information and you’d have no way to tell.

You can't prove that you got the absolute latest data (same with DNS by the way) as it's being distributed. However, a malicious node in the network can't present you with outdated information or false information, as the IPNS record is signed with the key from the peer. If the IPNS record wasn't signed, it would indeed be a huge flaw as it wouldn't be tied to a key from a peer. That would defeat the entire purpose o…

>> Luckily, we don't have that flaw in IPNS :)

And you have the math proof of that, right?

Re: Show HN: A Decentralized StatusPage on IPFS

#117
post #25

Earlier quoted context omitted.

The latest would be a link like /ipns/yourcompany.com, and you'd have a TXT record pointing at your node's IPNS hash (or an IPFS content hash directly) and you update it by either updating what your node's IPNS hash points to, or by editing the DNS record to point to the latest IPFS content hash.

Now I'm even more confused. I suppose I'll watch a talk on youtube or something. Edit: currently watching this - https://www.youtube.com/watch?v=BA2rHlbB5i0 (10 minutes)

So far we learned that the HTTP web is slow, impermanent and centralized.

This is why it can support billions of people daily in every corner on the planet and have services like https://archive.org/.

Time to move on I guess.

I wonder why do we need an http to IPFS gateway for that video he just uploaded though.

Re: Show HN: A Decentralized StatusPage on IPFS

#118

Earlier quoted context omitted.

This isn't even a well-formed question: IPNS clearly documents what it does do. It provides superior guarantees to cached HTTP. What's more, calling a node fault in a distributed quorum a "replay attack" suggests that application logic is hosted on IPFS. Since it is not and cannot be and redundancy is ultimately the responsibility of the storing agent, this seems like at best a misapplication of the term and at worst…

There is no clear specification of IPNS in the specs repo, never mind documentation in any of the repos I browsed. So no, it doesn't document anything useful to a user or application developer interested in knowing what they have to watch out for, including malicious nodes presenting outdated information. While replay attack might not be exactly the correct terminology (although I think it is), the result is that you…

> This just isn't something you think about if you were using a more traditionally hosted git repository hosted on a trusted developer's server (or someone they trust, etc).

You don't until github accidentally rolls back your content, which they have done.

Unlike the github scenario, particularly popular content will have more than 1 node relaying it so you can form a consensus. It's also the case that only 1 value can be at consensus in the GHT at any given time, so the proper content node is verifiable from many content sources.

Now, do the clients DO this? No. They don't.

But in general this is so far down the list of IPNS concerns as to read odd. They have bigger fixes to make besides concerns about highly visible attacks like this.

Re: Show HN: A Decentralized StatusPage on IPFS

#119
post #73

Earlier quoted context omitted.

Is IPFS infamous for illegal content? My perception was that it's still much too easy to trace the origin of content on IPFS and therefore not suitable for illegal things.

It was used in Spain to host illegal websites organizing Catalonian independence. But yeah, its not a great pick for illegal activities against technically competent governments.

There's not much point in trying to hide what your doing, if what your doing is holding a public vote.

Re: Show HN: A Decentralized StatusPage on IPFS

#120
post #73

Earlier quoted context omitted.

Is IPFS infamous for illegal content? My perception was that it's still much too easy to trace the origin of content on IPFS and therefore not suitable for illegal things.

It was used in Spain to host illegal websites organizing Catalonian independence. But yeah, its not a great pick for illegal activities against technically competent governments.

'illegal'
Post reply on HN