StrongLink 2015-11-25

Catalogue of my most notable disagreements with IPFS:

https://github.com/ipfs/go-ipfs/issues/1953

Hash conversion for import/export and long term archival #1953

[…] The IPFS code is open but work needs to be done to make it practically possible for other software to generate and validate IPFS hashes. The bare minimum is documenting the DAG format and writing a simple, portable algorithm for generating IPFS hashes (synthesizing whatever necessary DAG meta-data). IPFS itself should also standardize on one representation (which doesn’t mean getting rid of the trickle-DAG mode). Ideally, file hashes would be the raw hash of file content, not including anything related to how it’s stored in the DAG (but still using the multihash format). […]

https://github.com/ipfs/go-ipfs/issues/1957

Ability to specify known hash when adding #1957

[…] This depends on the user being able to compute the hash in advance. If the file came from IPFS, then that’s not a problem. Otherwise, applications need to be able to compute IPFS hashes for themselves (see #1953).

https://github.com/ipfs/go-ipfs/issues/1678

Standard URI for ipfs and ipns protocols (Discussion) #1678

[…] An IPFS path works as a relative URL. That means it is a resource name without a canonical location. Browsers can interpret it without conversion as relative to the current server, which presumably supports the IPFS interface. I can only call this a brilliant hack. It gets IPFS up and running very quickly for what it wants to do, but I think it has some long term tradeoffs. Using a new URI protocol makes more sense and is probably a better choice in the long run, but it breaks browser support right now. […]

If we could get all of these projects to standardize on a link format, then they could all interoperate (like how we have multiple compatible web browsers). Unfortunately I don’t see that happening anytime soon.

On the bright side, I’ve seen some comments by Juan Benet indicating that he understands that DHTs aren’t suitable for all use cases and plans to support other routing systems.

IPFS and StrongLink differ on how web pages should be represented. Obviously both allow you to store whatever data you want, but IPFS encourages users to store full web pages as-is with /ipfs/[hash] relative links. StrongLink instead encourages page content, such as HTML fragments[#] or Markdown, which is then rendered by a StrongLink application (such as the blog interface).

In my opinion, Juan has been over-selling IPFS as all things to all people:

https://github.com/ipfs/faq/issues/1

What type of apps would not be a good idea to build on top of IPFS? #1

https://github.com/ipfs/faq/issues/20

Streaming data between nodes #20

https://github.com/ipfs/faq/issues/51

centralized DB support? #51

I think IPFS should offer some level of guarantees about decentralization for applications that run on it. For example, Facebook shouldn’t be able to release “Facebook for IPFS” that downloads some stub loader over IPFS and then loads Facebook from their central servers. It’s too easy to subvert, but preventing it means acknowledging that a decentralized web will have certain limitations and can’t replace the traditional web for everything (e.g. e-commerce).

IPFS is strongly influenced by Git, including its command line interface. Git’s CLI is widely considered difficult to learn/use, but where Git uses two-level sub-commands, IPFS uses three-level sub-commands almost everywhere. This isn’t a fundamental problem as long as some sort of wrapper UI eventually becomes popular.

https://github.com/ipfs/archives/issues/8

Search engine #8

Search is an important feature on the web, so it will probably be important on the decentralized web too. Search on IPFS is basically a research project, with efforts to design a search index on top of the IPFS merkle-DAG. Even if it works and isn’t slow, it’ll have to deal with spam and SEO. StrongLink doesn’t have these problems, basically by using federated search.

Keywords: design, tradeoffs