doesn’t handle concurrency

Kavita is multiuser, each with their own progress sync. https://wiki.kavitareader.com/getting-started/

Now do tell, is it page 10 on a 5" 800x480 eink display with 48px font size and giant margins/lineheights/word paddings, or is it page 10 on a 13" display of 2480x1860 resolution with 11px font size and barely any margins

Again, it’s a protocol and developer discression can be used. Page 10 could be word 10, or word 1000/avg 10 words = 10. PSE can be used to store progress, without needing to request the page because the eBook is local. It could be any API format.

10 petabytes… Siphoned over months without detection.

Doubt. A stack of hard drives in a backpack still has the highest bandwidth.

You assume one buyer. Five buyers at 800K is better than 3 at 1MM.

PSE is a protocol, how information is used on each side of that protocol is at the developers discretion.

pse:lastRead="10"
pse:lastReadDate="2010-01-10T10:01:11Z"

My industry has a lot of Apple laptop users for the reasons you mention. Every time I pull out my Zenbook Duo, I hear converts in the making. Sure, it’s a bit thick, but it runs Linux great and has two monitors in a portable platform with a good battery.

Hmm, does that mean “most” since it… matters most? Eh? Eh? Ehhhhhhh?

https://docs.mattermost.com/administration-guide/configure/push-notification-server-configuration-settings.html#id-only-push-notifications

Yea not sure why they don’t do that by default since they claim they are a Slack competitor. You’d think a corporate entity would want that.

My workflow is usually to add a book to my Want to Read list in Kavita, then on a reader I can go to that list through OPDS and browse just that list. Makes things much more managable assuming I don’t spam the list.

https://anansi-project.github.io/docs/opds-pse/specs/v1.2

They use the PS extension. I believe Komga and Kavita maintain the spec now. Reader support for Kavita specifically is in the Wiki.

Progress sync works fine for me in KOReader with OPDS. Progress Sync Scrobble (to third-parties) is the Kavita+ feature.

My understanding was the Kavita+ items are things to do with third-party services and meta data providers that are an API/cost-based service to the dev. That being said I don’t use any of those features.

The OPDS service works for me, just like on Calibre. I can browse my books from within KOReader.

Mysteriously? Really?

The reason was clear, they never got the email for account verification, and were locked out. MS messed up.

I really hate headlines these days.

I switched. Kavita is the new hotness.

I found it for comics, but realized it handled books as well as Caliber does, in a modern interface with OPDS support.

I’d disagree with “most messengers” doing that, in my experience, most don’t do it by default. Signal is a pretty rare exception to do so by default.

What messenger doesn’t? Signal, WhatsApp, Matrix, Snapchat, Discord, Telegram, etc. I’d say “most” is pretty accurate. No idea what Wechat does, but that’s a whole different story.

If you get a push notification on your phone, everything you see in that notification must by definition pass through the push notification service.

Also not true. What you “see” could have been retrieved post-notification, as described in the message you responded to. What you see has nothing to do with what goes through the push service and is a full technical inacurracy.

Not true.

The push notification for most messengers is a ping with little to no data in it, telling the app to grab messages directly via TLS. That’s how e2e works with push.

Would running in Proton mean the security issues are moot?

If a snap is bundled with it’s own dependencies (the point of snap), those dependency libraries are not loaded into shared memory. Multiple apps that would typically share a loaded dependency must now each load them into RAM.

But that’s not honest.

Ubuntu’s default browser, and other apps, are snap-based. They take significantly more resourced than their Debian counterparts.

At its core is MEMORY.md, a lightweight index of pointers (~150 characters per line) that is perpetually loaded into the context. This index does not store data; it stores locations.

Actual project knowledge is distributed across “topic files” fetched on-demand, while raw transcripts are never fully read back into the context, but merely “grep’d” for specific identifiers.

This “Strict Write Discipline”—where the agent must update its index only after a successful file write—prevents the model from polluting its context with failed attempts.

For competitors, the “blueprint” is clear: build a skeptical memory. The code confirms that Anthropic’s agents are instructed to treat their own memory as a “hint,” requiring the model to verify facts against the actual codebase before proceeding.

Interesting to see if continue.dev takes advantage of this methodology. My only complaint has been context with it.

Can always self-host.

So is BitWarden if you self-hosted. The price increase is for a hosted service which Keepass does not provide.