feat: temporarily deactivate sending of pre-messages #7712
Conversation
link2xt
force-pushed
the
link2xt/rrozwkswwqtn
branch
2 times, most recently
from
0422ce8 to
391db5f
Compare
link2xt
force-pushed
the
link2xt/rrozwkswwqtn
branch
from
391db5f to
fd8f0ba
Compare
| /// | ||
| /// It is currently enabled only in tests. Once users upgrade | ||
| /// to be able to interpret pre-messages, the flag can be removed completely. | ||
| SendPreMessages, |
There was a problem hiding this comment.
Could we instead replace this hardcoded PRE_MSG_ATTACHMENT_SIZE_THRESHOLD with a Config key and make it, say, 1M (instead of 140K) temporarily? This way at least too huge messages won't eat traffic on the receiver side.
But overall the problem is that someone can fork Core and remove this limit or increase it, would be good to add a UI to download messages from the download table not immediately, but when the user decides, to be able to communicate with such modified clients smoothly
There was a problem hiding this comment.
I don't quite get what you mean, correct me if I misunderstood you.
Do you suggest to make PRE_MSG_ATTACHMENT_SIZE_THRESHOLD configurable instead of having a config key for completely enabling/disabling it?
This way at least too huge messages won't eat traffic on the receiver side.
Compared to disabling the feature entirely? And on what receiving side new clients or clients before pre-messages?
But overall the problem is that someone can fork Core and remove this limit or increase it, would be good to add a UI to download messages from the download table not immediately, but when the user decides, to be able to communicate with such modified clients smoothly
Clients should not modify/increase/customize the PRE_MSG_ATTACHMENT_SIZE_THRESHOLD const. It is out of scope to care for clients/forks that break compatibility willingly and without communicating with upstream.
There was a problem hiding this comment.
Do you suggest to make
PRE_MSG_ATTACHMENT_SIZE_THRESHOLDconfigurable instead of having a config key for completely enabling/disabling it?
Make it configurable, but not in UIs, just in Core. Maybe even add a test on what happens if a client with greater size threshold sends a message to us.
This way at least too huge messages won't eat traffic on the receiver side.
Compared to disabling the feature entirely? And on what receiving side new clients or clients before pre-messages?
Yes, if we disable the feature entirely, updated clients will receive all messages fully, but if we increase the size threshold for pre-messages, at least very huge messages won't be auto-downloaded. And for old clients the "empty message" problem will be solved for messages with recoded images at least.
Closes #7711