I mean, I wanted to start work on it, but if someone’s already released/working on one then I’d just happily use those instead.

Also, the absence of a thing usually means it’s not possible to have. In my mind I think it’s easy to have userscript code make API posts on behalf of the user, but maybe somehow in the intricate layers of tech it’s made impossible or tedious. If so, I’d like to know before I learn it the hard way.

    • ruk_n_rul@monyet.ccOP
      link
      fedilink
      arrow-up
      0
      arrow-down
      1
      ·
      1 year ago
      • it’s not federating any content to my instance.
      • going to that instance and performing a search also outputs no results.

      but thanks for the heads up! I’ll ask there about this as well.

      • Crul@lemm.ee
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        going to that instance and performing a search also outputs no results.

        If you mean searching for “schedule” in that community, I can confirm I didn’t see anything.

        But, if you mean that you don’t see any post at all at this URL https://lemm.ee/c/lemmydev , that would be weird

        Anyway, good luck!

    • ruk_n_rul@monyet.ccOP
      link
      fedilink
      arrow-up
      2
      arrow-down
      1
      ·
      edit-2
      1 year ago

      that’s a major security risk. even the reddit predecessor uses app tokens (though with the death of 3pa idk if such things still work). that’s why I want something that only runs on the client side.

      tbf there’s nothing stopping userscripts from stealing your jwt token in the cookie, which is just as big a security risk, but at least with userscripts you can read the source code.

      my plan would be similar to that one in which I store the jwt with the scheduled posts, with the notable difference of the data remaining on the browser storage. i wont even need to see any passwords since the jwt is already in the cookie which the script could read off of.