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

How We Made IPFS Content Publishing 10x Faster

probelab.io

Post reply on HN
Print view View original

51–60 of 69 posts

Re: How We Made IPFS Content Publishing 10x Faster

#51

Post by phae »

boramalper wrote: post #12

Is anyone still (or has anyone ever) used IPFS in production? I’m not talking about technology demos such as Wikipedia-on-IPFS (which indeed worked and was impressive) but where IPFS is actually being relied on for some functionality.

the thing that prevented me using ipfs in anger.. (granted i may not have looked hard enough) was that i couldn't have stuff in ipfs, and access it via posix filesystem at he same time. i'd have to store things twice.

fine for publishing, but not for having a live data set that is both used and published at the same time, as you can do with torrent.

Re: How We Made IPFS Content Publishing 10x Faster

#52

Post by OneDeuxTriSeiGo »

boramalper wrote: post #12

Is anyone still (or has anyone ever) used IPFS in production? I’m not talking about technology demos such as Wikipedia-on-IPFS (which indeed worked and was impressive) but where IPFS is actually being relied on for some functionality.

It's not literally IPFS but atproto/bluesky is using most of the bones of IPFS (IPLD) to do their entire data propagation and event broadcasting.

And tbh it shouldn't be terribly difficult to extend the existing infra to supporting a full IPFS based system but I don't think anybody has considered it worthwhile yet.

ATproto uses just the bits it immediately needs even if it could probably benefit from the other parts long term (ex for archival relay stream preservation).

Re: How We Made IPFS Content Publishing 10x Faster

#53

Post by charcircuit »

Gigachad wrote: post #45
topgrain2 wrote: post #30

Earlier quoted context omitted.

The idea of simply mounting a filesystem and selecting from a list of titles which roms to download and add to your local games, unloading them and transparently re-downloading when you need to free up space, all without relying on a centralized host even for the file index, is pretty appealing. You can do similar things with torrents but it's not quite as "natural". Most of the emulator frontends I've seen are prett…

It's because that crosses the line of plausibly legal. In theory you could use an emulator with only titles you copied from your own physical copies which is legal. But if they implement a download mechanism it's clearly illegal. At any rate you can replicate the same thing by just hosting the ROMs on your own cloud storage and using something like macos virtual files which will do this transprent download/delete to…

>your own physical copies which is legal

You can make an archival copy, but it is copyright infringement to use that copy in an emulator.

For newer console generations (decrypted) backups are not legal due to needing DRM circumvention.

Re: How We Made IPFS Content Publishing 10x Faster

#54

Post by [deleted] »

topgrain2 wrote: post #30
boramalper wrote: post #21

Earlier quoted context omitted.

And why would you do that? As opposed to, say, distributing via BitTorrent or serving them using a good-old HTTP server? edit: Not opposed to the idea, just curious what makes you pick IPFS over the existing alternatives.

The idea of simply mounting a filesystem and selecting from a list of titles which roms to download and add to your local games, unloading them and transparently re-downloading when you need to free up space, all without relying on a centralized host even for the file index, is pretty appealing. You can do similar things with torrents but it's not quite as "natural". Most of the emulator frontends I've seen are prett…

[deleted]

Re: How We Made IPFS Content Publishing 10x Faster

#58

Post by boramalper »

Gigachad wrote: post #44
ValdikSS wrote: post #43

Earlier quoted context omitted.

IPFS (at least initially) was designed to be a BitTorrent replacement, a new version of it, which you can use not only with a special software, but also via HTTP and also directly inside the browser. It basically works as BitTorrent, but also provides HTTP access to the files. In fact, many pirate websites use IPFS in one way or another (either directly, by serving the downloads over one of the public gateway, or ind…

Couldn't you also just build a bittorrent client that hosts a local webserver to provide http access? I could never get what IPFS actually did that bittorrent didn't.

> Couldn't you also just build a bittorrent client that hosts a local webserver to provide http access?

And this does exist! See confluence by anacrolix:

https://github.com/anacrolix/confluence

Re: How We Made IPFS Content Publishing 10x Faster

#59

Post by bergie »

boramalper wrote: post #12

Is anyone still (or has anyone ever) used IPFS in production? I’m not talking about technology demos such as Wikipedia-on-IPFS (which indeed worked and was impressive) but where IPFS is actually being relied on for some functionality.

Back when I was working at a website builder, we used IPFS for distributing content between our serving clusters.

If also made the sites available on IPFS, but that was a secondary concern.

Re: How We Made IPFS Content Publishing 10x Faster

#60

Post by [deleted] »

boramalper wrote: post #32
ydj wrote: post #26

Earlier quoted context omitted.

At meta, there was a project for delivering binaries of internally built libraries / binaries to dev laptops using a private ipfs network. This was live for at least some period of time.

Very interesting! I wonder if it’s still live and there is any writing on it?

[deleted]
Post reply on HN