If you have a few minutes left somewhere could you shine some light on the priority thing.
When a node with a low upstream bandwidth is trying to send or relay lots of big messages (e.g. GetSuccess responses with immutable data chunks) that would take an hour to upload, that’s often useless: In an hour, the recipient might not be interested in the message anymore. And I certainly don’t want to wait an hour for a website to appear in my browser!
So eventually we’ll have to make the different network layers share detailed information about what bandwidth they have and what bandwidth they need, so they can make smarter decisions about whether, when and where to send messages.
But for now … we just drop messages! We introduced the priorities so that e.g. we never drop messages that are needed for maintaining the network structure itself. But less important ones are currently just dropped when the load is too high.
It’s not as bad as it sounds:
Redundancy - resending messages via different routes, storing data on multiple nodes, not trusting individual nodes etc. - is the responsibility of the upper layers anyway, and they will always have to deal with it: If a user kills their vault or gets disconnected, all the messages that node had in the queue will also be lost. The current crude prioritisation approach just adds a little more unpredictability of that kind.