@cft

That's funny, I was just looking at the encrypted message validation today. The regular expression from ssb-validate requires that it ends with .box, but specifically doesn't check the end of the string. There shouldn't be any problems with .boxV2, as far as I understand.

@cft

At the core this is a layer violation: the pubs should not do deep packet inspection, just ship the content field unexamined, in a future-proof way, or?

Disclaimer: the only thing I know is that I know nothing, so don't take my word for this. My intuition, however, is that this likely has something to do with how how the secure-scuttlebutt package automatically unboxes private messages. I think secure-scuttlebutt's unbox tries to use ssb-keys' unbox, which calls toBuffer, which looks like it should return the correct base64 contents, but my guess is that it's erroring out somewhere and cowardly refusing to replicate.

I think a stack trace from a pub (or any replicating node) would make debugging this quite a bit easier. I'll see if I can reproduce the bug this week, let me know if you beat me to it and find the offending code.

Others who might be interested and/or knowledgeable: @dominic @arj @cel @cryptix

@cft

I think I've run into the same bug as you! I've opened an issue and made a small change that I believe resolves the issue. My understanding is that when the unboxing code runs into a decryption error it crashes Scuttlebot with an uncaught exception. I ran into this issue while prototyping blob content, and while I can't tell why your content string would be invalid it sounds like the same symptoms from changes to the content property.

Do you think we might be running into the same bug?