Do hubs fire data expiration events?

[dawsbot]

When requesting data from a hub's http or grpc endpoints, there is no expiration data for casts, reactions, etc. This makes replicating more difficult because we don't know when to expire data. My question is multi-fold:

1. Is there an event sent from hubs to expire data automatically when it's time?
2. If no to above, can we add expiration data in the API responses from hubs so that consumers know when the data they're receiving is no longer valid?

[vrypan]

Data do not expire, hubs prune data, based on various rules.

One rule has to do with storage duration: Storage units last for one year, but as long as I keep buying new ones ate the end of the year, my data will never expire.
The other one has to do with storage capacity (storage limits). For example, if I have one storage unit, I can store up to 5,000 casts. Which means that when I cast my 5001 cast, the first one will be pruned. Unless, I buy one more storage unit, in which case hubs will store up to 10,000 of my casts, etc.

My mental model is casts never expire, in the same way that if I have a hardware store, screws never expire (contrary to fresh fruit for example). But I will probably throw away very old stock of screws in order to make room for more recent and more profitable stuff. But if you have more room? You should feel free to store them :-)

(Maybe the team has a different way of thinking about this, I'd like to know their pov)

[dawsbot]

That is helpful! Thank you for the explanation.

A relevant follow-up would be "Is there an event sent from hubs to expire data automatically when it's time?"?

I believe the hub only has events currently for when a user initiates a cast delete or a reaction delete. But is that same event fired when the user has not paid and/or they cast one more than they have paid for?

[sds]

Messages don't expire, they'll eventually be pruned. Every pruned message results in a prune event being emitted.