I'm curious why another study is needed. Is it because the results of past studies didn't make a strong case for the UBI?

Digital goods can be sold but automation isn't going to make it into the first release. Hopefully later this year.

> But in the gif it is showing that you will have to pay for it

Only if the escrow resolves a dispute. The escrow agent doesn't actually learn of the transaction if all goes well.

As to the rest of the questions, the arbitration is a bit ad hoc at the moment.

The vendor selects the escrow agent he's willing to use and offers that as part of a "bundle" with product.

If the buyer doesn't know the escrow agent or doesn't trust him then he should not buy.

Obviously, having reputable escrow agents will be critical and there currently isn't any good in-app way of evaluating the reputation of the escrow.

Currently people tend to bring their reputations in from other platforms and use other platforms to recommend trusted escrows.

1.0 is a bit of an MVP. While there's tons of room for optimization, Go is still much faster.

That plus the fact that the main IPFS codebase is written in Go were the main considerations.

Thanks for the response! So the choice wasn't driven as much by actual performance issues, that might have been solved with refactoring, re-engineering, or simply running through pypy. The catalyst was the adoption of an IPFS library written in Go.

All the store data is kept inside a directory, the hash of which is mapped to your peer ID using IPNS. This enables all store data to be downloaded and authenticated using the peer ID.

Any change to the contents of your directory causes the root hash to change and the IPNS mapping is republished.

Mappings a numbered so when looking up a store via it's ID nodes will always use the most recent mapping they can find.

Republishing the IPNS root breaks the caching that accumulated on the root, but all objects inside the directory that haven't changed retain their caching.