Decide message size limits and options

[miguelfreitas]

I'd like to discuss some message size limits we should implement in twister-html.

Background:

• as explained here raise char limit to 256 twister-core#76 (comment) there are some limits on bencoded post size (counting text octets, possibly more than utf8 chars for non-latin langs, and extra fields overhead).
• as of today, with this commit miguelfreitas/twister-core@54b1d9e the 140 characters limit was mostly removed from twister-core. however posting arbitrary long posts will cause then to be rejected by the network as pointed by @dryabov here miguelfreitas/twister-core@54b1d9e#commitcomment-16853339
• @dryabov is correct in pointing that it is much easier counting utf8 characters in frontends (twister-html) than octets of the bencoded post.

so i'd favor some reasonably agreed limits like the suggested here miguelfreitas/twister-core#76. The 256 chars limit was endorsed by @gubatron @kseistrup @abiliojr @Qqwy @lohang and @jpfox (iirc @blog2read voted for 1024)

So my current suggestion (for discussion!) is:

1. Implement an user-defined limit on twister-html on maximum characters that should be shown on received twists. My vote is that this value should be 256 by default. So we'd have a "soft" limit we may easily change in future without protocol breakage.

2. Should we display the remaining characters of the post when user clicks to expand it? Or just clip it for displaying both collapsed and expanded? That's also a good point for discussion.

3. Implement warnings on text editing to report when 140 characters are reached ("older twister clients won't show this post entirely") and 256 characters ("this post is too long, it may be refused by some nodes and not appear on mentions")

4. The nice post preview added by @slr could use different colors for the first 140 characters, like twitter does.

5. The DM never really had a 140 characters limit. We have a 2048 byte limit for the encrypted total size, so it's hard to know exactly what the real limit is. Maybe increasing it to 256 or 512 should be fine (some sites claim chinese uses, on average, 3 bytes per utf8 char).

[slr]

1. yep.
2. user-defined.
3. yep.
4. yep.
6. I request a new transport layer for twister instead torrents.

amazing, I totally agree with @slr

[black-puppydog]

1. yes
2. user-defined
3. yes
4. yes
5. the longer the better. while in public posts a limit can be argued to be a feature, in private conversations it is just a nuisance

@tasty's view on 6) is quite radical 😛

[ca333]

1. yes
2. yes (user clicks on expand) if point 1) yes
3. yes
4. let user configure preview highlighting
5. 256 and if 75% of last X sent/received posts reach +90% of size-limit[256] softlimit adapts itself to 512

[stman]

1. Yes
2. Yes (Having a user-setting corresponding parameter that user could change would be cool)
3. Yes
4. Yes
5. The longest the better. Ideally unlimited.

[Tschaul]

1. Yes. 256
2. 512

[jpfox]

1. yes 256 fine
2. possibility to have post in full size directly would be fine
3. & 4) three colors is an other idea: black for 140 first, blue 141->256, red after 256
4. 512 if possible

[dryabov]

I'd keep 140-chars "soft" limit with a much higher "hard" limit (something about 1000 chars, for both public and DM messages).

[miguelfreitas]

@dryabov the hard limits are already there (see my first comment). it is just that is not simple for the twister-html to guess what the final bencoded size will be, therefore the need to stipulate some sane "soft" limits that are easy to enforce and understand.

[slr]

btw do we need to have in mind that there's situation possible in which a twist has both .msg and .rt fields filled (aka retwist with comment)? .rt also needs to be counted in the end, right?

[miguelfreitas]

right. so maybe we should better still limit the .msg to 140 characters if .rt is present.

[slr]

@miguelfreitas or maybe we need to completely drop the idea to have it both in one twist and try to fetch quotes like we do it with shortened URLs or like Twitter does it nowadays. I'd like to use @tasty\123 still and it will be useful for this case.

[Tschaul]

+1 for tastys idea. Don't like the backslash though. Why not the same format as for shortened url twists? We'd need the peek feature of twisterd then also anyway. Also rendering such twists is problematic, for example if there are mupltiple mentioned twist in one twist.

The easiest way out of this, however, is probably to drop support for rt with comments

[slr]

Don't like the backslash though.

my bad. of course I want forward slash — @tasty/123. see #353 also.