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 Post Character limit to 500. #2551

Open
jcx616 opened this issue Jun 5, 2024 · 47 comments
Open

Increase Post Character limit to 500. #2551

jcx616 opened this issue Jun 5, 2024 · 47 comments

Comments

@jcx616
Copy link

jcx616 commented Jun 5, 2024

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:

I really would post more here if the character limit was larger. 🥴

— Wilson Cruz (@wilsoncruz.bsky.social) Apr 30, 2024 at 4:57 AM
<script async src="https://embed.bsky.app/static/embed.js" charset="utf-8"></script>

--

I could like BlueSky if the character limit was larger. As I cross-post on BlueSky and Post I find myself editing down my rants. Rants are not meant to be edited.

— Larry Wayne (@larryranting.bsky.social) May 7, 2024 at 10:45 PM
<script async src="https://embed.bsky.app/static/embed.js" charset="utf-8"></script>

--

300 character limit isn't enough to allow for nuance in many cases, yet I've seen people here incredibly against increasing it to something like 3000+, just because twitter was smaller and they got used to it.

We really need larger character limits here.

— Epsi (@hotchoccy.space) May 19, 2024 at 7:19 PM
<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 -

Show more on a post

@jcx616 jcx616 changed the title Increase Posts Character limit to 500. Increase Post Character limit to 500. Jun 6, 2024
@ghost
Copy link

ghost commented Jun 6, 2024

would def need to have the show more to be included, -- could be a neat update if it increased when we get improved threading

@enn-nafnlaus
Copy link

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.

@Bossett
Copy link

Bossett commented Jun 19, 2024

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

@ghost
Copy link

ghost commented Jun 19, 2024

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...?).

Will absolutely be an improvement when we get the ability to post a thread with multiple posts at once

@mackuba
Copy link

mackuba commented Jun 19, 2024

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 :)

@lunamoth
Copy link

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

@ghost
Copy link

ghost commented Aug 10, 2024

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.

@makoConstruct
Copy link

makoConstruct commented Aug 15, 2024

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.

@Bossett
Copy link

Bossett commented Aug 15, 2024

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.

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

@enn-nafnlaus
Copy link

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.

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.

@ghost
Copy link

ghost commented Aug 15, 2024

I wanted to add with how long some fediverse and nostr usernames are like over 50 characters... it takes up so much space
and leaves a little room for actual post.

bafkreifdxrv4mh3pu5scdu544g2uejtnwy4cgxvjvqtk72f5okm6d3omyi

https://bsky.app/profile/surfdude29.ispost.ing/post/3kzidy5nnvv24

@bnewbold
Copy link
Collaborator

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.

@jcx616
Copy link
Author

jcx616 commented Aug 15, 2024

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.

@mackuba
Copy link

mackuba commented Aug 15, 2024

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

@enn-nafnlaus
Copy link

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.

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?

@IoIxD
Copy link

IoIxD commented Sep 1, 2024

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)

@filler56789
Copy link

@bnewbold, you admit yourself that people just screenshot text, create threads, etc. Can you elaborate on how it's a "creative obstruction"?

He can't. That's just his stupid opinion or lame excuse.

@enn-nafnlaus
Copy link

@bnewbold, you admit yourself that people just screenshot text, create threads, etc. Can you elaborate on how it's a "creative obstruction"?

He can't. That's just his stupid opinion or lame excuse.

I share your viewpoint, but let's disagree without being disagreeable here :)

@enn-nafnlaus
Copy link

i wanted to add another use case for increasing characters - as people and news agencies start multi posting - different social media platforms have different character limits. 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.

even increasing post character count, but keeping replies the same would be an ok balance.

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.

@andrei0x309
Copy link

I think 500 has become the new standard.
Many social apps have 500 now.

It's true that Twitter has only 280 but for pro the limit is: 10k

