Post scheduling?

[dessalines]

Not a priority rn, but as lemmy grows it might be cool to have a post scheduler built in.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/79308107-post-scheduling?utm_campaign=plugin&utm_content=tracker%2F126011972&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F126011972&utm_medium=issues&utm_source=github).

[Nutomic]

This can be done in clients.

[dessalines]

This one should stay open, because we can use Lemmy's scheduler to do this, and possibly add a column for create date.

A client isn't the place to build a scheduler, because most clients (esp web or mobile apps) won't run continuously in the background.

[Nutomic]

LemmySchedule provides this functionality. Closing this because I dont see any reason to reimplement functionality in Lemmy which can be done perfectly well through the API.

[dessalines]

That scheduling is a continuously running php app that also requires redis. It would be extremely useful to have this built into lemmy, which is the way that it should've gone instead of someone creating another app.

[snowe2010]

This is a really weird thing to have an argument about. Scheduling client side would be a nightmare, like how Microsoft Outlook handles emails where you schedule an email for the morning, close your laptop, and then the email doesn't send because your laptop is asleep.

But even then arguing about it through reopening and closing an issue is really weird. Leave the issue open, have a discussion, talk about the pros and cons of putting it in the software, and then make a decision with the community.

[snowe2010]

And then marking the most relevant comment in the thread as off-topic. You're really alienating your users and server admins with this. Have the discussion like adults.

[raskyld]

Hey, I was browsing good first issues and I saw this issue and just wanted to give my 2 cents for what it's worth.

I think the problem (what you're arguing on) stems to "what is an elementary feature and what is a pluggable feature". It's like thinking whether a specific library should stay as an external library or be included in the standard library.

Is the ability to schedule posts too specific to be included in the core Lemmy back-end? I don't think so. Scheduling seems a trivial feature that should be built-in and that every instance owner would like to have (imho).

I join @Nutomic though on avoiding to "reimplement" things and I would even say to avoid "bloating" the core back-end and instead work on #3562 to support more modular topologies. My reasoning is that most instance owners probably host those instances without financial support. Maintaining the backend as light-weight as possible while giving instance admin extensibility though server-side plugins if they are ready to pay the infrastructure cost that comes with it seems a better approach imho.

Another possibility would be to ensure those features added to the lemmy core are gated behind a feature flag.

[Nutomic]

@raskyld For me its fine to include this directly in the backend. The main question is who will implement it, because dessalines and I are very busy working on higher priority tasks. So if you or another community member implements it, there is no problem merging it as long as the code is clean and passes review.

[raskyld]

That seems a good exercice to learn about Lemmy backend and rust in general, I am gonna give it a try!

[dessalines]

Thx! How I'd go about it would be, to do a diesel migration that creates new columns on the post table, with a publish_date and published field, then have a scheduled job that finds all posts that aren't published. Federation of them would be the more difficult part.

[Nutomic]

For federation you only need to call this function (and dont forget to send the webmention as well).

[raskyld]

I am sorry Im based in CEST and for now I can only work out of business hours but I was wondering why would this be difficult? From my point of view, the post will not be federated and will stay persisted locally in the instance where it is written and scheduled and it would only be spread (federated) once released right?

[Nutomic]

Correct

[raskyld]

Hey, once I finished my contrib on #4142 I will get to actual rust code with this issue :)

[EmilJacobs]

Any updates on this?

[dessalines]

No one's working on it atm, but its in our milestones.