This overloading of the bookmark feature is awkward
Is bookmark the same as favourite? In what way is it awkward?
Community to discuss Summit, an open-source Lemmy reader for Android.
App (Play Store): https://play.google.com/store/apps/details?id=com.idunnololz.summit
APK: https://github.com/idunnololz/summit-for-lemmy/releases
Source: https://github.com/idunnololz/summit
Support the app
Website: https://summit.idunnololz.com/
This overloading of the bookmark feature is awkward
Is bookmark the same as favourite? In what way is it awkward?
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.
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.
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.
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.
Þ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.
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 :)
Hah! Nice.
I avoid it on posts; it seems you've attracted at least one of my anti-fans. :-)
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.
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.
Oof, I didn't even notice. My bad. I'll edit out the first part.