• 13 Posts
  • 274 Comments
Joined 3 months ago
cake
Cake day: May 14th, 2026

help-circle



  • I think I’m going to put a declarations.md that says something like “I made this for me, but I’m sharing it with the world. If you find it useful, use it and let me know! If you find issues, submit request and I’ll look but no promises. And if you want feature X … fork it and build it. The code’s yours, with my blessings. PS: I don’t accept PRs, sorry”.

    I code for fun; I’m not looking for a third unpaid job. That’s what parenting is for.



  • Interesting question. If you are asking for an LLM (that is self-hosted and can do that?), you’re going to need to provide some significant tooling, like rag / documentation, troubleshooting, sort out concurrency, front end etc. Honestly…it just easier to point them at a YouTube (network chuck has good stuff).

    It absolutely can be done and it absolutely can be valuable - for you personally. But if they’re having trouble doing basic things like installing jelly fin, they have zero chance of doing something like that themselves.

    Honestly, I think your easiest option for your non-technical friends is just to point them at one of the cloud providers, like chatGPT or Claude.

    OTOH, how much work are you willing to put into this and what’s your GPU / LLM set up like? There

    Your basic foot in door starting point is going to be installing and provisioning OpenWebui, getting a good local model up and running (Qwen3.6-35B or Qwen3.6-27B) and creating a “Knowledge Base” in OWUI with requisite documentation. You’ll need to set up tailscale / headscale so they can access your OWUI instance from their homes, too.

    If you’re serious about this, write back and I’ll thumbnail sketch it out for you. It’s a good project and I’ve done similar. There are real complexities to something like this beyond just “install ollama, lol done”.













  • SuspiciousCarrot78@aussie.zoneOPtoPrivacy@lemmy.mlReview of Proton's Lumo 2.0
    link
    fedilink
    arrow-up
    1
    arrow-down
    1
    ·
    edit-2
    6 days ago

    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…


  • 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.



  • SuspiciousCarrot78@aussie.zoneOPtoPrivacy@lemmy.mlReview of Proton's Lumo 2.0
    link
    fedilink
    arrow-up
    2
    arrow-down
    2
    ·
    edit-2
    6 days 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.