I was thinking about this and without reinventing the wheel perhaps we can use, as you stated in point #1, child private keys via BIP32.
Because the creation is deterministic, we can invalidate a key simply posting with the next one, avoiding to trust a separate db/system.
But this require some more things:
metatada should include the xpub (necessary to check the public keys sequence)
relays should remember the last valid pub key and reject new notes with old keys
clients have to remember the last valid pub key and reject new notes with old keys
clients have to aggregate content using the xpub as reference
Because a relay can vanish in any moment we have to think how to manage the history rebuild too; because, now if I'm not wrong, one can create and sign an event in the past. Perhaps timestamping (es. via https://opentimestamps.org) could give some benefit, but also add too.
I was thinking about this and without reinventing the wheel perhaps we can use, as you stated in point #1, child private keys via BIP32.
Because the creation is deterministic, we can invalidate a key simply posting with the next one, avoiding to trust a separate db/system.
But this require some more things:
Because a relay can vanish in any moment we have to think how to manage the history rebuild too; because, now if I'm not wrong, one can create and sign an event in the past.
Perhaps timestamping (es. via https://opentimestamps.org) could give some benefit, but also add too.
A lot of things to think about :)