Decide message size limits and options #352

Open
miguelfreitas opened this Issue Mar 26, 2016 · 14 comments

Comments

Projects
None yet
9 participants
@miguelfreitas
Owner

miguelfreitas commented Mar 26, 2016

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

Background:

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

This comment has been minimized.

Show comment
Hide comment
@slr

slr Mar 26, 2016

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

slr commented Mar 26, 2016

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

This comment has been minimized.

Show comment
Hide comment
@myleneb

myleneb Mar 26, 2016

Collaborator

amazing, I totally agree with @slr

Collaborator

myleneb commented Mar 26, 2016

amazing, I totally agree with @slr

@black-puppydog

This comment has been minimized.

Show comment
Hide comment
@black-puppydog

black-puppydog Mar 26, 2016

  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 😛

  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

This comment has been minimized.

Show comment
Hide comment
@ca333

ca333 Mar 27, 2016

  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

ca333 commented Mar 27, 2016

  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

This comment has been minimized.

Show comment
Hide comment
@stman

stman Mar 28, 2016

  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.

stman commented Mar 28, 2016

  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

This comment has been minimized.

Show comment
Hide comment
@Tschaul

Tschaul Mar 28, 2016

  1. Yes. 256
  2. 512

Tschaul commented Mar 28, 2016

  1. Yes. 256
  2. 512
@jpfox

This comment has been minimized.

Show comment
Hide comment
@jpfox

jpfox Mar 28, 2016

  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

jpfox commented Mar 28, 2016

  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

This comment has been minimized.

Show comment
Hide comment
@dryabov

dryabov Mar 29, 2016

Contributor

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

Contributor

dryabov commented Mar 29, 2016

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

@miguelfreitas

This comment has been minimized.

Show comment
Hide comment
@miguelfreitas

miguelfreitas Mar 29, 2016

Owner

@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.

Owner

miguelfreitas commented Mar 29, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@slr

slr Mar 29, 2016

Collaborator

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?

Collaborator

slr commented Mar 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@miguelfreitas

miguelfreitas Mar 29, 2016

Owner

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

Owner

miguelfreitas commented Mar 29, 2016

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

@slr

This comment has been minimized.

Show comment
Hide comment
@slr

slr Mar 30, 2016

Collaborator

@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.

Collaborator

slr commented Mar 30, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@Tschaul

Tschaul Mar 30, 2016

+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

Tschaul commented Mar 30, 2016

+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

This comment has been minimized.

Show comment
Hide comment
@slr

slr Mar 30, 2016

Collaborator

Don't like the backslash though.

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

Collaborator

slr commented Mar 30, 2016

Don't like the backslash though.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment