The creator of the tool is the admin of lemmings.world, and the tool is hosted at schedule.lemmings.world. So, if you have a user at lemmings.world, you can use this tool without having to trust a third-party.
If you don’t have a user there, you can create a user in that instance for the purpose of creating scheduled posts. Removing the need to trust two parties rather than one.
And, of course, since the source code is open anyone else can attach this to their own instance! Pretty cool.
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.
Just stop, please. You told me to GTFO and I don’t like it. Learn to communicate, please. Yes, I’m super, super defensive when someone tells me to fuck off.
I suppose the only thing is that you wouldn’t be able to upload an image to the instance as part of a post - you’d have to upload it somewhere else first, to then be able to refer to it.
For the detractors, register a throwaway account at some random instance, and use that if you want to test it out.
If you’re able to properly pore through the source to check it’s not stealing anything, then you’re capable of scheduling your own posts. The Lemmy API is very simple, it’s not rocket science.
I suppose the only thing is that you wouldn’t be able to upload an image to the instance as part of a post
It would be possible but it would add more complexity, more costs etc. I’ll probably tackle the problem when I have time, but now I’m glad that I have a version that I can use working.
If you’re able to properly pore through the source to check
I even pointed out some interesting parts regarding this in the README.
I used it for example to post this very post at a time when people from US are most likely to engage (though I’m not sure if the Lemmy demographics is predominantly US, but my gut feeling is it is).
Fediverse has made me click on so many weird links that could possibly be phishing links. I give Lemmy instance links to other people and they say it might be a scam phishing link as well and I kind of get their point.
I would like to make a list at some point with several community integrations and ask my instance’s users whether they would like some of them installed into the instance. This application will definitely go on that list! I do need to take into consideration how many resources each of the apps consume, to make sure I don’t bloat my server. But this one seems quite light. Is it?
The way I run it it’s entirely serverless and costs you close to nothing.
the application code runs on AWS Lambda (400,000 seconds per month free, time’s only counted when someone is actually making requests)
the static assets (CSS, JS etc.) are on S3/CloudFront (very small size, so less than $0.10)
event bridge scheduler is used for the scheduling (first 14,000,000 schedules per month are free)
sessions and “database” is in DynamoDB (you only pay for real requests, probably less than $0.10)
All in all the app can be hosted for much less than $1/month like that. If you host it in a standard docker container or something, it probably won’t take much resources either, my guess would be less than 256 MB RAM (probably less than 100 MB) is needed and whatever your backend for scheduling takes (Redis would probably be the most straightforward choice).
Yep, that’s exactly the target audience for this. I’m doing the first live test of this on !wwdits - in about 4 hours and 15 minutes a new pinned post should appear and the old pinned post should be unpinned. Hopefully it works because I’ll be sleeping at that time.
Because Lemmy doesn’t support OAuth and this is actually the only way to do it. Hopefully only temporarily. Edit: The thing’s open source, you can check that I don’t do anything with the password, I only use it once to login to the api and get the token, pretty much the same as I would do with OAuth.
They didn’t. They sent you a code and if the code matched, they assumed it’s you. I need the user’s JWT token to post as them. And that’s currently impossible without password.
schedule.lemmings.world
Oldest