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

91–100 of 130 posts

Re: Show HN: A Decentralized StatusPage on IPFS

#91

Post by StavrosK »

prophesi wrote: post #90
StavrosK wrote: post #81

Earlier quoted context omitted.

It's as much infamous for illegal content as hard disks are. That is, you can choose to host some, but you can also choose not to.

Yeah, it will eventually support having blacklists. So if you get a cease-and-desist letter, you can simply blacklist the offending content. It doesn't completely solve the issue, but it should help mitigate getting into legal trouble with it. For anonymous content, you'd probably have to handle the encryption/decryption yourself and use IPFS as the distribution.

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.

Re: Show HN: A Decentralized StatusPage on IPFS

#92

Post by MattHeard »

book_mentioned wrote: post #37

This is such a natural use case for IPFS that commercial adoption seems inevitable; as first mover you can offer the concierge edition and optionally gain a ton of credibility by open sourcing some of the core bits! It sounds like your marketing will need to explain: 1. How updates work and how you guarantee staying universes away from NSFW/illegal content -- answered separately because nobody wants to find out what…

What do you mean by "concierge edition?"

Re: Show HN: A Decentralized StatusPage on IPFS

#93

Post by KirinDave »

vertex-four wrote: post #79
KirinDave wrote: post #78

Earlier quoted context omitted.

Are you suggesting that IPFS doesn't document the behavior of IPNS?

Indeed I am - can you find me a document which describes whether IPNS is or is not currently vulnerable to replay attacks, in which scenarios its assumptions are broken, and/or best practices for handling any shortcomings of IPNS?

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 a disingenuous scare attempt.

In either event; IPNS is still considered a second tier, less complete that other "beta" parts of the protocol. It's not as experimental as pubflood, but less reliable than pinning.

It's all a moot point anyways, since IPNS is so slow as to be unusable in all but the least interesting cases anyways.

Re: Show HN: A Decentralized StatusPage on IPFS

#94

Post by marknadal »

Big fan of IPFS here, but silly question, isn't a status page suppose to have realtime updates of whether a service is online or not? This doesn't seem like a good fit unless you're using some realtime CRDT adapter on top like they list here https://github.com/ipfs/research-CRDT/blob/master/Readme.MD (disclaimer: I'm the author of https://github.com/amark/gun, which is one of the listed options). The StatusPage link is sparse on info, anybody know how it works underneath? Sorry if I'm confused on how status pages are supposed to work, can it really be static if it is supposed to be reporting services uptime liveliness (and thus requires some type of realtime monitoring)??

Re: Show HN: A Decentralized StatusPage on IPFS

#95

Post by book_mentioned »

StavrosK wrote: post #81
jstanley wrote: post #63

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's as much infamous for illegal content as hard disks are. That is, you can choose to host some, but you can also choose not to.

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.

Re: Show HN: A Decentralized StatusPage on IPFS

#96

Post by joshfraser »

StavrosK wrote: post #91
prophesi wrote: post #90

Earlier quoted context omitted.

Yeah, it will eventually support having blacklists. So if you get a cease-and-desist letter, you can simply blacklist the offending content. It doesn't completely solve the issue, but it should help mitigate getting into legal trouble with it. For anonymous content, you'd probably have to handle the encryption/decryption yourself and use IPFS as the distribution.

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.

Re: Show HN: A Decentralized StatusPage on IPFS

#97

Post by prophesi »

StavrosK wrote: post #91
prophesi wrote: post #90

Earlier quoted context omitted.

Yeah, it will eventually support having blacklists. So if you get a cease-and-desist letter, you can simply blacklist the offending content. It doesn't completely solve the issue, but it should help mitigate getting into legal trouble with it. For anonymous content, you'd probably have to handle the encryption/decryption yourself and use IPFS as the distribution.

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.

Yep, and even the content you've explicitly accessed, it's garbage collected unless you pin it. So that helps further mitigate the issue, in case you mistakenly stumble upon undesirable content.

Re: Show HN: A Decentralized StatusPage on IPFS

#98

Post by stevekemp »

marknadal wrote: post #94

Big fan of IPFS here, but silly question, isn't a status page suppose to have realtime updates of whether a service is online or not? This doesn't seem like a good fit unless you're using some realtime CRDT adapter on top like they list here https://github.com/ipfs/research-CRDT/blob/master/Readme.MD (disclaimer: I'm the author of https://github.com/amark/gun , which is one of the listed options). The StatusPage link…

There seem to be two types of status-pages:

Really great ones show that all services are up, and often have timing information, graphs, or metrics, etc. An example of this would be https://status.bitbucket.org/

More basic status-sites generally only show useful detail(s) if something is currently broken, and perhaps will show you a summary of recent problems over the past few days. An example of that would be https://status.github.com/messages

(I wrote a simple status-page for my own site, but I elected to go the simple route. I do monitor availability and response-time(s) of various parts of the service, but I only update the site when there are problems, manually. This works for me because problems are rare, and my site is small.)

Re: Show HN: A Decentralized StatusPage on IPFS

#99

Post by marknadal »

stevekemp wrote: post #98
marknadal wrote: post #94

Big fan of IPFS here, but silly question, isn't a status page suppose to have realtime updates of whether a service is online or not? This doesn't seem like a good fit unless you're using some realtime CRDT adapter on top like they list here https://github.com/ipfs/research-CRDT/blob/master/Readme.MD (disclaimer: I'm the author of https://github.com/amark/gun , which is one of the listed options). The StatusPage link…

There seem to be two types of status-pages: Really great ones show that all services are up, and often have timing information, graphs, or metrics, etc. An example of this would be https://status.bitbucket.org/ More basic status-sites generally only show useful detail(s) if something is currently broken, and perhaps will show you a summary of recent problems over the past few days. An example of that would be https:/…

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.

Re: Show HN: A Decentralized StatusPage on IPFS

#100

Post by stevekemp »

marknadal wrote: post #99
stevekemp wrote: post #98

Earlier quoted context omitted.

There seem to be two types of status-pages: Really great ones show that all services are up, and often have timing information, graphs, or metrics, etc. An example of this would be https://status.bitbucket.org/ More basic status-sites generally only show useful detail(s) if something is currently broken, and perhaps will show you a summary of recent problems over the past few days. An example of that would be https:/…

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

Post reply on HN