You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
perhaps this is not a limitation in textsecure-cli, but one in the underlying libtextsecure-java ?
i tried sending a message in varying sizes up to 2048 bytes by piping to textsecure-cli. the result is clipped after the 2000th byte.
since things like pictures and videos can be sent, clearly the underlying architecture supports larger messages. just wonder if textsecure-cli is being conservative?
also, it is useful to know this limit (2000 bytes) which does not seem to be declared in the sources. i also search in the sources available on github for libtextsecure-java and do not seem to find any clearly defined limits.
perhaps this is just a documentation issue.
The text was updated successfully, but these errors were encountered:
textsecure-cli has no limit on the message size. The clipping is done by the Android client when receiving the message. You can test this by sending a longer message to another textsecure-cli instance. However I wouldn't send too large text in the body that's not what it's made for.
For large data you can use attachments, they're not included in the message, but downloaded separately. The message contains only a link to the data.
perhaps this is not a limitation in textsecure-cli, but one in the underlying libtextsecure-java ?
i tried sending a message in varying sizes up to 2048 bytes by piping to textsecure-cli. the result is clipped after the 2000th byte.
since things like pictures and videos can be sent, clearly the underlying architecture supports larger messages. just wonder if textsecure-cli is being conservative?
also, it is useful to know this limit (2000 bytes) which does not seem to be declared in the sources. i also search in the sources available on github for libtextsecure-java and do not seem to find any clearly defined limits.
perhaps this is just a documentation issue.
The text was updated successfully, but these errors were encountered: