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

Increase default message size #4

Closed
ghost opened this issue Feb 5, 2016 · 9 comments
Closed

Increase default message size #4

ghost opened this issue Feb 5, 2016 · 9 comments
Assignees
Labels
Milestone

Comments

@ghost
Copy link

ghost commented Feb 5, 2016

140 characters is an archaic limitation that twitter only used so that single tweets could fit in an SMS. it's equivalent to not allowing lines of source code over 80 characters because then they won't fit on a punch card. Even doubling it, or 256 characters, would be an awesome improvement.

@buckket
Copy link
Owner

buckket commented Feb 6, 2016

The message size is not really limited. Technically the message can be as long as you want. It’s just the client that shortens longer strings per default, because I wanted people do stick to short and pregnant status updates.

Implementing a config option for when the shortener kicks in may be an option, but in general I’d like to stick to the default value of 140 characters, while also warning the user.

@ghost
Copy link
Author

ghost commented Feb 7, 2016

I understand the technical limitation. I'm suggesting the change because I feel there are important design implications to keeping the default at 140.

Increasing the default setting, and recognizing that many people won't change it, would allow for greater expressivity by default. I think going the App.net route (256 characters) or even giving people enough space to write a solid single paragraph would open up different forms of interaction, encourage clarity while still discouraging verbosity, and explore an affordance that isn't the route most people go.

Just a suggestion. I appreciate the attention you're giving these tickets.

@jomo
Copy link

jomo commented Feb 7, 2016

Hmm, I like twitter's 140 character limit, although a little more probably wouldn't hurt.
However I don't think links should fully count towards the limit, otherwise people will resort to using all sorts of crappy URL-shorteners.
Twitter solved this by giving links a fixed 'character count' of 23 while displaying the full link (although they still use a shortener for tracking or whatever).

@plomlompom
Copy link

There's already some thinking about putting metadata by convention into individual messages, which would further blow them up in length. It's unrealistic to keep the length of raw message texts below 140 characters that way, but how about this:

Push as much individual-message metadata as possible to the end of the message text, so that even naive clients (that don't interpret metadata) may display the most human-readable part of a message before their message-length cut-off point. Some optional separator, such as "/META" or a second in-line "\t", could be defined (by convention or even protocol) beyond which only metadata is supposed to lie in a message, so that clients might decide to only directly display as text the message part preceding this separator.

Beyond this separator, there could be space-delimited metadata tokens defining the feed or individual timestamp therein to which a message is a reply (such as "REPLY:http://example.org/twtxt/bob.txt#2016-02-05T19:44:54.340257+00"), or string replacement operators to blow up parts of the pre-meta-separator message text to URLs subject to link parsing (i.e. "REPLACE[@bob|[@http://example.org/twtxt/bob.txt"]), multimedia to optionally append to the message (i.e. "IMAGE[http://example.org/cat.gif]"), whatever. The point is to separate the parts of the message of value to someone just skimming the text from those that may be used to enrich them with metadata, to keep the former short, and allow the latter to expand to whatever sizes the weight of future extensions may demand.

@erlehmann
Copy link

@plomlompom or you could just use the Atom XML standard https://tools.ietf.org/html/rfc4287.

@otherjoel
Copy link

@erlehmann I second this. Atom is perfect for this job. A huge amount of work went into creating this standard, it’s well-defined, and there are validation tools and clients already out there and in widespread use.

@buckket
Copy link
Owner

buckket commented Feb 13, 2016

One thing I’d like to add here first: Currently the soft limit of 140 characters only kicks in after all the processing has been done. The raw tweet can be way longer than that what you’re actually seeing. Exactly the opposite applies when creating a new tweet. What you type is what get’s counted.

Coming with the next release the limit will be configurable.

It’s will be up to the user to decide how to consume twtxt’s content (micro- or not-so-mirco-blogging…) and what limit appeals most to ones personal taste. The default of 140 characters will remain though.

@buckket buckket added this to the 1.2.1 milestone Feb 13, 2016
@buckket buckket self-assigned this Feb 13, 2016
@quite
Copy link
Contributor

quite commented Feb 17, 2016

Ah, sorry for commenting on closed issue. Didn't catch this one before it went in. I thought that perhaps, the input and output character limit could be two separate options? So I can always read 1024 characters long messages, but possibly limit myself to producing 140 char long ones... https://en.wikipedia.org/wiki/Robustness_principle

@buckket
Copy link
Owner

buckket commented Feb 17, 2016

Right now the warning about tweeting more than 140 characters is still in place. It’s independent of what character_limit you set. You might be right, that it’s better to make this configurable as well, or remove it it completely. Will think about it.

@buckket buckket reopened this Feb 17, 2016
@buckket buckket modified the milestones: 1.3.0, 1.2.1 Feb 17, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants