Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decide message size limits and options #352

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

Decide message size limits and options #352

miguelfreitas opened this issue Mar 26, 2016 · 14 comments
Labels

Comments

@miguelfreitas
Copy link
Owner

@miguelfreitas 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
Copy link
Collaborator

@slr 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
Copy link
Collaborator

@myleneb myleneb commented Mar 26, 2016

amazing, I totally agree with @slr

@black-puppydog
Copy link

@black-puppydog black-puppydog commented 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 😛

@ca333
Copy link

@ca333 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
Copy link

@stman 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
Copy link

@Tschaul Tschaul commented Mar 28, 2016

  1. Yes. 256
  2. 512
@jpfox
Copy link

@jpfox 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
Copy link
Contributor

@dryabov 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
Copy link
Owner Author

@miguelfreitas 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
Copy link
Collaborator

@slr 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
Copy link
Owner Author

@miguelfreitas miguelfreitas commented Mar 29, 2016

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

@slr
Copy link
Collaborator

@slr 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
Copy link

@Tschaul 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
Copy link
Collaborator

@slr 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
9 participants
You can’t perform that action at this time.