Party1 makes secret1 and secret2.
Party2 makes secret3.
Party1 calculates sha256(secret1) and sends it to Party2.
Party2 combines it with secret3 to calculate sha256(secret3 + sha256(secret1)) and sends it to Party1
Party1 creates an AT that releases on either secret2 or (secret1 with secret3).
Party2 creates an AT that releases on secret1.
Party1 releases Party2's AT using secret1.
If Party1 is honest, Party1 provides Party2 with secret2 which can be used to release Party1's AT without leaving a link to Party2's AT.
If Party1 is dishonest and does not provide secret2, Party2 can still retrieve their funds with secret1 that was used to release their AT along with secret3, however there will be a link left in the blockchain, as both ATs will have received secret1.
I think I get this - so: sha256(secret3 + sha256(secret1)) is what Party1's AT would literally have to have coded (with a test that the result of said calculation == hard-coded value that was passed to Party1 by Party2).
If we added some 256 bit math functions (such as Add_A_To_B which is described in the API docco although it was not expected to be implemented until a later point in time) then we would be able to do this.
In order for "two secrets" to be passed in the one message it'd probably require that secret1 and secret3 would need to be both 16 bytes rather than 32 (I don't think that is really an issue as 16 bytes is still secure enough). The message limitation of 32 bytes is in order for AT to work on Bitcoin clones (messages being implemented as OP_RETURN values).
I was actually intending the + to mean concat, although combining them with a different operator would work also to keep it to 32 bytes, but I think xor would be a better choice than addition anyway, so no 256 bit math operations are required.
Sending 2 separate messages for the case of having to provide secrets 1 and 3 would be another alternative to handling compatibility with btc clones, although having an extra api call that retrieves messages without the size restriction might be good also so you only have to work within the limitations of the coins you are actually transferring between.