[glpatcern]

Inspired by @MahdiBaghbani

The suggested change is two-fold:

• rename the notification to CONTACT_REMOVED, to reflect the fact that it typically applies to a single pair
• tell apart two possible scenarios with an additional, optional property

For the two scenarios, consider an initial state as follows:

• Server A: user Alice has {Bob@B, Betty@B} as federated contacts
• Server B: user Bob has Alice@A; user Betty has Alice@A

Scenario 1. Alice stops collaborating with Bob.
A sends to B:

{
	"notificationType": "CONTACT_REMOVED"
	"shareType": "user"
	"message": "Alice has stopped collaborating with Bob"
	"user": {
		"userId": "alice@A"
		"targetUserId": "bob@B"
	}
}

=> B drops alice@A from Bob's contacts list only.

Scenario 2. Alice quits A's organization.
A sends to B:

{
	"notificationType": "CONTACT_REMOVED"
	"shareType": "user"
	"message": "Alice has left"
	"user": {
		"userId": "alice@A"
	}
}

=> B drops Alice from all users' list, i.e. Bob's and Betty's.

[MahdiBaghbani]

I read it through and mostly agree with it however during the implementation it would be subjected to changes so let's keep it open for the start of implementation to see how to modify it

[glpatcern]

Thanks @MahdiBaghbani, in fact already a suggestion at the last meeting was to rename localUserId to targetUserId, which I just did.

Otherwise I'd rather review/merge this change ahead of implementations, where we can still amend things if needed.