arweave VS notes

For example, decentralized data storage projects like Filecoin, Arweave, and Sia posted 50-100% user growth, providing blockchain-powered alternatives to AWS, Google Cloud, and Dropbox for distributed app data security.

There are a few solutions:

https://www.arweave.org/

https://www.lighthouse.storage/

To me, they seem like the most useful stuff coming out of the blockchain industry.

Familiar DePIN initiatives include Helium, a Decentralized Wireless Network from 2019, Filecoin or Arweave for Cloud Storage.

Arweave is a permanent and decentralized web inside an open ledger.

The metadata in question is called “tags” on the Arweave blockchain. Tags are a list of keys and values you can add to your transactions to give the reader of that transaction additional information about it. They aren’t pre-defined by the protocol; you can add custom tags. But there are several specifications that try to standardize common tags.

Arweave

IPFS isn't the right use case for a dropbox clone. It behaves like a CDN with no persistence guarantees.

Arweave is better suited to archival storage. There are options for participants to ban particular types of content which may be illegal to host in their jurisdiction. This was designed to prevent the spread of CP, terrorism related info, etc. but that means it is also susceptible to DCMA issues too.

https://www.arweave.org/

Arweave is a community owned, decentralized and permanent data storage protocol. You can check it out here.

Another choice is Arweave.

Is there an easy way to comply with an accountable IPFS block list?

"Implement Allow Lists and Block Lists" (2018) https://github.com/ipfs/notes/issues/284

"IPIP 298: (allow|deny)lists for IPFS Nodes and Gateways" (2022)

As for general gateways, those could be used to pull general illegal content against your will, and allow/block lists were discussed at one point for that reason (https://github.com/ipfs/notes/issues/284). However, in the interim, there is a config option Gateway.NoFetch that causes a gateway not to fetch new content, giving you an allowlist if you also have the content you want to share pinned beforehand.

> IPFS is basically the answer to the question "what is the RIGHT way to decentralize the web?"

There is no RIGHT way to decentralize the web. I don't think IPFS is right way to do it either.

Tim Berners-Lee's Solid (https://solid.mit.edu/) offers a much more practical path to a decentralized web. The advantages with Solid's approach over IPFS is that:

- Solid doesn't throw out what we already have, and recommend a new layer on top of the internet. Example: ipns

- Solid handles access control which pretty much every application needs. Encryption is btw, a poor substitute for access control. https://github.com/ipfs/notes/issues/376

- Solid has the ability to revoke access (very important), delete data

- Solid can work in browsers without extensions.

- Solid is not muddied with talk of the Blockchain. It's disappointing that the cryptocurrency has very nearly hijacked this space.

- Solid is conceptually simple. You own a pod that has a unique address (using familiar schemes). You put your stuff on it and allow access to people; like DropBox but standards based. Companies can offer paid hosting services to run your pod - more space, bandwidth etc.

- IPFS is not commercialization friendly.

- IPFS performance is unlikely to be great, ever.

Disclosure: I am invested in an open protocol similar to Solid, but simpler. So not entirely unbiased.

This, and a bunch of side issues linked from it, is a good discussion: https://github.com/ipfs/notes/issues/281

IPFS is not anonymous and like other p2p protocols shares your ip address.

There's been a bit of effort to get it working over tor for years now but the fundamental design makes this difficult. Also despite all the money that has poured into filecoin this doesn't seem to be a priority.

This issue is nearly 6 years old:

https://github.com/ipfs/notes/issues/37

As I see, this is an open issue to be implemented natively in IPFS: https://github.com/ipfs/notes/issues/339