spec: Add penalize notifications.

[JoeGruffins]

part of #444

It was discussed that the notification be tried on reconnect, and to add it to connect, but I thought just adding it to the connect response would be enough/better.

Also:

message (e.g. state connected to complete swaps or risk further penalty or loss of reg fee!)

I think can be hard coded into the client, since it will be true for all bans

Can be viewed here

[buck54321]

A connected websocket connection is specific to an account, so the accountid field is superfluous.

[JoeGruffins]

My thinking was that the signature would be meaningless after the fact unless the accountid was included. While you could prove that a ban was dealt out from a particular server, you couldn't prove to whom it was directed. Although for simply verifying the server and communicating, it is not needed. I will take it out since there may never be need for the ban receiver to prove they were banned.

[JoeGruffins]

I guess someone could reuse one of these messages though, if it didn't have the to whom. The signature will check out, only the timestamp will be old. Can that in any way be used as an attack vector? OK because wss is safe?

[buck54321]

My thinking was that the signature would be meaningless after the fact unless the accountid was included.

That's a good point. We can leave it for now and decide on later updates what's needed for the new system.

[dnldd]

Looks good.

[buck54321]

If this is going to be an object, the object will need to be defined. Can you define the object separately and just reference it here and in the penalty notification?

[JoeGruffins]

Is this how you mean?

[buck54321]

Yes, but the sig would not be a field in the object. It would stay as a field in the penalty payload.

[buck54321]

You'll need to describe the serialization.

[JoeGruffins]

As in how many bytes per field and the order?

[JoeGruffins]

I found a few different patterns, but will just adding the size of the fields be sufficient in this case? Should there be a separate Penalty serialization?

[buck54321]

I'd personally prefer a serialization for the Penalty object. For the penalty payload you wouldn't need a whole serialization description table, because you could just say sig || string || hex-encoded signature of the serialized Penalty object.

I found a few different patterns, but will just adding the size of the fields be sufficient in this case?

In this case, since all of the fields of the Penalty object are included in the serialization, you could try to combine them into one. I think the only place that's done so far is for the order prefix description, and I have mixed feelings on how well it works. The descriptions needed for serialization is often quite different than a description suited for the JSON field, so you'll need to combine the information carefully to avoid confusion.

[JoeGruffins]

The test failure happened because I pushed a commit with an unintentional change. I rebased after that but the tests did not re-test and the failure remained.

[buck54321]

Looks good. A couple last touchups though.

Would you please add entries in the table of contents in README.mediawiki.

** [[community.mediawiki/#Penalization_Notification|Penalization Notification]]
*** [[community.mediawiki/#Penalty_Object|Penalty Object]]