Live data from Hacker News

IPFS 0.5

blog.ipfs.io

81–90 of 145 posts

Re: IPFS 0.5

#81
post #41
post #18

Earlier quoted context omitted.

C or Rust would be perfect. No GC runtime, no name mangling, fast, great ffi story. Rust needs to start edging out Go for new tools. Kubernetes, Envoy, IPFS, etc. would have benefitted from it. It might not have been time four years ago, but it's time now.

Rust will start edging out Go once Rust becomes easier than Go to prototype/start projects. Rust is a great language, but right now I can start a project in Go and have someone else start a project in Go and have something up and working in a week. Rust still takes significantly longer to learn and/or find skilled developers for. Go is up there with Python in terms of "Get something out now ".

And therefore Rust will never outcompete Go in this regard in as much as Haskell, Ocaml, ... never overtook C. Rust might draw from the better principles and get things right C, C++, D, Go, ... failed to incorporate. But in order to get things done a company has to source developers from a market and consider that developers get replaced by another, taking over.

Even in a globalized developer market a smaller developer force is a risk.

In German we have a saying "to die in beauty" (in Schönheit sterben), does that translate? Your boss wants to get things done in due time and I see Go outcompete Rust in this respect.

Re: IPFS 0.5

#82
post #68

Earlier quoted context omitted.

plus IPFS wants to enforce copyrights worldwide: [1,2] Businesses principles plus monthly bandwidth usage matter for real people. [1] https://github.com/ipfs/community/blob/master/code-of-conduc... [2] https://discuss.ipfs.io/tos#8

This may only apply to their own ipfs.io gateway

It seems global copyright enforcement with blacklisting and blocklists: https://github.com/ipfs/notes/issues/284 (I've testified in US federal court in copyright cases as the expert witness professor. I always try to investigate the DMCA decisions of developers. Difficult tradeoffs.)

Re: IPFS 0.5

#83
I really wish there was a C/C++ implementation of IPFS that could be dropped in to a Linux, Windows, MacOS, or iOS cross platform app.

I already ported the Go code to iOS once, and it wasn't that painful, but functionally it would be a lot more useful as a C++ code base. I don't build browser apps - I feel there is still a need for native apps especially in this particular space.

Re: IPFS 0.5

#84
post #82

Earlier quoted context omitted.

This may only apply to their own ipfs.io gateway

It seems global copyright enforcement with blacklisting and blocklists: https://github.com/ipfs/notes/issues/284 (I've testified in US federal court in copyright cases as the expert witness professor. I always try to investigate the DMCA decisions of developers. Difficult tradeoffs.)

_Optional_ (up to a node operator) global copyright enforcement.

Of course they have to play ball with existing legislation in business settings.

Re: IPFS 0.5

#85
post #58

Earlier quoted context omitted.

Rust isn't that difficult to prototype or start projects with? What trouble do you run into? I think the hardest parts to understand are the concepts of borrowing, lifetimes, and ownership, but you don't have to know all the subtleties of that to prototype. A basic understanding is fine to get started with. Just like a developer doesn't have to understand all the subtleties of generics to get started with either, lot…

Understanding the concepts is one thing, applying them is another thing entirely. The Rust compiler is an incredibly difficult beast to placate.

Especially in prototyping you can mostly .clone() everything, and stop worrying about any lifetime problems.

Re: IPFS 0.5

#86
post #84
post #82

Earlier quoted context omitted.

It seems global copyright enforcement with blacklisting and blocklists: https://github.com/ipfs/notes/issues/284 (I've testified in US federal court in copyright cases as the expert witness professor. I always try to investigate the DMCA decisions of developers. Difficult tradeoffs.)

_Optional_ (up to a node operator) global copyright enforcement. Of course they have to play ball with existing legislation in business settings.

Note that outside of special cases like a publicly-accessible gateway, an IPFS node is not supposed to fetch or retransmit data that the node operator has not specifically requested to be stored there. So this copyright enforcement stuff will always mostly apply to these services. (There might of course be some corner cases such as fetching a mutable IPNS resource and then rejecting the data because it happens to match some blacklist, but these are also broadly sensible.)

Re: IPFS 0.5

#87
post #82

Earlier quoted context omitted.

This may only apply to their own ipfs.io gateway

It seems global copyright enforcement with blacklisting and blocklists: https://github.com/ipfs/notes/issues/284 (I've testified in US federal court in copyright cases as the expert witness professor. I always try to investigate the DMCA decisions of developers. Difficult tradeoffs.)

As hobofan said, this is up to each node to update/block. It really seems like that the TOS only goes for their gateway, I don't see how they could enforce this on the entire network.

Re: IPFS 0.5

#88
post #68

I really really want to use this, I have used it in the past. It works great as far as I could tell except for one thing: bandwidth limits[1]. Now I can do this myself, because I'm all "+337" and what not. (I used trickle as described in the comment[2]. Seemed to work fine. Nice and stable.) But I can't recommend Joe and Jane Consumer to install IPFS and some other thing with a straight face, because they'll say, "We…

plus IPFS wants to enforce copyrights worldwide: [1,2] Businesses principles plus monthly bandwidth usage matter for real people. [1] https://github.com/ipfs/community/blob/master/code-of-conduc... [2] https://discuss.ipfs.io/tos#8

For IPFS to work, there needs to be no central authority who can block files.

Todays IPFS is a long way from that - any Joe Random can DoS any particular hash by getting their node at the right place in the DHT and blackholing requests.

Re: IPFS 0.5

#89

>> Opera became the first major web browser to offer default IPFS support on Android, shortly after Brave started directly embedding the IPFS Companion extension (complete with a built-in js-ipfs node). This means millions of people around the world now have access to the decentralized web built directly into their browsers. Wow. Thank you IPFS community.

I believe Opera only redirects to a gateway and doesn't implement IPFS itself, though, which is rather less exciting.

Re: IPFS 0.5

#90
post #62

Can someone provide an example of a service that ipfs enables that can’t be provided on the regular web?

You can publish static content that doesn't go down when the server goes down and scales on its own as the content becomes more popular. It also has hashing built-in, so you can be sure the content you got is what you wanted,

Things like distribution of apt packages becomes much more exciting when each computer can choose to redistribute the packages it got to others in the LAN or area, even offline.

It's also very interesting to me how all the visitors to your website become servers as well, so content can never be "hugged to death" or links can never go stale, as long as at least one person has the content somewhere on their node.

That, to me, is huge, as links now go stale with some regularity. Think of all the Geocities sites (and all versions of them) just existing for ever, regardless if Geocities decided to shut down.

For example, here's my site on IPFS:

https://ipfs.eternum.io/ipfs/QmVW6JejQkjLnBJacR8qcZi88WNTMwi...

That can now "never" be lost, as long as someone cares enough about it to visit.

Post reply on HN