Emit labels with expiration set

[Bossett]

The label schema (https://atproto.com/specs/label) allows for labels that expire by setting the exp: value, however this is not currently enabled by Ozone.

My current use case is that I want to label 'new' accounts - so the newness label should expire so I don't have to keep track of it.

(will be playing around with it today - so will update this issue over the next few hours after seeing if I can emit something expiring)

Would love to see this added to the API or UI - I suspect most use cases here are automated, so would be good for this to be API first and UI second.

[bnewbold]

I believe the current status of expiring labels is that they should get enforced at the appview (so not hydrated as metadata if the label has expired), but need to confirm that, as we haven't actually used them to date. We need to update the ozone emit-event endpoint to accept an expiration time when creating labels; the expiration time would apply to all the labels created in that batch. There might be a few details to work out around clobbering/updating existing labels, for example (eg, do you need to delete-and-recreate the label, or does the existing label get updated, etc).

Adding a new-account label was actually the original motivation for having expiring labels, we just haven't gotten around to it. We could pretty easily have automod add this label for new accounts, coming from the bsky mod service, as an "unregistered" label, so it is available to clients and app behavior without showing up as a badge. Or I guess it could be a badge or neutral label of some kind, which would let folks explicitly "hide" all such content. That is a pretty strong product/community dynamic; though the harassment/abuse/ban-evasion is pretty real and being able to filter that out pretty worthwhile, even if it is kind of a drag net.

Just to note, in the long run we might also add account creation time as metadata in more endpoint responses, like profileView. That would let downstream services have more sophisticated behaviors (eg, different behaviors for "one day old" vs "week" vs "month"), and not require the overhead of a label per account.

A related idea is doing the opposite: adding a "vouch" label on account once they have established themselves in some way. Labels are public, and more sophisticated reputation systems might want to remain private / opaque in the cat-and-mouse game of spam and bots. But some basic "vouch" label could be a basic anti-abuse measure.

[Bossett]

Mostly off-topic, but thoughts while trying to implement this using a 'keep track and add/remove' system to kind of force this in without the attribute:

First-party support for 'new' (and things like creation date, etc.) would be much better than my method, because you could enforce 'oh you can't just randomly hide these people', and I like the idea of 'vouch' actually being emergent (i.e. follow-of-follows) - but kinda digressing.

What I'm actually trying to do is flag handle changes as new - the impersonation attacks have been (in part) from older accounts renaming themselves. I'm not sure that that will make sense as a native function, and my second use-case is labels for current events (and similarly: spoiler tags) - so I think there are extended use-cases that don't make sense 'native'.

fwiw - I would love the negation concept to be traded for an expiration concept (i.e. no more neg: f, just expire:now) longer term, so there's only one pathway to check if a label should be removed; which then favours the 'clobber the record' approach as it's more of an update.