what is the rationale for encouraging multiple implementations of ipfs?

[danoctavian]

Why not stick to writing a single implementation (eg. go-ipfs) and just have some interface for interacting with the ipfs daemon with implementations in many languages?

[bedeho]

I've also wondered about this.

[jbenet]

Go doesn't run on the browser (or rather, not really).

[lstagner]

You might be able to use gopherjs or llvm+emscripten. Even if its sub-optimal it would be interesting to see if it can be done.

[jbenet]

@lstagner indeed. would need to build connectors for webrtc and websockets as the comm, but it might just work :)

[io7m]

I think the main value is in having different people try to implement the specification in as many different ways as possible: You soon learn where the specification is weak! This is obviously not IPFS specific.

[alspore]

@io7m I think having multiple implementations will allow for better embedded application specific clients long term. If the protocol becomes the standard, not the implementation, experimentation with implementation will be more encouraged.

[non]

Agreed -- and in fact, if there is only ever one implementation then it is likely that either there will be no complete specification, or that the specification will be obsolete/incomplete/incompatible with the implementation. In that case, folks who want to experiment will end up having to try to reverse engineer the actual protocol from the implementation.

[daviddias]

Lot has happened since the opening of this issue :) I'm closing here but if you want to continue the discussion, please do so at https://discuss.ipfs.io/