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

51–60 of 130 posts

Re: Show HN: A Decentralized StatusPage on IPFS

#51

Post by carussell »

NickBusey wrote: post #40

I'm not sure this is actually Decentralized. I have been playing with IPFS quite a bit recently, and this looks to host the content on one node. That node goes away, your content goes away. You need more than one nodes 'pinning' the same content in order to actually be decentralized, and as far as I can tell this project doesn't provide that functionality. That has been my biggest drawback so far with IPFS, there isn…

The Dat project, which is somewhat similar to IPFS, and the people behind Beaker have addressed these things. So you can have a site like dat://9900f9aad4d6e79e0beb1c46333852b99829e4dfcdfa9b690eeeab3c367c1b9a/ or you can access the same thing as dat://fritter.hashbase.io using DNS-over-HTTPS for Dat (which is a mouthful, so I've been calling it DSN [Dat Short Names] instead). TTL is controlled by the publisher, just like with DNS. The main downside with the current incarnation is that while the content network itself is decentralized, short name resolution is not, since it's bootstrapped from the traditional DNS/HTTPS infrastructure for now. Which means the short name works only so long as the publisher continues responding.

Beaker is a web browser for Dat sites. The 0.8 release is supposed to happen sometime in the next month, I think. The same team set up hashbase.io to make it trivial to create a short name for a Dat site, and so that you can have Hashbase act as a fallback superpeer/permaseed for your content.

Re: Show HN: A Decentralized StatusPage on IPFS

#52

Post by book_mentioned »

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…

Competing on price is a mistake for enterprise customers, they want to pay more. Saying this option is cheaper counts against it.

Make it as reliable as IPFS claims it can be (this has to work in the real world!), and as easy to use as a Twitter account, then market that combo.

Look at the competition for pricing ideas, and charge more since your offering delivers.

Re: Show HN: A Decentralized StatusPage on IPFS

#53

Post by yorwba »

vertex-four wrote: post #46
paulogr wrote: post #9

Earlier quoted context omitted.

IPFS has a so called IPNS system that use mutable hashes. So when you publish using this piece of software you got always a permanent link to share with your users.

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.

Not if the page itself contains the time it was last updated (IMO all status pages should have this, IPFS or not). Then you could still get outdated information, but you'd be able to tell.

Re: Show HN: A Decentralized StatusPage on IPFS

#54

Post by Spearchucker »

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.

I think his point is that the existence of a SPOF obviates the need for distribution.

Re: Show HN: A Decentralized StatusPage on IPFS

#55

Post by diggan »

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

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 use case in the end.

Disclaimer: I work for Protocol Labs on IPFS

Re: Show HN: A Decentralized StatusPage on IPFS

#56

Post by diggan »

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.

> announce all your IPs

That's configurable. Check the format for the config here: https://github.com/ipfs/go-ipfs/blob/master/docs/config.md#a...

Keyword being `Announce` and `NoAnnounce`

Re: Show HN: A Decentralized StatusPage on IPFS

#57

Post by sudhirj »

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

If I understand correctly, you still need a gateway VPS to proxy the ipfs site out to the internet over http. Isn't this a single point of failure, as your gateway server will be pegged. Or am I misunderstanding the implementation? You could have a VPS in multiple regions, but we're back at square one.

Anybody can gateway the entire IPFS network, so not really. The officially maintained gateway is just one gateway. If you don’t want to rely on it, can run your own.

Re: Show HN: A Decentralized StatusPage on IPFS

#58

Post by diggan »

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

If I understand correctly, you still need a gateway VPS to proxy the ipfs site out to the internet over http. Isn't this a single point of failure, as your gateway server will be pegged. Or am I misunderstanding the implementation? You could have a VPS in multiple regions, but we're back at square one.

There is at least two ways of fixing this. First one is that browsers implements IPFS, and reshares the website when you visit it.

Second would be for paulogr to include js-ipfs in the webpage, so when users visits the page, they also reshare the website (if there is enough resources/not on battery/$other_criteria). Users would send the data for the website in-between them, just verify the data's signature.

Disclaimer: I work for Protocol Labs on IPFS

Re: Show HN: A Decentralized StatusPage on IPFS

#59

Post by andyjohnson0 »

yorwba wrote: post #53
vertex-four wrote: post #46

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.

Not if the page itself contains the time it was last updated (IMO all status pages should have this, IPFS or not). Then you could still get outdated information, but you'd be able to tell.

Even with a last update time on the page, how would you know whether that was really the latest update? You'd also need to know the update schedule.

Re: Show HN: A Decentralized StatusPage on IPFS

#60

Post by jstanley »

foxhop wrote: post #31
jstanley wrote: post #22

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.

Each time the page is updated, the TXT record would need to be modified with the latest IPNS hash?

No, if you put an IPNS hash in the TXT record you just update your IPFS node.

If you put an IPFS hash in the TXT record then you need to update that every time. I personally do this (domain name jes.xxx) because it means you don't need to leave your IPFS node running constantly in order for your IPNS name to be resolvable.

The record is:

    jes.xxx.		300	IN	TXT	"dnslink=Qme12vJPtMpeUwmG2NLG11Q47jy2unSonegNJxQb9QgYax"
And I have a small shell script to update it automatically.
Post reply on HN