momack2

Yep! The SNARKiest network out there I believe! https://research.protocol.ai/sites/snarks/

Hm, I've taken a look at some of the Storage Provider ROI dashboards and AFAIK numbers aren't anything like that -- so not sure what timeframe or cost of goods you're extrapolating from. (ex https://fgas.io/)

I'm also confused how your model accounts for all the ecosystem development and enablement work that is being done across the Filecoin ecosystem. Filecoin isn't just another ETH clone - there is a ton of engineering and product work happening across many teams, with a ton of resources and dev work being poured into them (ex https://www.youtube.com/watch?v=ApVVg78ZBog)

Fine to complain about crypto economic token distributions or something specific - but please don't imply that the dev teams working on Filecoin / IPFS are freeloading or disingenuous. There's a massive amount of work going into building new content-addressed web primitives by some very mission-driven folks that you're unintentionally maligning. (full disclosure - I'm one of them)

You have 2 main pathways for building on FVM: 1. (available sooner) Building an EVM smart contract that then interfaces with Filecoin's built-in actors. This will use existing EVM smart contract dev tools like HardHat, Truffle, Remix, Metamask, etc - and most contracts will likely be written in solidity (or any other EVM compatible language) 2. Native Rust smart contracts (or any language that compiles to run directly in the wasm FVM runtime). There is less tooling available for this today (though there are a few WIP SDKs being built in the Early Builders program), but maybe more accessible if you don't know solidity.

You can look for some of the FVM Foundry demo videos to see what folks are building so far! https://www.youtube.com/watch?v=jTtZh1zqUr8

Example: most NFT marketplaces (OpenSea, Foundation, Palm, etc) use IPFS and Filecoin - https://blog.ipfs.io/2021-06-17-opensea-ipfs-filecoin/

Hmm, I wouldn't assume the goal here is censorship resistance (esp given IPFS+ENS already fits that niche better). Looks to me like someone in the ecosystem is seeing the recent massive speed up to IPNS publishing (launched last week) and testing the waters on whether an "IPNS+DNS as a service" site would be useful to the folks that host dweb sites on IPFS.

Not sure when you last paged into IPFS - the team has made some pretty awesome performance improvements in the past year and seen strong adoption to match (ex, nearly all NFTs are stored on IPFS today).

Definitely check out the IPFS 0.9 release from last week if you haven't seen it! Has some MASSIVE speed ups to IPNS propagation - we're talking less than a second resolution now! There's also a new experimental DHT client that can provide 30M records in about 2.5 hours (which the folks at nft.storage are using reliably at scale). -- https://github.com/ipfs/go-ipfs/releases/tag/v0.9.0

This is cool! Curious if you'd be interested in doing a more formal anonymity audit of OnionCat+IPFS? AFAIK, the main hesitancy in making more of these capabilities broadly available is a potential mismatch between _expectations_ of privacy from a TOR+IPFS solution vs real-world constraints on reader/writer privacy for a distributed p2p system.

