Add auto-split for Toots over character limit

[BDGreyson]

Is your feature request related to a problem? Please describe.
Toots that are longer than the instance's character limit can (obviously) not be posted.

Describe the solution you'd like
It would be lovely if Pachli could auto-split Toots that are too long for the instance into multiple Toots, separated either by word or by sentence so that the first Toot is created and the other parts are automatically created as replies/thread to each other.

Describe alternatives you've considered
I can't really think about an alternative. My current way of handling it is manually cutting some content, hoping I intuitively cut enough to go below the limit, and then posting it as reply manually, hopefully between people interacted with the main Toot and are confused at its incompleteness.

Oh, or switching instances to one with higher character limit, but that would be a pity once you find a reall nicely fitting instance for yourself.

[nikclayton]

There's a few things that make this quite complicated. I'm noting them down here as an aide memoir for when I start to think about implementing this.

UX for composing

The UX for composing posts would need a significant re-work. Simply splitting posts on words or sentences is going to lead to a bad experience (e.g., a post that's too long by one word resulting in a one-word post.

What to do about @-mentions needs thought. At the moment if you reply to a post that has @-mentions those are copied in to the post. If you're posting a thread that's a reply do those @-mentions get copied in to every post in the thread, or just the first one?

Visibility for posts in the thread

Should each post in the thread have the same visibility?

Or should there be an option to make the first post in the thread one visibility (e.g., public), and the rest of them be unlisted?

Spoiler / CW / sensitive

Can you set a per-post CW in a thread, or do you provide the CW for the thread and it's attached to every post in that thread?

Ditto for marking a post as sensitive; should that be per-post in a thread, or apply to the thread as a whole?

Drafts

Whatever modifications are made to the composing experience also need to be made to the "Drafts" experience. If the user drafts a thread that should not appear as individual posts in the "Drafts" UI, but as a single thread the user can edit before posting.

Scheduled posts

I don't think you can thread scheduled posts using the Mastodon API. More specifically, you can't create a post that is a reply to scheduled post where the scheduled post time is still in the future.

So either scheduled posts would be limited to being a single post long, or the Mastodon scheduled-post functionality would have to be ignored, and all post scheduling would be done assuming your device is on and has network connectivity at the time the post is supposed to go live.

Neither of those are great UX. It would be interesting to see what other software does in this case.

Error handling

Assume the user has written a thread of two or more posts. The first post in the thread posts successfully. The second doesn't.

• How is the error surfaced to the user?
• What does the retry policy look like?
• If there are automatic retries, how many should happen before stopping and requiring user action?

Threads of more than one post should probably automatically insert an "(_x / _y)" marker at the end of each post (so subtract 9 characters from each post in a multi-thread). This is to make any missing messages obvious to people reading the thread.

Some conclusions

• The unit of posting should be changed; it's no longer a post, it's a thread of 1-n posts
• Posting a thread should probably add it to a queue of outbound threads, and start an expedited job to post that thread
• The queue of threads needs to be visible to the user somewhere in the UI
  • Successful threads (these probably expire out of the queue after 24 hours, this just provides the user some history)
  • Unsuccessful threads
    • Number of retry attempts so far
    • Last error message from posting
    • Number of retry attempts remaining
    • Time of next attempt
    • UX to retry now

[tzeumer]

Maybe one could be inspired by Fedilab which handles this very well as documented here: https://fedilab.app/docs/fedilab/user_guide/compose/threads/

It's also possible to schedule these threaded toots. So far this always worked well.