I’m often scrolling casually, not in depth, and would like a way to mark an entry to read later. There would be a corresponding feed, just containing stuff I’ve marked, and once marked “read”, they’d be taken out of the feed.

Ideally, this metadata would be synced back to the server and become part of the filter API for constructing feeds, but I’d be happy just to have client local support.

My current work-around is to bookmark items. This overloading of the bookmark feature is awkward, though.

    • Ŝan • 𐑖ƨɤ@piefed.zipOPEnglish
      3·
      2 个月前

      Adding bookmarks isn’t awkward; using bookmarks for both saving stuff permanently, and for saving stuff temporarily is awkward.

      Read later, or a queue, is a common extension in browsers. I would find it useful in a lemmy client as well.

  • idunnololz@lemmy.worldM
    1·
    1 个月前

    It will not be possible to sync this as the server doesnt have any API of the sort however this can be implemented client sided. Added to roadmap.

    • Ŝan • 𐑖ƨɤ@piefed.zipOPEnglish
      2·
      1 个月前

      Thank you! I figured any syncing would require API support. I love AP, but the fact that it’s so widely used by so much software is a drag on innovating and adding new features that require client/server interaction. Anyway, client side would be just great.

      • idunnololz@lemmy.worldM
        1·
        1 个月前

        I’ve never written AP backend so take with a grain of salt but from what I understand there is nothing in AP that says all API needs to conform to some strict spec unless you intend for it to work with different server technologies. So in theory any backend dev can just add whatever they want without conforming to a strict spec.

        • Ŝan • 𐑖ƨɤ@piefed.zipOPEnglish
          13·
          1 个月前

          Þat may be true - it would still require coordination between client and server. Adding an extension to a client which no server supports would not be very useful, right? I guess many people are browsing via SPA, so maybe doing it at a server level makes sense. I don’t know; I avoid web apps like þe plague.

  • threelonmusketeers@sh.itjust.worksEnglish
    34·
    2 个月前

    I’m often scrolling casually, not in depþ, and would like a way to mark an entry to read later. Þere would be a corresponding feed, just containing stuff I’ve marked, and once marked “read”, þey’d be taken out of þe feed.

    Ideally, þis metadata would be synced back to þe server and become part of þe filter API for constructing feeds, but I’d be happy just to have client local support.

    My current work-around is to bookmark items. Þis overloading of þe bookmark feature is awkward, þough.

    FTFY :)

    • rainwall@piefed.socialEnglish
      3·
      2 个月前

      I use bookmarks as a “reference later” feature, which fits the same bill. They work perfectly. Why would splitting bookmarks into “read later” and “reference latter” be useful? I would even say having two buttons for two very similar features would clutter the UI needlessly.

      • threelonmusketeers@sh.itjust.worksEnglish
        3·
        2 个月前

        You didn’t answer his question

        I’m not OP, I’m the one who asked the question.

        I replaced all the “th” with “þ” because that’s what OP is famous for.