Live data from Hacker News

Show HN: Hearth – A Dropbox-like, IPFS-powered personal website publisher

hearth.eternum.io

81–90 of 106 posts

Re: Show HN: Hearth – A Dropbox-like, IPFS-powered personal website publisher

#81
post #77

Never having used or looked into Beaker, dat, ipfs, etc, some immediate questions about security implications come to mind: 1) Someone accesses your "site" directly on your computer via ipfs/dat whatever it is. This is static content I guess? And it's like your computer is just running a static webserver (kinda/sorta? if not, or something more dynamic please advise). So, are there security implications here? Is there…

> 1) Someone accesses your "site" directly on your computer via ipfs/dat whatever it is. This is static content I guess? And it's like your computer is just running a static webserver (kinda/sorta? It's like static content served by bittorrent. The content might be served directly by your computer, or by other nodes in the ipfs/dat network which are caching your content. > So, are there security implications here? Is…

> It's pretty much the same security model as regular web content, as you mention.

I can't say much about IPFS, but this is not quite true of Dat. The Beaker team is working on a complementary set of APIs to read and write to Dat archives, so you could have, say, a TiddlyWiki-like site that can update itself.

It's always been a big problem that the security of file:// URIs is unstandardized. I can publish a repo, for example, that includes some tests/runner.html. You could open it Firefox to run the automated tests, but Chrome will choke on it because Chrome doesn't allow XHR for file:// URIs. The only way around this is to either put it online or run a local webserver (e.g., `python -m SimpleHTTPServer`) and access it through localhost. This is perverse. Dat is solving this in a way that's very similar to what would happen if file:// got first-class attention from the browser makers. If it's in a Dat, it doesn't actually matter if it's on your computer or hosted somewhere. All that matters is that you have the content.

This might not be exciting to HN types who are comfortable and willing to go rent some DigitalOcean instance and put up with administering it, but this will have a huge impact on the long tail of businesses—both small and large—that are quietly chugging along on little more than Excel and email (maybe the odd SharePoint installation).

On the other hand, developers should be excited about this, too, because it means they can start building apps that are _actually_ serverless (compared to Amazon and Google's definition). We're back to where we were in the 90s: you can go write some neat client software and share it with me, without having to think about the headache of needing to run a server in perpetuity just so that it can continue being useful.

Re: Show HN: Hearth – A Dropbox-like, IPFS-powered personal website publisher

#82

Earlier quoted context omitted.

How is this not another silo? A big one called "IPFS"

You're making a category error. IPFS (and friends—like Dat) are analogous to HTTP. Would you call HTTP a silo? No; services like Facebook and Google Drive are silo-y, but HTTP is not. The people working on the P2P web are just trying to make some design choices at the protocol level that facilitates its use in a more decentralized way than the services that HTTP has encouraged to flourish.

Content under HTTP can be thought of as siloed if the user doesn't have an HTTP client. Same effect no?

Re: Show HN: Hearth – A Dropbox-like, IPFS-powered personal website publisher

#83

Never having used or looked into Beaker, dat, ipfs, etc, some immediate questions about security implications come to mind: 1) Someone accesses your "site" directly on your computer via ipfs/dat whatever it is. This is static content I guess? And it's like your computer is just running a static webserver (kinda/sorta? if not, or something more dynamic please advise). So, are there security implications here? Is there…

1) Yep, exactly. There shouldn't be security implications, as long as the IPFS daemon is secure. 2) Again, as long as the IPFS daemon is secure, standard security practices apply. It's just static files. 3) It's all just static files. You get linked to from other files. Same as you navigate the rest of the web. It's not hard to wrap your head around it, really, just imagine that the web was all static files. That's i…

For number 3 literally the web 20( 30?) years ago

Re: Show HN: Hearth – A Dropbox-like, IPFS-powered personal website publisher

#84

Earlier quoted context omitted.

1) Yep, exactly. There shouldn't be security implications, as long as the IPFS daemon is secure. 2) Again, as long as the IPFS daemon is secure, standard security practices apply. It's just static files. 3) It's all just static files. You get linked to from other files. Same as you navigate the rest of the web. It's not hard to wrap your head around it, really, just imagine that the web was all static files. That's i…

For number 3 literally the web 20( 30?) years ago

We definitely had dynamic websites in 1998, guestbooks, forums, etc. Mostly via CGI. But yes, it's very close to that.

Re: Show HN: Hearth – A Dropbox-like, IPFS-powered personal website publisher

#85
post #70

Earlier quoted context omitted.

The content becomes a part of the problem when it is liable to spread the "disease" (to continue the allegory). I get the feeling we're discussing this on differing levels of severity, here. I'm not talking about dissenting political opinions or pseudoscience or conspiracy theories or counter-culture or drugs or anything silly like that, but things more impactful and corrosive to humanity. The persistence of certain…

Comparing wrongthink to disease has a sorry history. If you don't want to see bad things on IPFS, don't access them. If you wish to force other people to not see them either, the process is similar to anything else on the Internet. There's no need for moral panic.

