Updating set elements from command line

[Eric <evil.function@xxxxxxxxx>]

Is it possible to update set elements outside the packet path?
https://wiki.nftables.org/wiki-nftables/index.php/Updating_sets_from_the_packet_path

I'm using a blacklist set, which is populated from an external source and
updated nightly in a cron job.  Current set definition is:

    table ... {
        set doh_ipv4 {
            typeof ip daddr
            counter
        }
        ...

My update script currently maintains counter values by a kludge,
dump-flush-repopulate:

    # Dump the current set in json
    json=$(nft -j list set inet firewall doh_ipv4)
    ... select out the current counts into a map indexed by IP ...

    ips=$(curl https://some/ip4.list)
    nft flush set ...  # Thus losing all statistics.
    for ip in $ips; do
        ... fetch $packets and $bytes from map using $ip ...
        nft add element ... { $ip counter packets $packets bytes $bytes }
    done

I would much rather use timeouts to remove old elements, thus eliminating
the kludge.  First, redefine the set with timeouts:

    table ... {
        set doh_ipv4 {
            typeof ip daddr
            counter
            flags timeout
            timeout 3d
            gc_interval 1h
        }
        ...

Then my cron script would just run through the list of addresses something like:

    ips=$(curl https://some/ip4.list)
    for ip in $ips; do
        nft update element ... { $ip expires 3d }
    done

But...

$ nft -v
nftables v1.0.2 (Lester Gooch)
$ nft update element ... { 1.1.1.1 expires 3d }
Error: syntax error, unexpected update
update element
^^^^^^

The problem is that 'update' only appears to be implemented in the packet path,
according to the wiki article mentioned at top.

So again, is there some way to get 'update' behavior from the cli tool?

-
As an aside, this would solve two other problems with my current scheme:

  1) There's a windows during the update after the set is flushed, but before
     the element is added back and queries can sneak past (that window is only
     5-10sec, so not a real issue);

  2) Sometimes blacklisted hosts "bounce" in and out of the downloaded list
     (this is a real issue, as these hosts might come back online and bypass the
     firewall for the 24h period between cron updates, having a 3d expiration
     would be a significant mitigation).