Add blocking flag to contact message

[SuperTux88]

Diaspora currently doesn't federate this information, which causes a lot of bad UX (users writing a comment which then immediately gets deleted again). But this information is not really "secret", because a user can just like a post and when the like gets deleted again, the author of the post probably ignores them (so only bad UX with no real win).

The main reason why I didn't want to have this federated was, that federation was really unstable, and we had already inconsistent sharing states, and I didn't want a user to be stuck in blocking state, when the other person already unblocked them. But federation improved a lot and works quiet stable now. That's why I think we can start federating this now.

[cmrd-senya]

Is it actually possible to miss unblocking message? What do we do in this case? Since there is always only one recepient for this message it is possible to reliably know whether the message was accepted or not (the status of the post request to the remote receive route). So if we unblock the person but the remote pod doesn't accept it for whatever reason (e.g. pod was down at the time of unblocking) then the unblocking has no effect on the remote pod, only on ours.

We could somehow ensure that the unblocker message gets to the remote pod, e.g. by keeping resending it forever while the remote pod is online until the remote node responds 200.

Another approach that I think of, is to make the blocking UI informative, but not prescriptive. What I mean is that when a pod knows about the remote block it doesn't stop you from sending messages there, but it just shows a note at the UI "This user seems to be blocking you. Your message is likely to be rejected". Even if we have something broken at the federation level and miss the unblocker for some reason, that will still allow people to communicate.

That is out of scope for this PR, but you say that the federation is reliable, but I think that we can't still trust it for 100%, so it is worth considering of what do we do in case of its failure.

[SuperTux88]

but you say that the federation is reliable

I meant it's reliable enough, we will never have a 100% in a federated system. But in the past we had a lot of wrong sharing status of other people (probably also because of a broken block feature that destroyed the contact status). But I think today the contact status also works stable enough (which is already important for being able to send private messages), so I think we can use it for blocks too.

That is out of scope for this PR

Yes, we should think about that when finally adding it to diaspora, this PR only adds the possibility to the protocol.

e.g. by keeping resending it forever

I don't think we should retry it forever. We would need to store that somewhere and I don't think the problem is that big to make it worth the extra complexity.

We retry now 10 times, which ends in about 16-17h (which is enough for posts). But you're right, contact messages are more important (not only for blocking), so we should probably double the retries (20 times) anyway, that would end in retrying for about 2 weeks. If a pod is down/unstable for more than 2 weeks, it's probably bad UX anyway, so if a blocked-state stays stuck, I think that is the smallest problem of the users on that pod. When they then use the migration feature, all contact-messages will be resent, so the blocked-state is reseted.

Another approach that I think of, is to make the blocking UI informative, but not prescriptive.

I think we should block the UI, if we know the user is blocked (it has also the advantage that we can handle local blocks, where we are 100% sure the same way as remote blocks in the UI). If we see that this is a big problem and users are constantly blocked by a wrong state, we can always loosen it and make only a note that we think the user is blocked. But again, out of scope here for the protocol-part.