Backdate and scheduled toots within UI

[naDevi]

Pitch

• Add backdate toots feature to UI (it has on many popular social media platforms)
• Add scheduled toots feature to UI (Add UI for scheduled posts #15887, seems already support through API-wise)

Motivation

Backdate
We need backdate toots for many reasons,

• such as due delayed bring contents to social media then publishers don't have to upset the mind
• help avoid misunderstand readers because if post announcement, updates, news, tournament, and so many displayed as newer date or time than to actual then random and quick readers may misunderstand and feel unhappy for some readers about why old contents now
• Publishers will never ignore to add delayed contents to mastodon, because able to publish and backdate Then mastodon will never lack from information, details than to other platform or site.
• When start to use mastodon, if was using other platforms then able to backdate and add past months, years posts

and more benefits

(this doesn't have chance to mislead; display timer symbol next to the date of toot)
if hover mouse near to timer symbol then display actual posted date.

Scheduled

@koyuawsmbrtn It was a promised feature that never got delivered

[SuperSandro2000]

Scheduling toos is good idea but backdating toots without clear marking is a really bad idea.

[uNitrous]

Scheduling toos is good idea but backdating toots without clear marking is a really bad idea.

OP has explained how it need to be implemented (and as how it already has in other soci sites) nothing to worry, display clock symbol definitely solve the problem. i was struggling to accomplish this somehow then prefer see this feature come to mastodon soon.

[ShadowJonathan]

Backdating is already technically a thing as dates on posts are set by the originating server, not the receiving server, the only reason why they might seem delayed is network issues.

I don't agree with allowing backdating necessarily though, and your reasoning feels vague, and to be honest, i can't entirely parse what you're trying to say.

[JJTech0130]

I think they're trying to make the point that when you are importing toots from another platform, say birdsite, then you might want to preserve the original dates. (So that readers don't see 100s of toots at the same time)

[freemin7]

All the use cases can be summarised as:

• i have some canonical timeline of events with time stamps
• i want a mastodon account to reflect that canonical timeline
• i have not been posting to mastodon as the events in the canonical timeline happend
• i want it to look like to other mastodon users as if i have been posting about those events when the events occurred in the canonical time line
• i want to do this on a server i don't have full control over

If you were Tumblr or the new york you could easily set up and host new mastodon server where all the old content is backdated. It would look like a server recovering from a decade long net split no active server has user who followed users from there.

Backdating toots is about giving the same capability to users on any mastodon server which have active followers and have been tooting other toots after the date the toot is backdated to.

I think backdating would need to happen on an activity pub level as some activitypub implementations might make assumptions about eventual consistency of the inbox and outbox. This could also be used to create "disorder"/"fragmentation" in the data structures of a database degrading DB performance in a surprising way. This would need to be tested. Some might not even order by date but just order by incoming which could cause all kinds of trouble.

Which is why the ActivityPub spec says:

An OrderedCollection MUST be presented consistently in reverse chronological order.

This seems like a death blow to the idea of messing with the published attribute to much although consistently is not defined in the spec and only mentioned there.

Backdating is more harmless than forwarddating because it adds toots to less often seen places. A forward dated toot to 2100-01-01 might be stuck on top of the timeline until someone posts something newer.

A better way might be to have a field for a "preferred display date" attribute of an activity pub object which might or might not be processed by all clients and servers. I am unsure whether additional fields are allowed in activitypub. I am confident that some implementations will lose this attribute as it is not required to copy all fields of objects.

[trwnh]

protocol-wise there's no issue on setting any published date you want. the problem is when you have the abstraction of a "home timeline" containing posts from multiple sources, some of which were not explicitly delivered to you and are therefore not in your inbox. if you were browsing your inbox or some outbox or other collection directly, it wouldn't be an issue.

i think in mastodon, sorting is done by local snowflake id, and that id is assigned at the time the status is processed

[robusticus]

Any progress? Trying to bring over my 14-year-old Facebook. Seems like the objections here aren't relevant. Don't need it in the UI, just the API. Am I missing something, can it be done now?

[koyuawsmbrtn]

Like I said, API there, UI only on some third-party apps. What a shame.

[robusticus]

Undocumented but it works? Guess I'll give it a go. Set the created_at in the POST?

[koyuawsmbrtn]

No, take a look at this. There's nothing at all in the WebUI that uses this API, but it's documented somehow.

https://docs.joinmastodon.org/methods/scheduled_statuses/

[robusticus]

Thanks for the response! The documentation says that the scheduled_at value in that call needs to be at least 5 minutes in the future. Is that not true?

I was thinking adding a method there, importStatus, which would be the same thing, except it would accept and use a created_at value.

Related: #14287