Unbitten8366
My feedback
85 results found
-
4 votes
Unbitten8366
supported this idea
·
-
6 votes
Unbitten8366
supported this idea
·
-
3 votes
Unbitten8366
supported this idea
·
-
6 votes
Unbitten8366
supported this idea
·
-
7 votes
Unbitten8366
supported this idea
·
-
4 votes
Unbitten8366
supported this idea
·
-
3 votes
Unbitten8366
supported this idea
·
-
10 votes
Unbitten8366
supported this idea
·
-
6 votes
Unbitten8366
supported this idea
·
-
5 votes
Unbitten8366
supported this idea
·
-
37 votes
Unbitten8366
supported this idea
·
-
4 votes
Unbitten8366
supported this idea
·
-
541 votes
Unbitten8366
supported this idea
·
-
12 votes
An error occurred while saving the comment
Unbitten8366
supported this idea
·
-
35 votes
Unbitten8366
supported this idea
·
-
6 votes
Unbitten8366
supported this idea
·
-
14 votes
Unbitten8366
supported this idea
·
-
8 votes
Unbitten8366
supported this idea
·
-
6 votes
Unbitten8366
supported this idea
·
-
4 votes
Unbitten8366
supported this idea
·
If I close the app while Lumo is generating a response, the answer is lost. No buffer, no way to retrieve it later. The reason is clear: LLM server is stateless, client is the persistence layer.
Other AI assistants (Claude, ChatGPT) solve this server-side – finish generating, client picks it up later. Lumo can't do that because of the no-logs policy.
But it could work encrypted:
1. LLM generates response
2. Encrypts it with my public key (they have it – it's public)
3. Stores encrypted blob in a sort of "Lumo inbox"
4. Deletes everything on its end – stays stateless
5. Client reconnects → fetches encrypted blob → decrypts locally → saves with zero-access encryption
Same principle as Proton Mail handling incoming emails. Infrastructure already exists.
No logs, no plaintext on the server, no persistent state. Just an encrypted drop waiting to be picked up.