Scheduled posts #55
Labels
No labels
bug
contribution welcome
duplicate
enhancement
good first issue
help wanted
invalid
question
upstream
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Reference
marvin8/feed2fedi#55
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I believe the ActivityPub Client2Server spec does not feature scheduled posts. If my understanding of the codebase is right, feed2fedi only uses AT, rather than Fediverse-software-specific APIs, right? Does this mean that implementing post scheduling such as the ones on Akkoma is out-of-scope?
I'd like to do some research on post scheduling. Can you point me to some documentation on how post scheduling is done with Akkoma?
Being a form of Pleroma, it just has the same endpoints: https://api.pleroma.social/#tag/Scheduled-statuses
It also implements the Mastodon API, but this one does not feature scheduling.
Note that just because this is part of the API, not all clients implement it. For example, Mangane does, but Akkoma-FE does not.
Looking at the mastodon API documentation, it looks mastodon itself also supports scheduled statuses. So scheduling posts is not out-of-scope.
Any particular way you'd like to schedule posts with feed2fedi?
@foxy wrote in https://codeberg.org/marvinsmastodontools/feed2fedi/issues/55#issuecomment-7903630:
Reading the mastodon docs for creating a status and looking at the form field
scheduled_atleads me to believe that Mastodon does... Also looking at the Pleroma API documentation looks like the same way of scheduling a status.If my understanding is correct, it's definitely do-able.
Whoopsie! Perhaps I was just a bad reader. So the only Client-Server protocol missing this is AP?
My particular use case is reviewing the news items coming from the RSS feed before tooting them. So my real intention is to use scheduled posts as draft posts, by setting the scheduled publication date far away into the future.
I would expect a config field able to store an optional time interval (default is
Nothing). The posts should be scheduled for (RSS publication date + time interval), or just sent immediately if no interval is specified.I am not sure if this idea features any problems I am not seeing.
Let me play with this a little to see where the any potential troubles might lie.
Looks like this is not to complex. I have released 1.5.0 of minimal_activitypub to enable scheduled statuses. Will work on feed2fedi next.
@foxy I have a version ready that includes a command line option for scheduled posting.
Have a look at the wip branch if you'd like to have a look / provide any feedback before I release this version.
I am fine with this being a CLI flag, but the idea here was to pass a time interval to add to the publication date in the RSS feed to obtain the scheduled_at value.
The PR, on the other hand, adds scheduled_at as a flag already. This means that all posts will be posted at the same time, rather than with the same delay from their respective publication dates. Additionally, if you keep the bot running long enough, eventually scheduled_at will become a past date and it will have no more effect.
Hmm... That's going to be a bit more involved... It'll require processing of dates of the feed items. At this point I have on purpose steered away from processing to many fields of the feeds as they are an external data and I can't depend in them having all the fields needed...
I'll look into it some more and see what I am happy to do.
In the meantime how would you like to pass in the interval? As a cli option or as part of the config file? If using the config file, would different feeds in the config potentially have different interval periods?
Also how exactly would you envisage to express the interval? In days, hours, minutes, or seconds or a combination of all of them?
Maybe provide an example of an interval period as you'd like to express it.
What about adding the time interval to the current system time instead (or as a fallback)?
The ISO 8601 Durations is standard, but maybe not super simple? Whatever can be easily parsed in Python will work.
ISO8601 duration example:
P3Y6M4DT12H30M5S. Any other popular, standardized format would also work though.I don't think I have a strong preference between config file and flag, no.
@marvin8 wrote in https://codeberg.org/marvinsmastodontools/feed2fedi/issues/55#issuecomment-7908986:
What about different feeds?
Sorry, hadn't read that part.
My specific use case does not require feed-specific intervals, no. I can see how other people might find this useful.
Ok... thanks... Give me a bit of time to look at this. It might be a week or two. My Sunday is pretty much over and some other responsibilities take precedence during the week :)
Omg of course, no worries! I can also try and tweak the current PR myself, if I have time
Sure... be my guest.
Some 'light' reading on durations and math on dates:
Whenever Documentation - Arithemtic
For now I am thinking of only allowing time durations not date durations to make things easier.
Just FYI... I've updated the PR with an initial version of a scheduled delay based on a duration specified in the config.json file. At this time I think it might only work with Time duration.
Anyway. signing off for today... :)
@foxy I think I have a version that I'll release now. It has an optional config setting with a duration (ISO 8601 based) to schedule post in the future.
I have also update documentation around it.
If you feel like it, have another look. I'd be happy with feedback :)
Yes, the current state of #56 seems to fully satisfy the requirements. Thank you so much! I have had a careful read of the code. I might also be able to test this is the future, if needed.
Would you like me to keep this issue open until #56 is merged?
Thanks for having a look and confirming.
This issue will be closed when I merge #56, which I'll probably do today.
Closed by release 3.3.0
Thank you so much!