Who's panicking?

I was posing the question as to how the community could deal with something horrific. At this point in time the power is in the hands of the community developing the technology. Surely there were lessons to learn from the implementation of the web.

I posed it again because each time there is no discussing potential for improvement and only responses crying censorship with pseudo-Orwellian lingo.

There's a line someplace. Nobody is preemptively stopped from producing snuff, but we don't support it by allowing it to be stocked at the local library in the name of anti-censorship.

Re: Show HN: Hearth – A Dropbox-like, IPFS-powered personal website publisher

#86
post #77

Earlier quoted context omitted.

> 1) Someone accesses your "site" directly on your computer via ipfs/dat whatever it is. This is static content I guess? And it's like your computer is just running a static webserver (kinda/sorta? It's like static content served by bittorrent. The content might be served directly by your computer, or by other nodes in the ipfs/dat network which are caching your content. > So, are there security implications here? Is…

> It's pretty much the same security model as regular web content, as you mention. I can't say much about IPFS, but this is not quite true of Dat. The Beaker team is working on a complementary set of APIs to read and write to Dat archives, so you could have, say, a TiddlyWiki-like site that can update itself. It's always been a big problem that the security of file:// URIs is unstandardized. I can publish a repo, for…

I completely agree that the file access APIs in Beaker are extremely cool, and solve a real developer problem.

From a security point of view, it does slightly expand the attack surface, since there could be a vulnerability in that code which isn't present in other browsers. But given the simplicity of the APIs, I think it's a very acceptable risk given the benefits.

The biggest downside IMO of these additional APIs is that they only work in Beaker. If I were the Beaker team I would prioritize making them available to mainstream browsers in some way: javascript library, browser extension, webassembly... It would really help adoption if they found a way to do that.

Re: Show HN: Hearth – A Dropbox-like, IPFS-powered personal website publisher

#87
post #77

Earlier quoted context omitted.

> 1) Someone accesses your "site" directly on your computer via ipfs/dat whatever it is. This is static content I guess? And it's like your computer is just running a static webserver (kinda/sorta? It's like static content served by bittorrent. The content might be served directly by your computer, or by other nodes in the ipfs/dat network which are caching your content. > So, are there security implications here? Is…

> It's pretty much the same security model as regular web content, as you mention. I can't say much about IPFS, but this is not quite true of Dat. The Beaker team is working on a complementary set of APIs to read and write to Dat archives, so you could have, say, a TiddlyWiki-like site that can update itself. It's always been a big problem that the security of file:// URIs is unstandardized. I can publish a repo, for…

I'm not getting this. Fine if you want to go back to the early 90s when sites were all static but what does this model offer for dynamic sites and in particular sites which are intended to scale beyond a single, home user box? How do I migrate my Rails app to dat/ipfs?

Re: Show HN: Hearth – A Dropbox-like, IPFS-powered personal website publisher

#88
post #77

Earlier quoted context omitted.

> 1) Someone accesses your "site" directly on your computer via ipfs/dat whatever it is. This is static content I guess? And it's like your computer is just running a static webserver (kinda/sorta? It's like static content served by bittorrent. The content might be served directly by your computer, or by other nodes in the ipfs/dat network which are caching your content. > So, are there security implications here? Is…

> It's pretty much the same security model as regular web content, as you mention. I can't say much about IPFS, but this is not quite true of Dat. The Beaker team is working on a complementary set of APIs to read and write to Dat archives, so you could have, say, a TiddlyWiki-like site that can update itself. It's always been a big problem that the security of file:// URIs is unstandardized. I can publish a repo, for…

No, you still need to host it yourself or pay somebody else to, otherwise it still has a chance of dissappearing... but I agree that it's much close to the literal interpretation of "serverless" (I personally don't mind the term because it seems rather defined at this point - an idiomatic label)

Re: Show HN: Hearth – A Dropbox-like, IPFS-powered personal website publisher

#89
post #67

Earlier quoted context omitted.

IPFS

IPFS doesn't actually distribute hosting unless someone else goes through the trouble of doing pinning. Some gateways may keep local copies but they're also free to destroy local copies. In the typical deployment where nodes refer to their own local IPFS services, it's often the case that the primary IPFS pin serves the majority of traffic. If we're going to call that "distributed" then so are normal webpages with ra…

We call bittorrent distributed, I think IFPS counts too.

Re: Show HN: Hearth – A Dropbox-like, IPFS-powered personal website publisher

#90
post #36

Earlier quoted context omitted.

Please elucidate the timing. Your link redirects to twitter, and I can't find anything about it following links to the https://oswg.oftn.org/ or on your own website. So it looks completely non-existent, which makes me skeptical of "soon"

It's described in the first tweet on that twitter link. It will be out this year.

Your first twwet is what makes everybody skeptical. Your post here makes it sound like you're just polishing things up. Your tweet makes it sounds like it might not have even started.
Post reply on HN