Increase Post Character limit to 500. #2551
Comments
jcx616
changed the title
|
would def need to have the show more to be included, -- could be a neat update if it increased when we get improved threading |
|
As always, I vote for "let the user decide". If people want to write more, sure, go ahead. But everyone should get to decide how much they want to see as a max per-post as well. So if you write a lot, your post may just get cut off with a "(more)" button to those who don't want to see long posts. |
|
As a counterpoint - I think all these are perhaps better solved by leaving the limits low, and implementing good threading/authoring, if this is indicated in the main timeline, a user can now click in if they're actually interested. This kind of gets all the same outcomes, but doesn't require changes to the core timeline experience and 'feel' of the app (there is a lot of friction in asking a user to interact to consume more content, a thread implies that'll be high-value, but an extra 200 chars...?). There may be a compromise position - leave top-level posts alone, but allow 2nd/3rd posts by the author (authored at the same time as the thread) to be 500-1000 characters |
Will absolutely be an improvement when we get the ability to post a thread with multiple posts at once |
FYI, I accidentally discovered 2 days ago that Mary's Skeetdeck already does this :) |
|
In a thread, you can post up to 500 characters at a time. In Bluesky, it's inconvenient to post the same post in two or three separate posts. It would be nice to support 500 characters |
|
bc posts can have keep the original part at 300, and then add the extra 200 after would also work but i do think 500 characters would be a huge qol improvement. i type a lot and often have to remove punctuation and spaces in longer posts if not the follow up is often only going to be 2-3 words. |
|
Not opposed, but I think all we really need is a (show more) button, which obviates the need to limit content length at all. I don't really have a strong opinion on how long the truncated/visible in the timeline/summary part of a post should be allowed to be. Most academic journals only allow 60 chars in a title (which I think is too short, but they get by), and most paper abstracts are longer than you'd want to display in your timeline on bsky so 🤷 Actually... why wouldn't you want abstract-length skeets? I feel like the length you want here comes down to how much you trust the algorithm. If you have a really freaking good algorithm you're going to want to read 90% of the abstracts in full. At the same time, "leave it to users" kind of isn't a feasible policy, because post authors need to know how much of their post is going to show, there needs to be some standard. |
Sounds dramatic, but I really think this is one of those small decisions that destroys the site or at least dramatically changes the tone. It's a microblogging platform, and that has a kind of social 'feel' - that's why I'd advocate for good threading, but a clear 'cut off' at 300 characters (i.e. that stuff treated as the 2nd thread item) to continue to encourage a readable timeline. "Read more" I think will encourage an unreadable timeline - snippet, snippet, snippet, etc.; vs. a catchy 300 characters, with more data below. (But going up to 500 doesn't seem like it would have the same impact, but it's a creep up, so it's a tricky design question - constraints contribute so much to the overall experience.) |
The standard is 300 chars. It can be assumed that most people won't change from the default, and any that set it to less than that understand that they'll be seeing a lot of "show more" and deliberately want that. |
|
I wanted to add with how long some fediverse and nostr usernames are like over 50 characters... it takes up so much space
https://bsky.app/profile/surfdude29.ispost.ing/post/3kzidy5nnvv24 |
|
I think we are very very unlikely to make a change like this. Having a character limit is a creative obstruction and a core part of the microblogging "modality" and form of media. Having longer-form content show up in-line changes the dynamics. It is totally fine and expected that folks will link out to longer form posts. It is also totally fine an expected that folks will build alternative modalities and experiment in the network with different obstructions. As some history, we already bumped the character limit in early days of the app; the current 300 char limit wasn't just a randomly arrived at number, it is an iteration arrived at from feedback. |
|
Similar to the Nostr example shared by Monica, could there be some kind of compromise when we @mention people? Can the username handles be taken out of the character count? The native ".bsky.social" takes up a lot of space. I have another idea coming about username handles, but I thought this particular point was also relevant here. |
The way this works for links is that they are shortened client-side, with the full URL in the facet, so the same way, the client could potentially do something like that with Nostr mentions, leaving them as "@npub1qweqweqwe..." in the post text (first n letters + "...") - it's not like anyone can tell them one from the other by the npub :D |
Do you personally feel that a person writing a dozen posts as a thread is a better user experience (for both the author, and viewers) than a "Read more" button? |
|
Actually I think that the character limit should be removed entirely, it's an idea that comes from a bygone era where text messages were 120 characters long and Twitter was a mini version of something people did called "blogging". @bnewbold, you admit yourself that people just screenshot text, create threads, etc. Can you elaborate on how it's a "creative obstruction"? I personally think it's just frustrating, and actually invites workarounds that hamper core functionality of the site (when somebody chooses a screenshot or another link, it makes searching for the post more inconvenient, and sometimes you don't wanna create a thread for one reason or another) |
He can't. That's just his stupid opinion or lame excuse. |
I share your viewpoint, but let's disagree without being disagreeable here :) |
Yeah, this already is a problem with crossposts from Mastodon via Bridgy. It cuts off not just the oversized part of the post, but it also has to cut off even more to add in a link to the Mastodon post and a message telling you to click it to read the rest. Which you then have to do and navigate to another site. Versus the alternative, of just having a "read more" button under it if it's overlength and you haven't increased your max post length. |
|
I think 500 has become the new standard. It's true that Twitter has only 280 but for pro the limit is: 10k So the recap: I think considering the above 500 is a good starting point. |
Many Mastodon servers have much higher than 500. It's server-configurable. Other servers display the longer posts even if they limit their own users, which is IMHO a suboptimal-though-functional solution (like most of Mastodon's solutions ;) ) |
Good to know, I am not super documented on the mastodon stack, didn't know that is configurable. The point I wanted to emphasize is that it seems 500 is a reasonable number since many social protocols today have that or a greater number as a limit. |
Agreed, though I'll reiterate that I think even better is to have a default and let users decide whether they what to deviate from that default, both in terms of what they can compose and what they want to see, with the knowledge that other users, depending on their settings, may choose to get a "(read more)" button or just have it hidden (I think "(read more)" is a good default choice). I IMHO always prefer user choice. I think we also should keep the bigger picture in mind. Right now ATProto is being used almost exclusively as a microblogging service, but the design allows it to be much more in the future. So we really should think about how, with a firehose of different types of content available, we let users choose what they want to see and how. |
|
I think that 300 to 500 is a good increase without needing to add the "show more" button, I don't think it would disrupt the flow of microblogging personally. For example, this is the current limit (300 characters): And this is the proposed increase (500 characters; 300 characters plus 200 over): Visually speaking I don't see much disruptiveness, I do admit it is just the word "test" repeated several times but as far as I am concerned as a user, it looks manageable to display. The problem would be if some posters used a lot of line breaks, making the post look much taller. I suppose that the "show more" button would need to be implemented in this cases, where the post has an X number of line breaks.
I oppose to removing the limit entirely because this is the internet and people will definitely post the entire script of Bee Movie the moment they realize it. A 500 character limit seems good enough, as it would already allow companies to cross-post content a bit better without being cut short that badly. One thing to note would be that it would suck if the "show more" button revealed just 1 or 3 words that happened to go over the viewable limit. Some level of "orphaned words" system would need to exist |
|
This is something that I think should be considered: Some may want to configure their PDS server's character limit to more than 500 or their video length limit to more than 1 minute. Is there a way for someone to do that with their own PDS server? If so, where could we find documentation? If not, can we please consider this as a possible feature to do for PDS servers? |
What do you mean by this. I can't imagine this would be any different than just making the char limit 520. In an ideal world, would it not be a character limit, but instead a size/line limit? (In an even more ideal world, would it be a cognitive load limit, where a post should not take longer than 5 seconds to appreciate) |
In my head, it is not going over the limit of 500 that enables the "show more" button; it would be the number of lines the post has. A post with several words with line breaks between then will hardly use up 500 characters, but will monopolize screen space. For those cases the "show more" should appear. However the "orphaned word" system would check if the string hidden in "show more" is just a word or two, and if it is true, disable the "show more" button and just display the entire text. |
|
I don't like Threads and Mastodont also because of the large character limit. I don't like long posts. Please don't change it here. The reason I love microblogging is because you can write short and concise. Long posts are tiring. |
|
Reactdev did a 40 post thread, and it was the worst experience ive had on bluesky trying to read it - i got lost multiple times on my mobile app trying to keep up with every post. (https://bsky.app/profile/react.dev/post/3l72fmroqcm2r) Im guessing it was 40 posts due to character limit when it could of been contained to like 20 posts if we had a character limit increase. its frustrating- and the thought of having to break apart a pre made post bc it hits character limit is even more frustrating. as more users and news agencies start multi posting, it looks really bad when you see a news agency post get cut off because its been automated and half the title is missing in the post due to character limits not being consistent between sites. |
|
The argument "we should make it larger because it better accommodates third parties (react.dev, fedi handles, etc.)" is a losing battle - there's no limit you can't justify that way, and the platform is always playing the <other guys post length + 1> game |
|
Chiming in with a slightly different perspective: the 300 character limit feels like a relict of a time when microblogs were distributed via text message and screen resolutions were fraction of what they are today. While I agree that improving thread composition will help publishers/creators, threaded posts increase the cognitive load on users reading the content by adding buttons, framing, and other visual elements. With this in mind, a 500 character limit is reasonable. It leverages the additional screen space available on modern mobile devices to present complete, nuanced thoughts while reducing the space occupied by framing/timestamps/engagement buttons. This, in turn, would be expected to yield a performance benefit throughout the stack (eg faster scrolling, more content per JSON object) |
|
If it increases the cognitive load of the user, then they can make it where there's a "reader mode." That is, it automatically takes the posts and puts them into scrollable paragraphs without any lines or anything that clearly separates the posts (or at the very least, have a faint line that separates the posts). If they want to like or repost a specific post, then they can simply tap on it and the buttons appear (or maybe the like, repost, etc. buttons would be faded out until you tap on the individual post). I can understand if there's pushback with respect to this because it may seem unnecessary. However, even if the increase happened, there will still be a need for it because it's not going to eliminate threads. Threads are an inevitability, so regardless of what happens, I think this is a good option to have. |
|
I like the idea of a reading-mode for threads that removes the buttons and usernames/avatars from immediately connected replies from the same author unless hovered! I do also echo the sentiment of wanting a higher character limit, 500 just feels like a more comfortable amount to write a contained paragraph inside of. Either way, the only other addition I'd like to add is a request for some sort of UI element that indicates the OP replied directly to the first post, to indicate that it's a thread. Youtube does this in the comments section, you can clearly see whether or not the replies to a comment has a response from the creator of the video: And I think a similar UI element could be used to indicate whether or not one of the immediate replies to the post are from the post author (thus indicating it continues on as a thread) or just replies from other people: Currently people tend to get around this by adding "(1/?)" to their posts while creating a thread, but sometimes you might add something to a post making it into a thread after-the-fact, and also with the short character count I often find that I don't have enough character space to even add a number indication! A built in indicator that the OP continues the thread would alleviate a lot of this. |
|
I sometimes cross-post to both Bluesky and Mastodon and expect to be doing that for years, so it’d be such a major quality of fedi-life if I didn’t have to write for two different char-lengths. |
|
Another thing that I realized is that according to my personal feeds, very few people tend to use up all the 300 characters. It seems that the average is around 200 to 230 characters, which would be like 2/3 of the available characters, so if we estimate this value for 500 characters, most people would be making 330 character long posts, which is actually close to the current limit (assuming that this percentage will carry over with this hypothetical increase) Basically, even though the topic here is "increase limit to 500", it doesn't mean all posts will now be 500 characters long. I don't see how it will disrupt the microblogging feel of the site |
|
My perspective is that even 500 characters is too low now. As one user said, the small character limits are a relic of a dated limitation. On the non-mastodon fediverse side, software is allowed to post extremely high amounts (my instance on akkoma allows for 65536 characters), and while most of the time users use less than 500 characters, the times where post warrants even 1000+ characters allows for nuance and discussion when needed. It is appreciated greatly. The UIs hide most of the text and allows the user to open them to see more if they want to. You can just ignore the post and move on if you don't want to read it or your cognitive bandwidth doesn't allow for that. As a non-twitter user, the threads people make feel like a work around that should not exist. For this reason, I would prefer to see the character limit increased not to 500, but to 5000+. |
|
Why are we spending effort on making threads usable when the point is microblogging? If increasing the character limit were to break the feeling of microblogging by encouraging longer posts, surely threads would too? If we're introducing arbitrary limits to prevent people from making longer posts, there should be some system to prevent people from making threads as well, given that they're just longer posts with worse UX. My corner of the Fediverse is mostly non-Mastodon and generally defaults to character limits in the thousands. Running a query against my database for instances that are on software with high character limits, most instances had an average post length of around 110 (excluding empty posts, replies, and quote posts): labyrinth.zone (5000 limit) at 103, snug.moe (3000 limit) at 110, mk.absturztau.be (8192 limit) at 96, tech.lgbt (1024 limit) at 137. For the largest number there, tech.lgbt, only 10% of posts (excluding empty posts, replies, and quote posts) are over 300, and only 4% over 500. I see no evidence that raising the post limit, even to tens of thousands, would raise the average length of posts beyond what is still considered microblogging. Instead, it seems like culture has a much stronger impact on post lengths. If there are people who want to make 500 character posts every now and again, and we're willing to put in effort to make threads easier to use so they can make those longer posts, I don't see why we shouldn't let them make their 500 character posts if there is no indication that people will inflate their average post length beyond the existing effects of threading. Even the people in this thread seem to understand the need for longer posts in a nuanced discussion! |
|
alternatively, i think having a separate field for hashtags might help? kind of like how there's a labels option now. could easily limit the number of hashtags, or the characters that can be used, but keeping the hashtags separate could help more people describe their situation/image/whatever, but the hashtags don't use up post character allocation so they can include any and all relevant hashtags to help people find (or avoid) the topic. i see a lot of posts that don't get tagged because the content uses up all the characters, and i feel that's an issue for a lot of accessibility reasons. |
That's part of Bluesky's atproto/lexicons/app/bsky/feed/post.json Lines 51 to 56 in 879a74f The issues for surfacing these in bsky.app are bluesky-social/social-app#848 in general and bluesky-social/social-app#6216 in particular. Some third party clients do support them already. |
|
Post length limits that aren't necessary for technical reasons are a mistake. Display length limits configurable by the user can keep everyone happy. |
|
Recently posted about this limit. Moving from FB, I like to have the ability to have a thought out thread on a discussion topic. 300 characters forces the "10 word answer" mantra of simplicity. if this is truly to be a platform where one can express themselves, then allowing for more than 300 words is a must. Why limit it at all? Just collapse it if it is over a limit |
|
The existence of labelers adds to the case for eliminating the character limit. If long text posts are allowed, someone who doesn't like them will surely create a labeler for them, allowing everyone who doesn't want to see them to hide them. |
brilliant use of labels |
|
Up to 1000-1024 would be optimal. Longer posts could damage microblogging atmosphere. But 300 symbols are too short for thorough arguing. Sometimes Mastodon's 500 symbols limit is not enough, I have to make threads there for better explanation. |
You would not even need a labeler, this would function better as a user preference that just filters posts that have a content length that exceeds their preference. Custom Feeds can already do this too. But yes, this website sorely needs to increase the character limit. Chaining comments is not an adequate solution, because it results in disjointed replies depending on which part of the chain someone replies to, and requires people to realize they need to click to see more of the posts unless you use up more of your text to indicate there's more to see, which also then takes them away from the timeline they are on, which users often have hesitancy to do, it breaks their flow. There is also another negative, the effect it has on language. It forces people to use often smaller, more generalized terms instead of being able to type eloquently and precisely. So we end up with many more chances for misunderstandings, bad-faith assumptions and a habit leaning towards reduced vocabulary instead of increased exposure to more... It would be great if this discussion was made a priority, as this is a pretty core change that would best be done before atproto becomes more widespread, instead of changing it later and breaking many other services. |
My understanding is that the 300-character limit only applies to social-app (i.e. Bluesky itself) rather than to all records on ATProto: For example, WhiteWind allows users to make longer posts – up to 100,000 characters, I believe – on ATProto. |
|
https://github.com/bluesky-social/atproto/blob/main/lexicons/app/bsky/feed/post.json |
and others
Is your feature request related to a problem? Please describe.
This is a feature request related to product enhancement.
Describe the solution you'd like
I propose increasing the post character limit from 300 to 500, including hashtags and emojis. This change will align our platform with others, facilitate sharing more comprehensive ideas, and complement the upcoming video feature, ensuring a diverse content range.
Some reasoning as to why 500 characters:
1) Competitive Edge: Many platforms with higher character limits, such as LinkedIn and Facebook, see high engagement with longer, more informative posts. By offering a 500-character limit, Bluesky can/might attract users who prefer these detailed interactions while maintaining the platform's unique style.
Supporting material:
Hubspot blog: https://blog.hubspot.com/marketing/character-count-guide
Feedback from some Bluesky users:
<script async src="https://embed.bsky.app/static/embed.js" charset="utf-8"></script>--
<script async src="https://embed.bsky.app/static/embed.js" charset="utf-8"></script>--
<script async src="https://embed.bsky.app/static/embed.js" charset="utf-8"></script>2) Improved User Satisfaction: Users often find character limits restrictive. Increasing the limit provides more flexibility, reducing the need for abbreviations, fragmented posts, or threading. This change was positively received when Twitter increased its limit from 140 to 280 characters, leading to clearer and more expressive communication
Supporting material:
Hootsuite blog: https://blog.hootsuite.com/ideal-social-media-post-length
3) Enhanced Content Diversity: Allowing more characters enables users to share more detailed and comprehensive thoughts, ideas, and updates. This can enrich the platform's content quality and variety, supporting deeper engagement and conversation. This idea aligns with findings that medium-length posts often perform well on platforms like Threads.
Supporting material:
Buffer Blog: https://buffer.com/resources/optimal-length-social-media/
Status Brew Blog: https://statusbrew.com/insights/social-media-post-length/
Describe alternatives you've considered
I considered maintaining the 300-character limit for timeline display and placing any additional content under a 'Show More' button. This approach would prevent timeline clutter but might disrupt the reading flow and engagement, as users would need to take extra steps to view longer posts.
Additional context
Mockup of what the "Show More" option could look like -
The text was updated successfully, but these errors were encountered: