this post was submitted on 22 Jul 2026
10 points (69.2% liked)

Privacy

49928 readers
973 users here now

A place to discuss privacy and freedom in the digital world.

Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.

In this community everyone is welcome to post links and discuss topics related to privacy.

Some Rules

Related communities

much thanks to @gary_host_laptop for the logo design :)

founded 6 years ago
MODERATORS
k_o_t@lemmy.ml
tmpod@lemmy.pt
Yayannick@lemmy.ml
ranok@sopuli.xyz
10
Review of Proton's Lumo 2.0 (aussie.zone)
submitted 1 day ago* (last edited 1 day ago) by SuspiciousCarrot78@aussie.zone to c/privacy@lemmy.ml
20 comments fedilink hide all child comments
 

Just wanted to share my review and experiences of using Lumo 2.0, which is Proton's new LLM.

Given that many of us use Proton services and are privacy conscious, I thought this might be of interest.

The below is a lightly edited from another post.

It broadly speaks to the integration (or lack thereof) of Lumo with other Proton services, rather than the privacy angle (which I am sure you're aware of), though I can speak to that too. EDIT: see my below follow up.

I see no reason at this point to continue with my subscription, and if anything, I'm thankful for the shot in the arm to improve my self hosted stack / create an equivalent or better service for myself.

TL;DR: With some elbow grease and know how you can probably create something equivalent or better home.

I keep seeing suggestions here that Proton should adopt Kimi K3, or otherwise move to a much larger and more fashionable model.

I am increasingly unconvinced that model capability is Lumo’s primary problem.

Lumo Lite appears very likely to be based on a Qwen 27B-class model, judging from the behaviour and the Artificial Analysis results Proton have stated.

(That identification is not proven, obviously, but it is plausible enough for my broader point).

A model in that class should already be an excellent all-round foundation for Lumo.

My humble suggestion:

Serve it at FP8 or comparable precision. Optimise it properly. Keep latency reasonable. Increase the context length.

Then spend the engineering effort on the things that would actually distinguish Lumo from every other chatbot:

  • Reliable Proton Mail, Drive, Calendar and Contacts integration

  • Authoritative and current Proton product information

  • Deterministic tools for calculations, dates, prices, plan limits and account features

  • Exact-span retrieval rather than loose paraphrasing for proton_info

  • Visible source dates and document versions

  • A clear distinction between retrieved evidence and the model’s interpretation.

At present, Lumo can (apparently) retrieve information about Proton’s own products and then produce an answer that reverses or mangles the source.

Something like “it is not $12.99” becoming “$12.99” is not a problem that Kimi K3 or GLM inherently solves.

It is a grounding and validation problem.

A larger model may paper over some failures. It may phrase uncertainty more elegantly. It may recover from poor retrieval more often.

But it does not make stale information current, and it does not make an unreliable tool pipeline deterministic.

IMESHO, Proton’s strategic advantage is not that it can host the largest open model.

Other companies will always have larger models, more compute and faster release cycles.

Its advantage is that it owns a private productivity ecosystem, with only one real mind share competitor.

A smaller model that can reliably search my mail, locate a Drive document, understand my calendar, retrieve the correct Proton support information, chat, OCR (native ability with latter Qwen models iirc), image manipulation and perform bounded actions would be considerably more useful than a stronger general-purpose chatbot with shallow integration.

I would much rather Proton solidify Lumo Lite into a dependable, deeply integrated assistant than keep changing the model underneath it in pursuit of benchmark gains.

The model is probably already good enough.

The product around it is not.

ICBW and YMMV.

top 20 comments
sorted by: hot top controversial new old
[–] PeculiarGoat@lemmy.world 15 points 1 day ago (1 children)

The best thing about Lumo is that it isn’t integrated with their core services. I hate seeing ✨bullshit everywhere.

[–] SuspiciousCarrot78@aussie.zone 2 points 1 day ago* (last edited 1 day ago) (1 children)

Hah, I dont mean integrated like Micro$hit. I mean "is aware and can communicate with your other Proton services".

I like Lumo too but right now it's just...a collection of open weight llms, with missing features, low context and poor utility (bad web app, poor integration with Proton drive, can't create artifacts etc).

If Proton's intention is to create a privacy-based alternative to chat GPT or Claude, they're going to be chewing off a hell of a lot more, and nothing in how Lumo is currently served offers any confidence in that.

On the other hand, if their intention is to offer a Proton based product, that could be tightened up and made much more useful in a short order. Without spending a lot more.

But I'm not doing Proton's homework for them. As an end user, Lumo isn't quite "there" for me as a product, so I will discontinue. YMMV.

[–] floquant@lemmy.dbzer0.com 6 points 1 day ago (1 children)

If Lumo had access to the contents of your mailbox, wouldn't that be breaking a core feature of the whole Proton stack? E2EE/zero knowledge is fundamentally incompatible with integrating a provider-operated chatbot that can access your data

[–] SuspiciousCarrot78@aussie.zone 0 points 1 day ago* (last edited 23 hours ago) (1 children)

Zero-access means Proton cannot independently read stored mail (*). It does not prevent users from authorising selected decrypted emails / folders for temporary Lumo processing.

A server-side AI would temporarily see plaintext (which Lumo does anyway when it uses Proton drive etc), so Proton would need strict opt-in, minimisation, no retention, and clear disclosure, but it would not necessarily break zero-access storage.

Again, we (users) shouldn't be the ones doing the homework on this. Let Proton work it out (or not). Given it's taken 4+ yrs to get Proton drive to work with Linux.... well....

[–] non_burglar@lemmy.world 2 points 22 hours ago

Are you new to corporate lies about privacy?

Proton is beholden to Swiss disclosure law, and swiss law caves to international requests pretty often.

Just assume your emails are being read by proton.

[–] Kirk@startrek.website 4 points 23 hours ago (1 children)

I've played around with Lumo... it uh, generates some text.

Maybe I'm missing the point of why someone would pay for that?

[–] SuspiciousCarrot78@aussie.zone 0 points 23 hours ago (2 children)

Ostensibly, because of the privacy footing Lumo claims

https://proton.me/support/lumo-privacy

https://proton.me/blog/lumo-2

[–] Kirk@startrek.website 3 points 19 hours ago (1 children)

I meant why would I pay for a program that doesn't really like, do anything? It literally only generates text.

[–] SuspiciousCarrot78@aussie.zone 0 points 17 hours ago* (last edited 16 hours ago) (1 children)

To clarify, do you mean you don't understand what a large language model can be used for (at all) beyond "just generating text"?.

Or do you mean specifically you don't understand what Lumo purports to do that's different from other llm?

Or something else?

I feel like this is a gotcha you're walking me into, and if were about to have a FuckAI moment, let's just not and say you won.

Basically, is this a genuine question or are you playing to the anti-ai crowd? It's hard to tell sometimes and I don't have the time or energy to get stuck in a circular debate with a bad faith interlocutor.

On the small off chance this is a legit question, try this from 22:15 on

https://www.youtube.com/watch?v=IOwvXarh72Y

[–] Kirk@startrek.website 1 points 13 hours ago

Ok so not just text, but walls of text? I still feel like there's something I'm missing. Lumo can't even like, turn on a radio station.

[–] non_burglar@lemmy.world 1 points 22 hours ago

I mean, it's a proton.me product. They say lots of stuff that isn't really true.

[–] sobchak@programming.dev 3 points 1 day ago (2 children)

I don't think Qwen 27B would make much sense. I'm pretty sure Deepseek is cheaper to serve at scale (because of the small active parameter set) and is "smarter." At least that's what is reflected by 3rd party provider pricing on Openrouter.

Reliable Proton Mail, Drive, Calendar and Contacts integration

I think this could cause major problems for privacy guarantees.

[–] ghodawalaaman@programming.dev 1 points 1 day ago (1 children)

how? aren't all of them already hosted on Proton's server. you are already trusting them for your data. how does Lumo make it worst?

[–] sobchak@programming.dev 1 points 1 day ago

Proton can't read your mail (big "*"); it's decrypted client-side. Feeding it to their LLM would violate that. I'm unsure about their other services.

[–] SuspiciousCarrot78@aussie.zone 0 points 1 day ago* (last edited 23 hours ago)

Deepseek, Minimax, GLM, Kimi etc are all massive and take serious compute and storage. Active parameter count and MoE tricks not withstanding, does Proton have the capacity and infrastructure to offer them at scale (let's say, 1 million subscribers) in good quality? Dunno.

Unlike Kagi, Proton hosts in house, not API. Lumo lite is very plausibly Qwen 27B based on what Proton have stated and shared.

It could be Qwen 3.6 35B-A3B or Qwen3.5-397B-A17B (but that makes no sense for a "lite"). Nothing else really matches the AAII scores they have stated.

https://proton.me/support/lumo-privacy

https://proton.me/blog/lumo-2

So, if the intention is to provide a proton product, a bigger LLM is going to cost them a lot more to operate, concurrency, MoE tricks and network effects notwithstanding.

Lumo is already capped at --ctx 128K at an unknown quant.

Proton is vary cagey about the details, for reasons you can imagine.

I think this could cause major problems for privacy guarantees.

Why? Either the privacy protections are legitimate and effective - in which case, a smaller, more capable product becomes a genuine USP.

It would costs less to run, costs less to buy, and is genuinely more useful than a bare LLM (or whatever thin harness or system prompt Proton uses

Else the entire Proton premise is a house of cards from the jump.

Either it's all private or none of it is.

[–] blackbeans@lemmy.zip 1 points 1 day ago

I personally like Lumo. There aren't many other services that offer privacy out of the box. And it's not some integrated solution so that I don't have to worry about data being shared with other services.