Postel's Law in Development

This was a difficult parse, for being so short.

> Postel’s law, also known as the robustness principle, states that we should all be friends and try to get along.

No.

> It’s also occasionally harmful.

No.

> Lain wants to add chat messages to activitypub in pleroma. I think this could be cool, so I wrote some code for honk. Two implementations of the same concept? We’re gonna need some serious robustness, on principle.

What or who is Lain, what is activitypub, what is pleroma, what is honk, where did 2 implementations come from, what does serious robustness mean and what principle does it apply to? (if Postel, is the a redundant "principle" statement?).

> I could relax the parsing requirements slightly and accept it.

Then you pass on an empty mediaType when you know that's incorrect for the protocol? That's your problem, not his or an issue with the principle.

In that grueling "hour" you could have told your friend to fix their implementation, because you're going to make an assumption and it may have a mismatch in special cases. That's the story that could have been told. Instead it's "Postel's Law can hurt because I move fast and break things".

Inherent in Postel’s law is that you hold received messages to a lower standard than those you emit. Using your live receiver code to validate your output is incorrect, then, because you’re testing against the wrong standard.

The usual workaround for this is to have a control flag for the receiver that specifies whether it should accept nonconforming messages. When testing a transmitter, run the receiver in strict mode. In live operation or when testing the receiver, run it in lenient mode.

Reminds me of how we subverted Postel's Law to uphold Postel's Law https://medium.com/pageup-tech/update-on-driving-client-resi...