There should be an open protocol that can help coordinate people who want to coinjoin.  Is there already something else out there that can automate that?

So it's trivially identifiable whose outputs are whose based on the observed offers?

Read the first page of this thread. There's a solution involving blinded outputs.

I havent read the whole thread so this might not be a new idea but... it was something I accidentally discovered sending coins to a different coin with the same digit.

This concept is not promised to be implemented by VVV but was kicked around.

https://docs.google.com/a/mitchellmint.com/presentation/d/1X0QHjzkVtGJf5sf1vtiIjGQ_AvPg2GdPSYrc5vb9NIo/edit#slide=id.g35a51815e_040

Would using ring signatures work as a method of mixing without having to trust a server even though they are using one? Provably fair mixing?

Have the clients connect and have all the inputs define the initial state of the cryptonote type ring signatures. Each person then shuffles the ring and they are only able to follow their own coins. They then specify the outputs in the ring whatever they are. Once everyone is happy they are getting paid they all sign. No one, not even server would be able to follow who is getting what. And even if the person had one input they could have multiple outputs depending on what they specify in the ring.

Kind of like my idea here: https://bt.irlbtc.com/view/706000.0

I am currently working on a Java library which facilitates decentralized CoinJoin-ing using a BitcoinJ backend.

As of this moment the library only works with fixed CoinJoin participants, I have yet to implement participant discovery (that's next on the list).
It also is very insecure at the moment, as I hacked together some sections in order to test general principles. It will be some time before the code is solid enough to not be embarrassing :\

Current plan:
1. Implement peer discovery (perhaps using a DHT)
2. Fix error handling and enhance verification of transaction components
3. simplify, refactor, rename
4. post source code (under a permissive OSS license)
5. Make CoinJoin process more anonymous.
6. ALPHA release?

example:
http://tbtc.blockr.io/tx/info/c4d86d7a054e5979172b223a15d5d9594f703d6376ab294ee4b2da45ff77b0eb

This is a test CoinJoin transaction between only 2 users. In this example I set the change and output address to be the same. The general caveats of a CoinJoin transaction still apply: each change address is clearly linked with an output address, and therefore by using blockchain analysis it may still be possible to link addresses. True anonymity requires minimal address reuse and tools for managing taint.

For now, though, I just send an unconfirmed transaction to a new address of fixed size, then use that unconfirmed transaction as part of the CoinJoin. Needless to say, for this scheme 0 confirmation coinjoins should not be accepted! Regardless, I am trying to write the library to be adaptable as possible to different types of CoinJoins, including coinjoins where each user has multiple inputs, casual coinjoins, and coinjoins without any change address.

This is very safe, however it is not very private. It is essentially not possible to "lose" your coins doing this, however it has been proven that these types of transactions can be traced by inspecting the blockchain.

I have coded a simple implementation of CoinJoin.
https://bt.irlbtc.com/view/730321.msg8254585

It makes no assumptions about how peers communicate but instead provides ascii-armored raw transactions similar to the PGP format which can be shared on any text-based protocol such as a Tor hidden service forums, Bitmessage chans, I2P eepsites, Freenet pages or something like that.

If you are writing a Java library and are planning on using a DHT, have a look at TomP2P.  Its what i used in http://coinmux.com.

So let me try and figure this out this is a little out of my league but here it goes:

Effectively you are creating a mixing service within the Bitcoin network itself? Making privacy better because no one can track where you sent your Bitcoin because it is split up and combined with other peoples transactions. Surely this has already been done by several mixing services?

Wouldn't this create more legal problems for Bitcoin? If this is what you want to achieve surely it's illegal because this can be abused very easily.