So the recap:
Bluesky: 300
Threads: 500
Twitter with pro: 10k
Farcaster: 1024
Lens: no defined limit but most apps can go over 3k
Mastodon: 500

I think considering the above 500 is a good starting point.

@enn-nafnlaus
Copy link

I think 500 has become the new standard. Many social apps have 500 now.

It's true that Twitter has only 280 but for pro the limit is: 10k

So the recap: Bluesky: 300 Threads: 500 Twitter with pro: 10k Farcaster: 1024 Lens: no defined limit but most apps can go over 3k Mastodon: 500

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 ;) )

@andrei0x309
Copy link

I think 500 has become the new standard. Many social apps have 500 now.
It's true that Twitter has only 280 but for pro the limit is: 10k
So the recap: Bluesky: 300 Threads: 500 Twitter with pro: 10k Farcaster: 1024 Lens: no defined limit but most apps can go over 3k Mastodon: 500
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.

@enn-nafnlaus
Copy link

I think 500 has become the new standard. Many social apps have 500 now.
It's true that Twitter has only 280 but for pro the limit is: 10k
So the recap: Bluesky: 300 Threads: 500 Twitter with pro: 10k Farcaster: 1024 Lens: no defined limit but most apps can go over 3k Mastodon: 500
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.

@SpriterGors
Copy link

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):
image

And this is the proposed increase (500 characters; 300 characters plus 200 over):
image

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.

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

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

@seanking2919
Copy link

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?

@makoConstruct
Copy link

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

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)

@SpriterGors
Copy link

What do you mean by this. I can't imagine this would be any different than just making the char limit 520.

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.

@Pandoskowy
Copy link

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.

@ghost
Copy link

ghost commented Oct 27, 2024

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.
in addition to fediverse usernames taking up character limits the quality of post we can do-

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.

@Bossett
Copy link

Bossett commented Oct 27, 2024

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

@DataDrivenMD
Copy link

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)

@MasterJ93
Copy link

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.

@captainharrie
Copy link

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:
image

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:
image
image

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.

@erlend-sh
Copy link

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.

@SpriterGors
Copy link

SpriterGors commented Oct 30, 2024

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

@vyke-exe
Copy link

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

@squili
Copy link

squili commented Oct 30, 2024

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!

@kawree
Copy link

kawree commented Nov 14, 2024

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.

@Tamschi
Copy link

Tamschi commented Nov 14, 2024

alternatively, i think having a separate field for hashtags might help? […]

That's part of Bluesky's app.bsky.feed.post lexicon already. You can add at most 8 outlined tags up to 64 graphemes/640 bytes each:

"tags": {
"type": "array",
"description": "Additional hashtags, in addition to any included in post text and facets.",
"maxLength": 8,
"items": { "type": "string", "maxLength": 640, "maxGraphemes": 64 }
},

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.

@zakwilson
Copy link

Post length limits that aren't necessary for technical reasons are a mistake. Display length limits configurable by the user can keep everyone happy.

@pirhos
Copy link

pirhos commented Nov 18, 2024

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

@zakwilson
Copy link

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.

@ghost
Copy link

ghost commented Nov 18, 2024

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

@Twilightssuperb
Copy link

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.

@Invertex
Copy link

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.

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.

@surfdude29
Copy link
Contributor

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

https://github.com/bluesky-social/social-app/blob/625459add6c14c9ae6c1158fbe5c67a4e0838fc6/src/lib/constants.ts#L55

For example, WhiteWind allows users to make longer posts – up to 100,000 characters, I believe – on ATProto.

@rotmoded
Copy link

https://github.com/bluesky-social/atproto/blob/main/lexicons/app/bsky/feed/post.json
the character limit is actually enforced by the app.bsky.feed.post lexicon and therefore the pdses and appviews not just the social app. whitewind allows up to 100000 characters because it uses a different lexicon
https://github.com/whtwnd/whitewind-blog/blob/main/lexicons/com/whtwnd/blog/entry.json

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests