Raise app.bsky.feed.post grapheme limit to 2000 while preserving short-form client presentation

[Erics1337]

Proposal

Raise app.bsky.feed.post.text.maxGraphemes from 300 to 2000, while keeping maxLength: 3000 or adjusting it only as needed for Unicode/code-unit safety.

This would separate protocol capacity from client presentation:

• The lexicon/PDS would allow posts up to 2000 graphemes.
• Clients could still preserve a short-form timeline by collapsing or truncating long posts in feeds, quote embeds, notifications, and compact surfaces.
• The official Bluesky app could continue to show approximately the current amount of text inline, with a native "Show more" affordance for longer posts.

Why this belongs at the lexicon layer

The current app.bsky.feed.post lexicon allows text.maxLength: 3000 but caps text.maxGraphemes: 300. That means client-side changes alone cannot make longer posts work reliably; clients that raise their composer limit will still create records rejected by lexicon validation.

Keeping the protocol-level ceiling at 300 also forces every app.bsky client into the same microblogging composition model. That is a product choice that makes sense for the official Bluesky timeline, but it is a surprisingly strict constraint for a federated social protocol intended to support many clients and presentation styles.

User demand / existing Bluesky issues

This proposal builds on recurring social-app feedback:

• Increase Post Character limit to 500.  #2551 asks for increasing the post limit to 500 and includes user feedback requesting more room and a "Show More" mockup.
• Constrained 300-character limit causes high user friction social-app#10960 asks for raising the post limit to 2000 while preserving scannability through "Show More".
• Post character limits social-app#5913 asks for increasing the limit beyond 300 and notes that thoughtful critique often needs more room.
• Invalid app.bsky.feed.post record: Recordtext must not be longer than 3000 characters social-app#4952 shows that users can already hit confusing length validation behavior around the current maxLength/maxGraphemes split.

I also opened a draft social-app PR for the client-side constant change, but it intentionally remains a draft because the lexicon currently rejects posts over 300 graphemes:

• Raise composer character limit social-app#11032

Why 2000, not 500

I understand 2000 is a product-sensitive number. I am proposing it specifically as a protocol ceiling, not as a requirement that every client render 2000 characters inline.

The strongest argument for a larger ceiling is that smaller increases still preserve the same "editing tax" dynamic. Research on Twitter's move from 140 to 280 found that hard limits create "squeezing" behavior: users write more tersely, use more abbreviations, and continue clustering near the new ceiling after the increase. A later study found that cramming re-emerged at 280 and that a larger limit would be needed to reduce it further.

In other words: moving from 300 to 500 helps, but it still leaves the protocol in the business of forcing compression. A 2000-grapheme ceiling gives users enough room for context, accessibility, and nuance while leaving timeline aesthetics to clients.

External precedent

Several short-form or microblog-adjacent platforms already separate composition capacity from timeline readability:

• Mastodon defaults to 500 characters, counts links as a fixed 23 characters, and supports content warnings that collapse post bodies by default. Its docs explicitly describe content warnings as useful for collapsing long posts or providing setup/context.
• Threads launched with 500-character posts and later added expandable 10,000-character text attachments, showing a mainstream short-form product can preserve compact feed entries while supporting longer expression.
• Twitter/X doubled from 140 to 280 after observing that English users hit the old ceiling far more often than Japanese users. A year later, company-reported data summarized by Axios said brevity still dominated; the extra space mainly reduced abbreviations rather than turning the feed into essays.

Accessibility / communication benefits

A hard 300-grapheme limit often requires users to remove context, hedge words, examples, and connective language. That is not just a style issue. It can make posts harder to understand, especially for technical explanations, conflict-sensitive topics, accessibility-related posts, multilingual users, and neurodivergent users who rely on precise phrasing to avoid misinterpretation.

The proposal is not that every post should be long. It is that the protocol should not require every complete thought to be split into a thread when one bounded record would be clearer.

Compatibility and implementation sketch

A staged rollout could make this less risky:

1. Update the lexicon from maxGraphemes: 300 to maxGraphemes: 2000.
2. Update server/PDS validation and generated API packages.
3. Update the official social-app composer limit and draft validation.
4. Add or confirm display policies for:
   • feed items
   • post thread items
   • quote-post embeds
   • notifications
   • embeds / external renderers
   • screen-reader labels and "Show more" controls
5. Monitor moderation, spam, and performance impact.

For clients that want a stricter product experience, nothing about this prevents keeping a local 300-character composer limit or truncating aggressively in feeds.

Open questions

• Should the protocol ceiling be exactly 2000 graphemes, or should maxLength: 3000 be revisited at the same time?
• Should app.bsky define a recommended display-collapse threshold, or should that remain entirely client-specific?
• Are there known moderation, indexing, relay, firehose, or AppView costs that make 2000 meaningfully different from 300?
• Would maintainers prefer this as an experimental lexicon change, a flag-gated server rollout, or a formal ATP proposal first?

Sources

• Current app.bsky.feed.post lexicon: text.maxLength: 3000, text.maxGraphemes: 300
• Existing atproto request for 500 characters: Increase Post Character limit to 500.  #2551
• Existing user report: Constrained 300-character limit causes high user friction social-app#10960
• Related feature request: Post character limits social-app#5913
• Related validation issue: Invalid app.bsky.feed.post record: Recordtext must not be longer than 3000 characters social-app#4952
• Draft client-side PR: Raise composer character limit social-app#11032
• Mastodon posting docs: https://docs.joinmastodon.org/user/posting/
• Axios on Twitter's 280-character aftermath: https://www.axios.com/2018/10/30/a-year-after-tweets-doubled-in-size--brevity-still-rules
• Gligoric, Anderson, West: "How Constraints Affect Content: The Case of Twitter's Switch from 140 to 280 Characters": https://arxiv.org/abs/1804.02318
• Gligoric, Anderson, West: "Adoption of Twitter's New Length Limit: Is 280 the New 140?": https://arxiv.org/abs/2009.07661
• Gligoric, Częstochowska, Anderson, West: "Anticipated versus Actual Effects of Platform Design Change: A Case Study of Twitter's Character Limit": https://arxiv.org/abs/2208.14392
• The Verge on Threads expandable 10,000-character text attachments: https://www.theverge.com/news/770391/meta-threads-text-dumps-attachments-10000-characters

[Erics1337]

Adding one more framing here, and tagging @estrattonbailey since they gave helpful feedback on the related social-app PR that this would be a frontend/backend/moderation paradigm Bluesky is not currently ready to support.

I think the gap is not quite "long-form content." The apps mentioned in the PR thread - Leaflet, PCKT, Offprint, Lemma, etc. - are useful, but they solve a different problem: articles, notes, newsletters, or blog-like publishing.

What seems missing is medium-form social posting:

• Instagram-caption-length posts attached to normal social media context
• image/video posts with enough room for context
• personal updates that are longer than 300 characters but are not articles
• creator/community posts from people who might otherwise stay on Instagram or Meta
• accessible/precise posts where shortening removes necessary context

That middle layer matters if Bluesky/ATProto wants to be a viable off-ramp from Meta-style social media. A lot of people do not want to write a blog post or publish an article; they want a normal social post with enough room for a caption, explanation, recommendation, event note, or nuanced personal update.

So the question I am trying to ask is slightly different from "should Bluesky support long-form content inline?" It is:

Should ATProto have a native medium-form social post surface, even if individual clients preserve compact timelines with truncation / Show More / local composer limits?

If the answer is still no, it would be helpful to understand what specifically makes medium-form posts too large a paradigm shift:

• Is it primarily product identity and feed readability?
• Is it moderation tooling and policy surface area?
• Is it storage/indexing/AppView/PDS cost?
• Is it compatibility with existing clients?
• Or is the concern that app.bsky.feed.post should remain intentionally microblog-only, with medium-form delegated to separate lexicons/apps?

I think documenting that distinction would help contributors understand whether the path forward is "not now," "different lexicon," "different client affordance," or "not aligned with Bluesky's product direction."