In might not be *the right* way depending on the use-case, as it'd be over-kill and potentially have a coordination problem for ad-hoc chains of signatures where a user may only co-sign events randomly. In that setting a derivative of "boost" would probably be adequate.

It'd only be proper for regular group signatures, like for an entity or committee.

FROSTR uses these threshold sigs, could check out that project or maybe consult with @bitcoinplebdev 

This is probably the hard, but right way. Although I would assume at the cost of more rounds. Can you send me some documentation you'd recommend I look into?

nerd2ninja

Would require first a one-time attestation to membership, but all forward events would be verifiably linked to your key

nostr

Protocol Design

A threshold signature

Would require first a one-time attestation to membership, but all forward events would be verifiably linked to your key