Who sets TTL? Should there be a minimum/maximum TTL?

[GeorgeFlerovsky]

George: ... Publisher-specified TTL ...

Drazen: I can see how users would be frustrated with this. We can’t assume that a Publisher knows apriori what an appropriate TTL is for ALL dApps. Some dApp will take 10x ADA/USD exchange samples each a minute apart, and then it can be garbage collected immediately after it has been used. Some dApps will want to store the highest yearly ADA/USD exchange rate, and perhaps refer to it in many transactions. The point is the Publisher perhaps shouldn’t make such a decision. And why would the Publisher care? I mean they get more work paid for if there’s more publishing.

George: The main thing I’m trying to avoid is the submitter setting the TTL too low, because of the submitter’s incentive to recover their deposit earlier. This screws over consumers, because the submitter doesn’t care about keeping the fact statement available for them to reference.

Perhaps this can be managed if we impose a hard minimum TTL.

Drazen: I understand, but do note that Submitter+Consumers would largely come in pairs, they’re going to be the same entity. As in dApps offchain will talk to COOP and build transactions. Not sure if they’ll ever be a separate entity. If they are, it’s easy enough for separate dApps to query onchain to find suitable utxos that won’t expire right?

George: You’re right that some facts are so ephemeral that all consumers essentially have to be submitters for them.

However, I can imagine some domains/usecases where there can be many consumers and few submitters. In those cases, I would like to avoid the submitter’s perverse incentive to screw over consumers.

[bladyjoker]

Currently the user sets the gcAfter parameter. Closing this until the discussion needs revisiting.