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

101–110 of 130 posts

Re: Show HN: A Decentralized StatusPage on IPFS

#101

Post by book_mentioned »

MattHeard wrote: post #92
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?"

I was going to link to ZoneEdit but apparently post-aquisition it has been concierge-d. Maybe NearlyFreeSpeech is a good non-cierge example.

I think another contrast is Heroku vs AWS.

Re: Show HN: A Decentralized StatusPage on IPFS

#102

Post by prophesi »

KirinDave wrote: post #67
paulogr wrote: post #2

One of the main problems while I was researching about status page services and saw many having the same doubts here was about where to deploy the status page. Besides this market has a lot of players even the biggest one had problem when the big S3 outage happened last year (see ref-1). What about do not depend on a centralized infrastructure to deploy you status page and kept always alive? This project aims to depl…

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.

Re: Show HN: A Decentralized StatusPage on IPFS

#103

Post by snow_mac »

diggan wrote: post #64
wybiral wrote: post #45

Earlier quoted context omitted.

Ah, good to know. I love the idea behind IPFS but it just doesn't feel mature enough yet. The documentation, examples, consistent APIs, etc, don't seem very solidified.

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?

Re: Show HN: A Decentralized StatusPage on IPFS

#104

Post by jstanley »

sp332 wrote: post #49
survivaletc wrote: post #16

I love that the background image is a schematic of a centralized network. Look at that single point of failure! ^^ https://www.dstatuspage.net/decentralized.png

In a tree, any node can be chosen as the "root". That means any non-leaf node is a SPOF.

But it should be a DAG instead of a tree.

Re: Show HN: A Decentralized StatusPage on IPFS

#105

Post by johnmw »

diggan wrote: post #55
CapacitorSet wrote: post #11

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.

The slowness of IPNS is something we're actively working on. Currently we have fixed so resolutions are faster after the first lookup, by using the libp2p feature pubsub. It being faster/slower than DNS depends on your case, but if you're close to the next node, it'll probably be faster. If you're offline, DNS won't work at all :) We also have more fixes for IPNS in general that will come soon. So, depends on your us…

First, thanks for your work on IPFS.

I've been trying to get into IPFS recently. One thing I can't wrap my head around is that IPNS only seems to persist for about 12 hours and then stops working.

It seems to defeat the purpose of a truely distributed name system, as my computer that needs to keep republishing the name becomes a critical part of the system?

Am I missing something or are there plans to resolve this in the future?

Re: Show HN: A Decentralized StatusPage on IPFS

#106

Post by gone35 »

rhn_mk1 wrote: post #8

One thing I'm missing (or misunderstanding) about IPFS is updates. In a centralized system, like HTTP, a site has a single address: something.example.com. Any new entry (e.g. blog post) I create gets its own entry address, but is also referenced from the main site address. As far as I understand, IPFS contains static copies of documents, so any document that would be the "front" page would have to be copied before up…

Not a network person by any means, but I think that this points out to what I think is the fatal flaw of IPFS: the apparent "one-wayness" of addresses to content.

Yes, I know that is supposed to be its main feature, but (again, naïvely speaking) it seems to induce a huge, possibly even intractable overhead... Think of, say, programming in C without being allowed to ever rewrite memory contents, or change what a pointer points to!

Again, not an expert; and I'm sure with all the money they raised, people with actual technical expertise in network protocols are hard at work on this and can vouch for the design... But I'm curious anyway how this is not an obvious dealbrealer, given the extreme latency requirements in networking..

Re: Show HN: A Decentralized StatusPage on IPFS

#107

Post by AgentME »

book_mentioned wrote: post #95
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.

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 ipfs presents itself, because I see this misconception (that just running ipfs causes you to host anything) often.

Re: Show HN: A Decentralized StatusPage on IPFS

#109

Post by kodablah »

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…

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

Re: Show HN: A Decentralized StatusPage on IPFS

#110

Post by vertex-four »

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

Earlier quoted context omitted.

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…

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 cannot trust any information pointed to by an IPNS record to be up to date. There's fairly trivial attacks I can think of that revolve around this - for example, if a git repository is hosted in IPFS with an IPNS record linking to it, you might actually get an older version of the code with known security flaws. 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).

Post reply on HN