My feeling is swim and theft are both close enough in behaviour that we should focus on them. I agree that inheritance is beyond scope at the moment. @peg is correct in that the forward capacity allows for all three cases. I made the case for the different pathways in my interface posts yesterday.

%XwpDpMc...

%YPkZMHo...

I think the UI dictates how the cases are handled, since the forward mesage types can be used in all 3 scenarios. I can see your point @mix as to why to focus on theft but I also think that the swim case can be dealt with in pretty much the same manner, except we can do extra things at the end (like switch identity, which yes may be a big nice-to-have rather than a needed).

If one of those happens to be an ssb secret then they can mess around with that, but we're not going to touch that because it's a less secure option, and also requires more messing around

@mix I'm not sure I get the reasoning, why is it a less secure option?

ask for your shards to be forwarded to a new identity

The thought just occurred to me. When we forward a shard to an identity, there is still nothing stopping them sending the shards to the original identity. It might be useful to lock off in the UI any shards that have been sent that also have a corresponding forward message. Actually here we have another difference between swim and theft, because if we recover in swim, the old identity is still secured and they might not want to have those shards locked off. Whereas in theft you most certainly no longer trust the old identity, so you want to stop people from being able to send the shard back to the old identity.