Live data from Hacker News

IPFS Project Roadmap

github.com

11–20 of 154 posts

Re: IPFS Project Roadmap

#11
I've been considering Swarm distributed file system because of its closeness with the Ethereum development.

It seems to do the same thing and works already but hardly gets any press. IPFS and the Protocol Lab's Filecoin sale seemed to generate a lot of marketing despite it becoming clearer later that Filecoin is for an unrelated incentivized network.

It is hard understand the pros and cons of choosing to use IPFS over Swarm, or where they are in comparative development cycle.

I know many decentralized applications that opt for IPFS for their storage component, and know of the libraries to help different software stacks with that. But I can't tell if it is right for me, versus the state of Swarm.

Re: IPFS Project Roadmap

#12
post #4

The vision of a IPFS-powered web working is beautiful. However I would love to see a reference implementation that works at minimum and not just drains out your computer up to latest resource it may have. If we're so near the "production-ready" status of the reference implementations then I think that goal will never be achieved.

[deleted]

Re: IPFS Project Roadmap

#13
post #6
post #4

The vision of a IPFS-powered web working is beautiful. However I would love to see a reference implementation that works at minimum and not just drains out your computer up to latest resource it may have. If we're so near the "production-ready" status of the reference implementations then I think that goal will never be achieved.

I see this comment often when IPFS is discussed - but the devil is in the details when it comes to replacing the underlying tech of "the web" with something else. How does an IPFS powered website do dynamic content? User sessions? Is all the client's session data encoded in the IPFS address itself? Even if there's no user sessions, but the page content updates, how do you continuously point clients to fetch the right…

For dynamic data, you need to use a CRDT system like GUN ( https://github.com/amark/gun ).

For instance, see P2P Reddit ( http://notabug.io ) which:

- Running in production with GUN.

- Handling about 42,000 monthly visitors. ( https://www.similarweb.com/website/notabug.io )

- Has done ~1TB in 1 day of decentralized traffic.

You can then configure GUN to save to IPFS as the blob/storage engine (or we have filesystem, localStorage, IndexedDB, S3, etc. as options).

It is basically like having a P2P Firebase :) with IPFS plugin.

Re: IPFS Project Roadmap

#14
post #6
post #4

The vision of a IPFS-powered web working is beautiful. However I would love to see a reference implementation that works at minimum and not just drains out your computer up to latest resource it may have. If we're so near the "production-ready" status of the reference implementations then I think that goal will never be achieved.

I see this comment often when IPFS is discussed - but the devil is in the details when it comes to replacing the underlying tech of "the web" with something else. How does an IPFS powered website do dynamic content? User sessions? Is all the client's session data encoded in the IPFS address itself? Even if there's no user sessions, but the page content updates, how do you continuously point clients to fetch the right…

> how would you implement a Hacker News style aggregator that updates every minute

AIUI, that's the problem that IPNS is designed to solve (https://github.com/ipfs/specs/blob/master/naming/README.md#i...). HN controls its private key, enabling it to be the only one who can update the record at the signature of its public key, and those IPNS records have nanosecond precision expiry timestamps and TTLs, meaning they can update at the frequency of their choice

I agree with the sibling comments that (at least as the IPFS is currently specified) having a user session would be problematic. It's theoretically possible that _your_ HN front page would have an IPNS record of IPFS://mdaniel.news.ycombinator.com and then we're back to the aforementioned expiry semantics. Upvotes would have to travel out of the IPFS network, but in some sense, I think that's expected since one wouldn't want an upvote to be archived, but rather the resulting content to be

There are a ton of weird perspective changes when thinking about the content addressable web, but it might not be the 2050-esque far away that it seems

Re: IPFS Project Roadmap

#15
post #5
post #4

The vision of a IPFS-powered web working is beautiful. However I would love to see a reference implementation that works at minimum and not just drains out your computer up to latest resource it may have. If we're so near the "production-ready" status of the reference implementations then I think that goal will never be achieved.

That's what's got me excited - they've managed to articulate a vision for the future that I'm totally on board with: decentralized, privacy respecting, and user owned. I really want to see that vision become a reality.

it is already here! If you use a mix of SSB, GUN, DAT, IPFS, & WebTorrent.

SSB = Social-like P2P data.

GUN = Firebase-like P2P data.

SEA = End-to-end encryption. ( https://gun.eco/docs/SEA )

DAT = GIT-like P2P data.

IPFS = Images/assets.

WebTorrent = Video-like P2P data.

Re: IPFS Project Roadmap

#17
post #5
post #4

The vision of a IPFS-powered web working is beautiful. However I would love to see a reference implementation that works at minimum and not just drains out your computer up to latest resource it may have. If we're so near the "production-ready" status of the reference implementations then I think that goal will never be achieved.

That's what's got me excited - they've managed to articulate a vision for the future that I'm totally on board with: decentralized, privacy respecting, and user owned. I really want to see that vision become a reality.

For the internet to be truly decentralized, it needs to be so at the physical connectivity layer as well.

Perhaps a worldwide swarm of drones creating a mesh network.

Re: IPFS Project Roadmap

#18
"2019 Goal: The most used code and binary Package Managers are powered by IPFS."

That's kind of stupid-ambitious for 2019 when another 2019 goal is "a production-ready implementation" and IPFS has been around for 3 years already.

This isn't a roadmap, it's a wishlist. And I'm someone who wants to see IPFS succeed.

Re: IPFS Project Roadmap

#20

I love the idea of IPFS, but I can't think of a use case not covered by torrents. Would someone mind enlightening me regarding what sets IPFS apart from torrents?

Main feature is automatic data-sharing between distributions. With torrents, everything is siloed, and data is only exchanged between peers of that torrent. IPFS doesn't care /why/ you're getting information or the link you found it from, just that it can find it by its hash.

Say you distribute "Julie's Webcast Complete Series" and somebody else distributes "Julie's Webcast - Episode 3, with Russian subtitles," peers and seeders from both distributions can share data for the shared content. Similarly, updating a dataset only requires downloading the new data.

This is done automatically, both per-file hashing and (optionally, not sure the current state) of in-file block hashing.

Post reply on HN