Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: A Decentralized StatusPage on IPFS

dstatuspage.net

Post reply on HN
Print view View original

121–130 of 130 posts

Re: Show HN: A Decentralized StatusPage on IPFS

#121

Post by book_mentioned »

AgentME wrote: post #107
book_mentioned wrote: post #95

Earlier quoted context omitted.

All content received is automagically re-distributed by default, correct? It is similar to BitTorrent in this regard; very different from the more common client/server paradigm. I will have to do a bit more research to see how the default clients handle caching popular, unrequested content.

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…

>> All content received is automagically re-distributed by default

> you only host [...] things that you have recently requested

Thank you for taking the time to correct my misunderstanding, but is this not restating what I wrote?

Or are you rejecting the other portion of the comment discussing caching popular content (never requested/received)?

Re: Show HN: A Decentralized StatusPage on IPFS

#122

Post by alexeldeib »

letlambda wrote: post #119
013a wrote: post #73

Earlier quoted context omitted.

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.

You have it somewhat backwards -- they wanted to get the word out, and the government had been suppressing discussion actively. They used IPFS to circumvent that.

Re: Show HN: A Decentralized StatusPage on IPFS

#123

Post by tscs37 »

atrus wrote: post #113
joshfraser wrote: post #96

Earlier quoted context omitted.

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.

And who can assure that these blacklists won't be manipulated for someone's gain? Ie, surpressing activity they don't like on the network?

Re: Show HN: A Decentralized StatusPage on IPFS

#124

Post by snissn »

stevekemp wrote: post #100
marknadal wrote: post #99

Earlier quoted context omitted.

Thank you for these links! So... This still seems problematic though - if you manually update it, then the hash of the page is going to change, and then you'd need to retrieve a different IPFS item than the original status page. And so on... No? This just seems like an odd loop.

When I manually update my site, that just means I add a file to the git-repository with today's date. Once I commit and push that a Makefile rebuilds my (static) site. I don't personally use IPFS, but I imagine if I did then I'd have a script to change DNS, or update the hash IPFS uses. I see from other replies that updating the "most recent" version of a site is simple enough that it shouldn't be a problem in practi…

ipfs works by creating a URL based on the hash of the content that you're publishing. so ipfs.io/hash(MYSITEISDOWN) vs ipfs.io/hash(MYSITEISUP)

Re: Show HN: A Decentralized StatusPage on IPFS

#125

Post by AgentME »

book_mentioned wrote: post #121
AgentME wrote: post #107

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…

>> All content received is automagically re-distributed by default > you only host [...] things that you have recently requested Thank you for taking the time to correct my misunderstanding, but is this not restating what I wrote? Or are you rejecting the other portion of the comment discussing caching popular content (never requested/received)?

Oh, I just realized I missed the word "received" in your first sentence! I don't have much to add to how you actually worded the sentence.

I think the automatic re-sharing of recently requested content is only for a short time period (elsewhere someone mentions 30 minutes). Probably not anything anyone should rely much on; it just sounds like a bonus to maybe soften the blow a little bit if you get a lot of activity suddenly.

Re: Show HN: A Decentralized StatusPage on IPFS

#126

Post by kakarot »

kodablah wrote: post #109
AgentME wrote: post #107

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

Willing to bet that guy didn't read the docs, maybe this is a public relations issue.

Re: Show HN: A Decentralized StatusPage on IPFS

#127

Post by diggan »

snow_mac wrote: post #103
diggan wrote: post #64

Earlier quoted context omitted.

Thanks! We're hard at work making everything better, especially the documentation and examples bit, but lots of work on the APIs as well. If you have anything concrete to suggest or help out with, please open up a issue in the relevant repository, this would be the entrypoint to find your way around in our Github organization: https://github.com/ipfs/ipfs Disclaimer: I work for Protocol Labs on IPFS

I want to contribute, experienced senior web dev. Where do I get started?

Jump into #ipfs on freenode (IRC) and tell us what area you want to contribute to and someone can point you in the right direction.

Otherwise, assuming you know JavaScript, https://github.com/ipfs/js-ipfs/issues?q=is%3Aopen+is%3Aissu... is a great place to start.

If you have some Golang experience, https://github.com/ipfs/go-ipfs/issues?q=is%3Aopen+is%3Aissu... should work to find you some beginner issues.

Re: Show HN: A Decentralized StatusPage on IPFS

#128

Post by RainaRelanah »

StreamBright wrote: post #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…

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

This can easily be addressed by choosing hosts which have gigabit upload links if you are hosting high demand files. Personal computer backups may opt for hosts with 10mbit upload that offer much cheaper storage. It may not be possible to do so atm, but eventually the platforms will get there. It's still very early and most distributed storage technologies are nowhere near complete.

Re: Show HN: A Decentralized StatusPage on IPFS

#129

Post by KirinDave »

prophesi wrote: post #102
KirinDave wrote: post #67

Earlier quoted context omitted.

Why is this desirable? IPFS nodes don't really rehost content for any substantial period of time (especially the gateway) so you're still stuck with some major problems: 1. You're still hosting off your IPFS node. This isn't worse, but it isn't better. You need to have a node and it needs to have connectivity. 2. IPNS resolution is glacial and it's a known issue without resolution currently. So any gateway trying to…

1. They're hoping that FileCoin will resolve that issue. Akin to Storj and Siacoin, people will offer to host (aka pin) content on their IPFS gateway node in return for FileCoins, and the market will decide the price. 2. In the meantime, you can set up a script to update your DNS TXT record to point to the most recent IPFS hash. I've got a static site generator that does this upon the completion of a build.

It's really too bad that anyone still thinks FileCoin is not a deeply flawed (if not outright scammy) endeavor. The only reason it isn't more widely decried is that the IPFS folks have a lot of goodwill in the community.

But it's a bad coin.

As for your #2, I don't use this solution because of propagation times. Instead, I use an nginx proxy that rewrites incoming requests on a specific path to root on IPFS node. When I rebuild, I rebuild that site config there.

But tbh, I'm going to undo that. I get absolutely nothing for being part of IPFS and there's effectively no reason to host content there. It's a DHT and while that's cool, it's actually substantially less efficient than alternatives.

I've been enthusiastic about IPFS because it's a neat white paper, but after using it for months I've concluded it's a tech demo with no real direction to go other than a deeply flawed cryptocurrency.

Re: Show HN: A Decentralized StatusPage on IPFS

#130

Post by creatonez »

icebraining wrote: post #42
wybiral wrote: post #38

Earlier quoted context omitted.

Yeah, the nodes connect via IP addresses. You could proxy it through Tor or something though.

As far as I understand it, proxying it is dangerous because IPFS will announce all your IPs so that the shortest routes can be established. You probably need to run it in a VM/container that only has access to Tor and no other network adapter.

It's pretty easy to configure ipfs to not advertise internal IP addresses.

Though it really should be the default behavior.

Post reply on HN