allow NIP-44 to encrypt more than 65535 bytes #1907
Conversation
|
There is no need for the 0 length signal. You can just check if the whole message is bigger than 65603 and go for the 4-byte length. |
|
Meaning.. current systems will misread the length bytes and will not be able to decrypt anyway. So why bother. |
Sounds good to me. Is that number 65603 exact? |
|
I am not sure. I got from the documentation. We need to get some tests for -1, 0, and +1 lengths from the 2-byte limit to ensure everyone is on the same page |
But we'll go with my proposal or yours? |
|
@vitorpamplona I think the current proposal is slightly easier to understand and the code for it looks clearer, and it's easier to debug for legacy implementations (you get a length=0, it raises some eyebrows). So even if it wastes 2 bytes I think we should go with it. Yay or nay? |
|
Makes sense. Has anybody coded this? I am still stuck in my outbox refactoring :( |
Yes, this is the diff:
That's good to hear! |
This is backwards-compatible and no one has to change anything if they do not care about bigger messages.
The only reasonable case where this necessity has shown up so far was signing of big kind:3 lists via NIP-46.