On this page in Brave (chrome-extension://nibjojkomfdiaoajekhjakgkdhaomnch/dist/options/options.html) you can choose any IPFS gateway you prefer (or even run your own gateway if you want!).

List of public IPFS gateways available here: https://ipfs.github.io/public-gateway-checker/

That's a great idea! I know there's a project in the works to have redundant copies of the Archive stored on Filecoin, so expanding that to also make the data available for Collaborative Clusters should be totally doable. We'd have to slice the archive down into bites that small machines like yours and mine can help with though. Thanks for the suggestion!

You can become an IPFS Cluster Follower (https://collab.ipfscluster.io/#instructions) and help back up various datasets of IPFS content (like Project Gutenberg, Package Managers, Websites, etc)

We're actually implementing a standard Pinning API right now! You can check out the spec here (https://github.com/ipfs/pinning-services-api-spec) - currently being integrated by Pinata and soon others.

By the way, here's a PR to add other pinning options to the docs: https://github.com/ipfs/ipfs-docs/pull/471

When was the last time you tried? 0.5.0 from May had a lot of improvements - but go is still a hungry hungry beast. maybe try using Desktop which sets a lower peer count?

Thanks! We've been making a lot of updates to the documentation to make it easier to use - so glad it feels easy to follow!

I'll follow up on the Pinata docs example. There are a lot of options for how to persist content in the IPFS network, and we should describe all of them (even if Pinata is one of the smoother/easier to use ones for those new to IPFS who don't want to run their own persistent node). Feel free to file an issue or PR on that docs page if you get a second and we'll help get that fixed ASAP.

Given interest in decentralized persistence, you may be interested in collaborative clusters which allow a group of peers to all persist each other's content: https://collab.ipfscluster.io/ & https://cluster.ipfs.io/documentation/collaborative/

You may enjoy this HackFS Workshop from Juan Benet (creator of Filecoin) that starts pretty high level but gets much more into the details of how the Filecoin network works: https://www.youtube.com/watch?v=P28aNAdZDi4

Correct, IPFS is not a blockchain - while both are merkle-dags ('directed acyclic graphs' of hash-linked data), blockchains have all nodes sync the state collectively, while IPFS instead shards state across the entire network (such that each node maintains its own filestore).

Nope - but used by lots of blockchains for things like off-chain storage (since having a content-addressable handle for a file that can never change is super critical for things like smart contracts)

For anyone looking at https://arxiv.org/pdf/2002.07747.pdf to get an estimate on the actual # of IPFS nodes, note that these tools are trying to crawl the number of nodes acting as "DHT Servers" in the Public IPFS DHT. Nodes behind home firewalls or NATs don't become DHT routers because they aren't dialable, and other large users intentionally set many of their nodes into a lower-bandwidth client mode. Also, many applications run their own private IPFS networks (like OpenBazaar for instance) and don't participate in the Public IPFS DHT, so wouldn't be reached through a crawler here.

Actually, content-based addresses is really critical for decentralized web stuff - since you can't trust a single source to name data, and instead want many different parties to participate in the same global address space in a secure and trustless manner. Check out the dweb primer for why working with a base-layer built on content addressing is so powerful: https://flyingzumwalt.gitbooks.io/decentralized-web-primer/a...

IPNS is used by many groups to create a mutable layer over IPFS (it recently got much faster in our 0.5.0 release in April), but you can also use tools like Textile, OrbitDB, or other mutable databases built on IPFS.

Going well! Check out all the awesome applications using IPFS in our editable ecosystem diagram: https://www.figma.com/file/2bVNnjoOmxh4TtID9kzqEG/IPFS-Appli...

A few highlights are Fleek, Textile, Audius, 3box, Anytype, Qri, Berty, and MagicLeap! Specifically in the blockchain space, there's Peepeth, Augur, Uniswap, Civic, Arbore, and Aragon.

Our TOS applies to the IPFS HTTP Gateway where Protocol Labs run the infrastructure (bridging data in the IPFS Network to users over HTTP) to ease onboarding/development. There are many different IPFS Gateways (https://ipfs.github.io/public-gateway-checker/), with different local jurisdictions that can each choose their own TOS.

We do not and cannot control the data that each individual node is hosting in the IPFS Network. Each node can choose what they want to host - no central party can filter or blacklist content globally for the entire network. The ipfs.io Gateway is just one of many portals used to view content stored by third parties on the Internet.

That aside, we definitely don't want to 'apply copyright worldwide'. For one, it's not consistent! Trying to create a central rule for all nodes about what is and isn't "allowed" for the system as a whole doesn't work and is part of the problem with more centralized systems like Facebook, Google, Twitter, etc. Instead, give each node the power to decide what it does/doesn't want to host, and easy tooling to abide by local requirements/restrictions if they so choose.

Saying there's "no business value" in tools coming out of this space/building on IPFS is nonsense. Sure, the vast majority of people won't care about using a tool because it's decentralized in and of itself, but they _will_ choose tools that give them features they care about - like working better offline, having faster downloads/uploads, being more reliable and trustworthy, preserving their agency and control, etc. These implications from building a distributed system (ex able to collaborate when disconnected from central servers) are strong business reasons for folks to use one service over another, but that isn't clear from saying "it's decentralized". Look at Netflix using IPFS for faster container image distribution (business value: more productive developers - https://blog.ipfs.io/2020-02-14-improved-bitswap-for-contain...), Audius & Matters.news using IPFS to give content creators more ownership over their own data, Berty & OpenBazaar using IPFS for private messaging/marketplaces -- clearly there is business value in removing middle-men/central points of failure & control in these applications.

You absolutely can incentivize others to pin content. Check out Infura (infura.io), Pinata (pinata.cloud), Temporal (temporal.cloud), and Eternum (eternum.io) - these are all services you can pay to host your IPFS data with reasonable uptime. They have an incentive to keep your content around because you pay them to. Filecoin is a distributed solution to that (and making active progress - they have a testnet out with over 5PB of proven storage: https://filecoin.io/blog/roadmap-update-april-2020/), but you don't have to wait for that to land.

Check out Filecoin (https://filecoin.io) - token for buying/selling file storage for IPFS data. You can earn tokens for renting out your disk space and use them to purchase backup/hosting from others.

...there are a lot of cool and useful integrations popping up: https://blog.ipfs.io/weekly-84/.

go-ipfs is where the majority of new development happens right now as the desktop/server implementation (compared to js-ipfs=browser & rust-ipfs=IoT) - but if you want to prove that Rust is clearly better/faster _in general_ - have at it: https://github.com/ipfs-rust/rust-ipfs ;)

I think the thing jbenet was selecting for back in 2013 was concurrency support & modularity, and golang is still a decent choice for that. Rust 1.0 didn't happen until 2015 after the go-ipfs alpha was already out - but agree it's made awesome progress since then!

Totally agree with you. This is an issue for most open membership p2p networks. Effectively, you need to create some type of reputation system or barrier to accruing power to make it harder for attackers to DOS/manipulate the network than for well-behaving nodes to operate it. IPFS definitely thinks about resistance to a variety of attacks like the ones you describe - but we still have a ways to go. Next steps might look like improvements to the DHT, or other more selective content routing solutions (ex, expanding on our dht-client vs dht-server designation to make content routers more selective/reputation-based).

Check out our most recent research discussion for some thoughts about how we might scale up Sybil resistance in p2p networks: https://www.youtube.com/watch?v=L4SJzoKHKPk

orbitdb is a distributed database built on IPFS - looks like they have a python http client: https://github.com/orbitdb/py-orbit-db-http-client

the py-ipfs-http-client library is also actively maintained (but I think needs some small changes to work with IPFS 0.5): https://github .com/ipfs-shipyard/py-ipfs-http-client/

There's actually a new Rust-IPFS implementation looking for more contributors. Seems to be moving pretty fast - https://github.com/ipfs-rust/rust-ipfs

IPNS records still have a default 24hr lifetime, but republishing your IPNS records is now much MUCH faster, so it should be much cheaper to run a process to republish these regularly. I assume you can also bump up your lifetime to >24hr if you want - but note that will mean nodes not using pubsub (aka getting updates pushed to them proactively) might be slow to get new updates.

Here's what's new for IPNS in the release: https://github.com/ipfs/go-ipfs/blob/master/CHANGELOG.md#ipn...

We do use Kademlia - but note this release actually runs 2 DHTs - one for LAN connections and one for WAN connections. You could easily imagine a small Mars outpost as the LAN DHT where you can do fast retrieval for all content already available locally without hitting interplanetary lookup times.

https://docs-beta.ipfs.io/recent-releases/go-ipfs-0-5/featur...

Brave embeds IPFS Companion - which allows you to have an embedded js-ipfs node in your browser! https://ipfs.io/ipfs/QmSHE8RjeP59WamMrgEmaDnDFASui2hainG7BZ3...

In Brave you need to either run a local node (ex using IPFS Desktop), or enable the embedded js-ipfs node in the IPFS Companion settings - https://ipfs.io/ipfs/QmYoZWq5Q23kv5P2vkmLUqRRjdMgqTd3kuggezo....

Still room to improve - Opera's default support is much easier from a UX perspective - but it's all part of the upgrade path!