Why build this blog, or anything, on IPFS?
teetotality.blog
teetotality.blog
In addition the ecosystem is filled with technical/community debt that makes navigating the system a nightmare for anyone who isn't an expert. As an example: https://github.com/ipfs/go-ipfs/issues/1482
It's a shame if you ask me.
* = unless something has radically changed in the last few months and they just haven't closed the GitHub issue: https://github.com/ipfs/go-ipfs/issues/3860
You go to https://manager.ens.domains/ to register a .eth address and on the settings page for your domain you add a Content record and point it to ipfs://Qma7nxS98CAb2BTaxLJBSFozxxSp5XTu6tMtCrKcRQ9ByV or whatever the IPFS hash of your website is.
After that you can visit your site at https://myname.eth in a browser that supports ENS/IPFS or you can go to https://myname.eth.link in any browser and see your website.
IPFS is good at content-addressed storage. IPNS is not part of content-addressed storage. Tutorials about IPFS should ignore IPNS, and talk about alternative ways to link to IPFS links, like using DNS.
You're right, there are a ton of great ideas and suggestions for how to make IPFS better that we haven't gotten to yet - we're working on making it easier to navigate and for more folks to help contribute. To that aim, we just created a new ipfs-docs site (in beta right now) to better explain the concepts and how-to of working in the ecosystem: blog.ipfs.io/2020-01-07-ipfs-docs-beta/ -- would love your feedback on how we can keep making that better!
I love the idea of IPFS, but let me ask you the question, when is it finally going to be ready for people to easily deploy? A year from now, 3 years, 5 years? Or maybe you have no idea?
Don't give some vague answer about how you are working on it. Give me a reasonably specific prediction, or say you have no idea.
As far as I know IPFS is an open system contributed to by volunteers. Making those kind of demands for deadlines in such an aggressive tone is way out of place.
And why do they need to be defended by others? If I am being unreasonable, why don't they just say that themselves?
Since I've got you here, I'd be happy to give a little feedback: The constellation of websites for the protocol labs projects, their different visual styles, their different states of decay/maintenance, the interlinking back and forth with source files in github, and the undocumented status of all these projects really lend to a maze-like and poor learning/browsing experience. If it were my project, I would dump all the different sites and consolidate under one web presence. I never know if what I'm reading is current, or planned and not done, or old and out of date, or just bugged. As an example, there are even broken links on the readme at https://github.com/ipfs/ipfs. The number of TODOs or unresponsive links in README files in the various github repos (under the various github organizations) adds to the frustration of trying to learn your work. As an example, take the readme at https://github.com/ipfs/go-hamt-ipld : It's been recently worked on, and yet the entire table of contents are broken links and the examples section is literally just "//TODO". I think y'all should consolidate efforts, kill or privatize the projects that are unusable by the outside world, and in general start developing things to a more complete state before adding new stuff.
I've tried several times now to incorporate IPFS into my developer toolbelt and have aborted my attempt each time due to this or that rough edge that you don't learn about unless you spend time trolling through the github issues. It seems like each time I've come back y'all have added more unfinished stuff (congrats on the filecoin testnet!) and the rough edges still remain. As an example, I just added a 7 gigabyte file (an xcode disk image) through the desktop client: It peaked at around 15gb of ram during the process and the client offered _zero_ visual feedback while it was working. In fact, while the client says my repo is the correct size, the xcode image I added doesn't actually show up in the file browser. It's all very painful to work with. ipfs, ipld and libp2p hit the right notes in their promotional material to entice someone who wants to help the decentralized web grow, and I would love for these projects to be what they aspire and claim to be, but it all just seems to fall apart rather quickly when you actually start to use them for something beyond your tutorials.
(600,900) watermarks suggest you had an old config (ipfs-desktop will respect pre-existing config and won't override values). Just change watermarks manually to (50,300) and restart.
If you run daemon via ipfs-desktop the routing preference from config file is ignored: Desktop runs daemon with an explicit command line parameter (--routing=dhtclient) to avoid DHT server traffic.
Hope this helps.
DAT,SSB don't work in browser.
WebTorrent is the original better choice.
But I'm seeing most big projects move to GUN (mine, https://github.com/amark/gun). Internet Archive, HackerNoon others using it in production, with over 10M+ users, decentralized.
If IPFS team doesn't seriously fix their performance issue within 2 years, they're gonna see a lot of backlash. With $250M+ raised and 100+ employees this should be possible, I know they can do it, dWeb would be better for it.
Now we just need to figure out what to use it for. I think the largest successful experiment of distributed file storage was Wuala. At the beginning it was similar to IPFS, using random home devices to store data, doing some clever calculation and splitting of files to guarantee that a file is likely always available. Emphasis on likely.
They had nice features:
- keep files private
- share files with other registered users
- share files with unregistered users, through a keyed hyperlink
- publish files
- backup
- file synchronization
- file versioning
At the end they migrated away from using random home nodes for storage and went for central servers. Not sure about the motivation behind it but I would really like to know. Did that happen because of business requirements or some technical limitations?
Each node can disappear at any time and is really hard to predict. To compensate for that you will need to upload your data to more nodes. You have to deal with backward and forward-compatible updates because both client and server versions updates are also not under your control. There are also more complicated issues of trust and bad actors that can affect the product.
Now you have a datacenter. The clients upload their data exactly once. Your server software has at most two concurrent versions during deployment. Security is handled in a traditional fashion with DDoS firewalls and pentesting. Your whole software stack is much simpler because you can build on top of more solid assumptions.
Skype also used to be P2P until the Microsoft acquisition where they moved towards hosted nodes. Some people say it's so that Microsoft can spy on everybody but I really believe that the main reason was so that they could improve the QoS.
I generally agree with the conclusion, but there's a few downsides that aren't conveyed here.
Let's look at the proposed upsides: 1) Ownership, control, censorship: That's partly correct. Ownership is fair, in the sense that you can run your node and self-host. However this is true of any self-hosting solution. You could run a Docker instance of a Wordpress or Ghost site and get ownership / control.
2) The point about censorship is muddied, however. I'll combine that point with the second upside: Resilience. Every day for the past two years, I've seen people wonder if IPFS is a magical cloud with infinite storage. People seem to think you put a file on IPFS, and it just gets replicated, censorship resistant hosting. That's not how it works. People need to pin your hash. You need to tell the world about your hash somehow. All this is done via a public list of IPs that is being broadcasted. Think of IPFS this way: you're letting people with the hash become CDNs of your content. That's cool, but that doesn't solve discovery, keeping things up, etc. IPFS doesn't encrypt the content, or the connectivity, or hide the hosts. Solutions exist around that, but they're niche, and honestly I question the motives besides just ideology.
3) Elegance. Yeah it's a really, really cool way to solve linking. As some others pointed out, it's not as fast as classic centralized links, so it's better suited currently for solutions that don't require speed.
1. https://techcrunch.com/2019/11/05/how-arweave-permaweb-works...
I question the motives of people who would be against encryption, aside from it being a lot of work and just not having been done yet. Ideally: no one should know the true IPs of their peers, and no one snooping on the connection should be able to read anything useful. Even the contents of the files should be encrypted, but I struggle to see how that could be easily implemented (maybe like Mega.NZ does where the key is part of the URL).
Otherwise it's going to be very hard to convince me to host arbitrary content from untrusted strangers. It's just pragmatic. No encryption = no plausible deniability.
Let's say that stuff was encrypted during transmission, and also when stored by peers. But peers could see each other's true IPs. That would basically give you a modern version of Freenet. And just like with Freenet, users could be arrested, and prosecuted based on hand waving. When you get down to it at trial, "plausible deniability" depends on having a suitable expert witness, and convincing a jury that the prosecution's expert witness is full of it.
So anyway, none of that helps unless true IPs of peers are hidden.
Hiding connectivity metadata and host identity are essential to protect users from adversaries.
What I'm recommending would protect all sorts of users from all sorts of adversaries. So it's nonjudgmental.
But that doesn't mean that it's "circular".
So, you could publish content to IPFS and tell your favorite CDN to pick it up, and you pay them to keep it active. But IPFS isn't limited to one CDN, so you could always pick another one. And your users could also go through a different CDN. Or some people who really want to could run their own CDN and pin whatever they want to host.
Think of the bits that work properly as "the web of BitTorrent magnet: links" and you'll have a reasonably accurate picture.
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.
Is there a reasonable way to use untrusted gateways while upholding the data integrity guarantees? I think it should be possible in theory.
It was y'all that actually got IPFS working via Tor.
Or to pick something closer to the point, someone seeding a copyrighted film and also a Linux distribution. That sort of coexistence has gone on for many years without causing problems for the legal uses of torrents.
I’d have the same objection if the seeder was voluntarily choosing what to seed for that express purpose, but I don’t know that it should apply if the seeding is just an automatic part of how the network operates underneath.
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.
Though it's old school, it's incredibly difficult to run server at home now at least in India. The network I connect to is behind a NAT which is behind another NAT. At least that's what I saw when I tried to host my blog on Raspberry PI at home over a year ago. Ultimately I gave up on that endeavor. If anyone has solution that doesn't involve third party, please suggest.
I think I will have to wait until my ISP implements IPv6. That could take another decade :/
- [0] https://github.com/cjdelisle/cjdns/
- [1] https://scuttlebutt.nz/
I solicit feedback via email rather than having public comments, and upcoming authenticated areas are done via Auth0 tokens.
I was in the same predicament but there was a news item that act(ISP) was rolling out ipv6... speaking with customer care and even escalating to nodal support was useless as they were clueless... Spent an afternoon fiddling with router and I got a v6 address no problem!
Tl;dr; don't believe clueless tech support .. Just try it out at your end.. you might get a pleasant surprise!
1. Talk to your ISP. Most of them will assign you a public static IP for a fee (5000 INR/yr was what I was quoted last time)
2. Setup a simple proxy on a $5 droplet on Digital Ocean. I run OpenVPN server on the droplet, a client on the homeserver, and `simpleproxy` that forwards the relevant ports. You can do the same with iptables as well.
3. Any other approaches involving ngrok-like solutions are much costlier, unless you host it.
Not to be a downer on IPFS at all, btw. I'm very glad that both it and Dat exist. IPFS has always seemed like a much larger undertaking and it is cool thst they are trying to push the dweb even further. We need that just as much as we need Dat, which with its inclusion in the Beaker browser for example really serves as a super cool demo of what dweb can give us in the future.
With a title like "Why build this blog -- or anything -- on IPFS?" You were trying to persuade me, right?
I had to read through what is essentially every single cooking recipe on the web, before I got to the actual filling. I.e a whole lotta aimless wandering and musing, that is only tangenitally related to the topic at hand, before giving me what the title promised. Similarily to cooking blogs, this page is 2/3 filler, and 1/3 actually giving me what the title promised "So……why IPFS?"
> 1. Ownership, control, censorship
The author goes on to chastise Medium's censorhsip practices, but not too long ago he mentioned self-hosted Wordpress and staticly-generated Github pages. Wordpress and Github pages get over these hurdles and are easier to setup than IPFS.
> 2. Resilience
Suffice to say, the point of this pargraph was "DNS and HTTP unrobust, webservers fail under unforseen circumstances." Ok, well how does IPFS do things differently? You never explained how IPFS works, much less how it gets over any of the aforementioned issues you outlined.
> 3. Elegance
> But I will say that content addressing strikes me, and many software people who come across it, as obviously superior to host-based addressing along certain dimensions.
Never touched upon or elaborated.
> Plus, it's super cool. You should try it!
Atleast you have a call to action. Otherwise, this post fails to even come close to making me interested in IPFS.
Still, I wish IPFS had been defined within the post. I had to look it up on Wikipedia; presumably it's "Interplanetary File System".
I think my main problem with this blog post, and many others, is that they come off too "stream of consciousness," instead of something more structured, and easily-digestable.
It's obvious the author can write[0], but at risk of being presumptuous, it seems like it was hastily written and submitted to HN for the sole purpose of generating traffic.
[0] This is a much better piece, albeit short: http://teetotality.blog/posts/think-do-build/
If DNS and HTTP are not working absolutely no one will care about some blog being up.
If you understand how BitTorrent works -- including its strengths and limitations -- you'll understand how IPFS works.
Broadly I agree, but IPNS isn't really part of IPFS, it's an external thing that fakes mutability of another thing that cannot be changed. There are many examples of this kind of thing (e.g. DNS itself, abstracting over IP addresses), with an incredibly wide variety to deal with the various tradeoffs, and IPFS itself not hardcoding a single approach is a good thing. BitTorrent doesn't either, but some tactics have sprung up organically, as has occurred for IPFS (e.g. https://www.increaseo.com/eth-domains-ipfs/).
I would argue that this is even more of a problem with decentralized services because there is no one to define (or police for) spam or bad content.
So, IPFS is more of a CDN than a file system currently. It's a distributed content cache. There's an enormous long tail of files that are only available on 1 node, which is typically somebody's laptop.
Another problem is that the block system does not combine well with e.g. s3 or similar file buckets on popular cloud providers. If you think of IPFS as a CDN then you basically have to worry about hosting files somewhere that is reliable and durable. IPFS does not solve that problem currently. So, you basically will either be self hosting some file servers or use something off the shelf, like S3. There's an S3 backend for IPFS but it's a bit unclear how well that performs. We've done some tests with it and the small blocksize is creating quite a bit of overhead for read and write HTTP requests.
Access control or privacy protection are currently not really in scope of IPFS. I doubt this is a good tool for bypassing e.g. censor ship unless you are willing to expose yourself to explaining why your node is hosting certain content hashes. TOR and I2P probably provide better protection here. I2P actually runs a variant of bittorrent for file sharing. It's been a while since I looked at this but it used to be quite slow but reliable.
I'd be really interested in a "what to do and what not do" wrt IPFS to avoid those 20s (or completely non-functioning) URLs.
The traditional web works with the concept of timeouts set by the owner. So if you request some content, and it's unable to find it within X seconds, the request gets cancelled.
IPFS (the network, not gateways) works differently, as the use case is different. Basically, there is no "requests". You simply put in a "ask" in the DHT about who has this content. If someone finds someone who provides the same content, then it tells you about it.
IPFS in itself doesn't have any timeouts, as the model is different. The use case is basically "I need this content, no matter how long time it takes and from who".
So, the difference between DNS addresses responding with different times, comes up to the maintainer of the gateway. Sometimes it's more connected to other nodes (like probably ipfs.io's gateways are) and sometimes they employ a longer cache for content (cloudflare's gateway have a long cache) and it makes the resolution time faster/slower.
- Use more static HTML - Since your assets are versioned and static, start calculating hashes for everything you publish - When you link to something, include the URL and the integrity <a href="URL" integrity="sha256:...">...</a>
In the immediate future this will fix broken links. Things that are important will be cached and accessible via content addressing. In the long-term future this will fix other problems like linking to a page and then it being changed to something you don't endorse.
ipfs resolve -r /ipns/teetotality.blog/posts/how-this-blog-was-made/%60: no link named "`" under QmefCQnxfw2qaT5WKMxiMVGTWu2i47ttpyUCDdn7f3nA2K
Why is medium being compared to IPFS???
You can read more about why that is here: http://teetotality.blog/posts/how-this-blog-was-made/
> It updates a dnslink pointer at Cloudflare, which allows Cloudflare's DNS to direct teetotality.blog HTTP traffic to the correct IPFS hash address via their IPFS Gateway. So even though you've (probably) reached this page through a regular old HTTP link that uses the teetotality.blog host name, there is in fact no server with that name - the content is stored on various IPFS nodes, including but not limited to Cloudflare's edge caches.
I don’t want to write a wall of text, right now the top post on https://qbix.com/blog lays out several specific actionable things we can all do to bring about this future. It requires a snowball effect and a critical mass for any of this to take off.
"I struggle, you struggle, (thus) we relate!"
I blame it on the spirit that being last in school is way cooler than being first, and I suspect it's as old as humanity.
Why not just make your criticism of the quoted text straight up? Why the rhetorical flounce out of the room?
There’s a proof of concept of building IPFS into Guix’s store[1]. There’s also periodically discussion on the mailing list. I’m sure it’s much more complicated than I’m giving it credit for, and there would be security and social implications (someone’s going to be building most of the software, and what happens if you have low bandwidth or a small data plan?) Still, IPFS sounds like an interesting experiment in this area.
Don't get me wrong. Content addressing is very cool, and may revolutionize everything. It's very elegant. I'm just a bit skeptical.
You know what? Saying stuff is addressed by their content doesn't change the fact that the internet is "location-addressed" and you still have to know where peers that have the data you want are and connect to them.
And what is the solution for that? A DHT!
Turns out DHTs have terrible incentive structure and don't seem to be working well.
Downloading content on IPFS is the _most slow experience ever_ and for some reason I don't understand downloading is even slower. Even if you are in the same LAN of another machine that has the content you need it will still take hours to download some small file you would do in seconds with `scp`.
Now even if you know which peer has the content you want and tell IPFS to connect to it directly and the connection is established and the is being (slowly) downloaded... IPFS will drop the connection and the download will stop.
Sure it can.
- Github pages
- Netlify
- Zeit
All free for static sites; all easy to set up a continuous deployment pipeline for.
I recently went back to Digital Ocean for my side project because of what Netlify currently doesn’t have: DNSSEC, HTTP/2 push and prioritization. ECC certificates from Let’s Encrypt.
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 instance of H2o where I have full control.[2]
1. https://github.com/andydavies/http2-prioritization-issues
2. https://h2o.examp1e.net/configure/http2_directives.html#http...
Provided it fits into a single Ethernet frame it's not going to make any difference, right?
Basically you can access it if you use Opera browser or some browser extension. If not there are some gateways, like this: blog.almonit.eth.link
but even a personal publishing server would also be great to keep people's data being controlled by megacorps
Can't they come back when it's really usable?