All the docs tells about to setup IPFS server. What is the intended way to browse ipfs sites(extensions , or new browser ) ?
Why build this blog, or anything, on IPFS?
151–156 of 156 posts
Re: Why build this blog, or anything, on IPFS?
#152Last I checked a lot of the consensus were that the Dat project was more mature than IPFS and that it had some advantages over IPFS (such as not using as much resources to run). How is it now? Is it more mature? Even though I actually even sub to their newsletter I haven't really been keeping up to date if they have made any major releases. Not to be a downer on IPFS at all, btw. I'm very glad that both it and Dat ex…
I've tried both extensively. Both suck. And they're not really comparable, except on their problems.
Re: Why build this blog, or anything, on IPFS?
#153When I first learned about content addressing a couple years ago, it sounded like the holy grail. I'm less certain now. It seems much better from the machine perspective, but I'm not sure it matches closely enough the way humans interact with data. We are spatial and temporal creatures. There's something unsettling about my video file being chopped up into a million chunks and stored who-knows-where. Compared to the…
Technically content addressing and chunking (chopping up files) are two orthogonal techniques. You could envision a system where the hash of a single raw file (no matter how big it is) is it's identifier, and you can then have a mapping between that identifier and the locations (e.g. IP addresses) of servers who store the whole file.
You are of course correct. I was implying current content-addressing systems, such as IPFS.
Re: Why build this blog, or anything, on IPFS?
#154Earlier quoted context omitted.
I understand that no one is going to tamper with the data. Everybody (who is running a full node) is gonna get what they ask for, but then they are gonna go and announce it to the world that they have it, and that worries me privacy-wise.
> that worries me privacy-wise This should be addressed by the client, not the server. The server's function is to serve the data, not serve data and pretend it doesn't know who it gave it to.
Since IPFS is peer to peer, who is the server in this context?
Re: Why build this blog, or anything, on IPFS?
#155Earlier quoted context omitted.
Why do you want ECC specifically? Isn't that an implementation detail?
From a performance point of view, ECC certs are significantly smaller than RSA certs at a comparable level of security. Smaller certs translate to fewer bytes going over the wire when doing TLS handshakes, reducing latency. But it was really their lack of HTTP/2 push support and how their CDNs don't support H2 prioritization correctly[1] which annoyed me to the point of going back to Digital Ocean and running my own…
> Smaller certs translate to fewer bytes going over the wire when doing TLS handshakes, reducing latency.
Provided it fits into a single Ethernet frame it's not going to make any difference, right?
Re: Why build this blog, or anything, on IPFS?
#156Earlier quoted context omitted.
The other potential possibility/issue that I would be uncomfortable with, would be a bad actor visiting and then seeding my content. Say someone also seeding or just locally having child pornography or some other nefarious thing, and now they are also an aggregator for your non-nefarious content. Just the possibility of that type of potential unintended association gives me pause in terms of considering it for a blog…
I got a downvote so I guess people aren’t concerned about this or believe my concern not valid or naive?
> I got a downvote
Have another one for complaining about it. Wear most with pride and some have been proven to be well deserved. Let history be the judge rather than your fragile ego hey.
Otherwise feel free to go back to Reddit.