Ok. I thought the receipts will be made readable for anyone to see on the internet. If they are only readable for the user and the merchant then good. Theres no need to do anything else. All Im saying is the potential use case for decentralized receipts will go hand in hand in a reputation system of Open Bazaar or some platform like it.

Like your idea - some questions -
1. Support for transacting with other chains?
2. How to prevent malicious marketplace action using the vendor's marketplace signing key. Vendor must have a way to respond on chain by verifying their own private key to invalidate a PoPR from marketplaces using Vs.

The most important feature in 'community controlled' is, imo, trust. And trust is gained through disclosure. Think about my lottery site, I am actively preventing suspicion by providing everyone with as much information as possible, including the distribution of bets, so when I say there were 5x2nd prizes, that information can be checked against data that existed before the winning result was chosen.

On the same train of thought we could do accounts based on alias + public key, and allow people to choose their trusted parties (or untrusted, +1/0/-1). If we then disclose the alias trust linkage, I'm sure that all the smart people around here could detect suspicious movements. How could this system be broken? If I create 100 users that all trust my real user, then that user has +100, but none of the 100 fake users is trusted by anyone, so no profit there. But if my real user get trust points from the community, and I trust the 100 that trust me back, this would be slightly different, unless I don't care about who else trusts you, unless they are already in my web of trust.

But I digress, and I need to work

What would be the ideal way to use a sidechain or fork of Ethereum/Bitcoin to establish a trustless 2-of-2 escrow system?
The major problem with 2-of-2 escrow for non-cryptocurrency transactions is that there is no way on-chain to verify the transaction validity without the use of a centralized oracle system or other means.
2-of-2 escrow then allows an attack by which they "reject" delivery, receiving a refund but have actually received the product. This is very inconvenient for anyone trying to set up a decentralized type marketplace.
My potential solution is to issue (via ethereum smart contract or other means) a token for X coins to the smart contract (giving them some amount of value) and establishing a secondary market for them (any major crypto exchange works fine here, more is better).
A Seller (Alice) could then require a given TX require a given amount of collateral tokens per the smart contract.
A Buyer (Bob) would be responsible for "putting up" or "staking" the contract in addition to the crypto used for payment.
In the event of a seller-accept buyer-reject "scam" - the buyer would still be refunded his coins, but the reputation token would be "burned" into the void for malicious behavior. This occurs whether the seller shipped the item or not - creating a disincentive both to initiate a false dispute, and to initiate a dispute, generally. The problem that I see is the value of the collateral token must be strictly controlled such that X is a high enough value to incentivize accepting delivery it would be within standards, but not so high as to make a defection staggering in the event of a scam. Potentially you could write the contract such that the seller chooses the amount of collateral tokens required for the transaction based on the value, and the buyer chooses whether to accept this risk or not.