Technically that’s true, but if i am interested in that feature and looking through awesome-lemmy and see the name lemmy schedule i might think it won’t have that feature and then won’t check it out.
Ah, didn’t know it was there. Would you suggest any better description? I’ve currently changed it to “App for scheduling posts, pins/unpins and notifications about new content”, though I feel like it could be better.
On second thought i don’t know if a name change is needed as this functionality will probably be added to lemmy natively and might make yours obsolete.
Not currently, but getting notifications for new comments might be nice. The edits are not really possible in any sane way, I would have to store every version to see if it changed. Or I would have to store the last time you visited. Neither of which I really want to do, the app doesn’t store any permanent data about its users, everything is always stored in the queued job only and then forgotten once the job runs.
I've used this tool from the developer's instance. It works as intended. I haven't tried the new release.
I was skeptical that it would work to be honest. Particularly as I am a kbin user modding a kbin community. However, I was able to create an alt account on a lemmy instance and give the account mod status in the kbin community. So I use that account to post. I would be nice if kbin could be directly supported but I understand there are ongoing issues with the kbin API --- lack-thereof. For time being, the workaround has been functional.
Logging in to the interface now, I can't see any of the previous scheduled posts I've made which did used to be visible. Maybe the new version is a breaking change from prior. Which is fine with me. This kind of thing will obviously have an experimental nature to it. I am hoping that going forward the previously-scheduled posts will be visible because it is convenient.
My review is five stars ⭐⭐⭐⭐⭐ for the application. Thank you @rikudou for building and sharing this very useful application.
If you get this working thru a docker compose I will love you so much (at least more than I already do, I wish you could follow users on lemmy because I love seeing your content and posts)
On the todo list, not very urgent, though. Currently you can upload the image somewhere that allows direct link grabbing and put the direct link into the URL field. I use imgur for that.
With a mobile client, for example, you can check if it sends your password somewhere else, there are tools. If you use an open-source client then it’s even easier. Major clients have something that you could call reputation, though I wouldn’t put too much trust into it.
I don’t store your password if that’s what you’re asking! I’m planning to make it open source once I make sure I didn’t accidentally leave any production secrets in the code.
Anyway, here’s how it works:
You log in using your account, the site checks whether it’s a valid account using api and if it is, it creates a JWT token that’s used to authenticate you against Lemmy. At this point your password is already forgotten and the site has no way of getting it.
The JWT token is effectively the same as having your password - it allows you to do the same things you could if you have logged in normally.
The JWT token is not stored on the server, it’s only in a cookie in your browser.
When you schedule a post, the post details, your instance, your username and your JWT token are stored in a job that gets scheduled to run later. This is the only part where any sensitive information (JWT) about you are stored somewhere else than your computer.
After the scheduled job is triggered, it authenticates as you and creates the post as if it were you, immediately afterwards the job config is deleted, meaning the JWT is no longer stored.
The JWT is stored in every scheduled post you make, meaning as long as you have any scheduled post, the JWT is stored somewhere. When all scheduled posts are posted, your JWT is no longer present anywhere on the backend.
Note that due to current technical limitations, even if you cancel a scheduled job, its config (including the JWT) is stored until the original scheduled time. This will be (probably) fixed in future versions when I have some time to work on it.
Hope it clarifies it, let me know if you don’t understand any part of it!
Yup, that’s right. I don’t do that, though. Which obviously you’ll have to trust me on (or don’t and don’t use it). It has been open sourced now, but that still doesn’t solve it and I’m obviously not gonna go and give people production access to my AWS account.
I’m not saying you must use it, I’m just giving it here in case anyone wants to.
Dude, I literally develop stuff all the time and have dozens of open source projects. Why the hell do you think I have the need for collecting your credentials? Use a fake account for all I care, the code is open source and you can read it.
Where the hell did I lie? I’ve been open since the beginning. Are you a troll?
unusually defensive when called out for stating fact
You mean when someone told me to “do X or get the fuck out”? Are you fucking surprised I don’t like being told to fuck out? Where else have I been “unusually defensive”?
Pretending to not store effective passwords and attempting to obfuscate the mechanism to less tech savvy users
Stop lying and making stuff up, please.
I haven’t, your code stores effective password access and gives you the ability to control other people’s accounts and you’ve done nothing to secure it in your little php framework and said “just trust me bro, I won’t use your account by proxy even thought this is exactly what this app does”
In a scheduling system. Probably bad wording on my part, sorry. I meant that it’s not stored anywhere for just logging in, though it’s stored as part of every scheduling job in the scheduling system.
schedule.lemmings.world
Active