E2EE suggests that only the user (or at least only people the user knows about in the case of e.g. group chats) is able to see/access the decrypted data, which is false. Limitless does not decrypt data on the client using a key only the user has access to, it decrypts the data on the server (in this case using AWS KMS) and sends it to the client. Even if we remove just decrypting everyone’s data out of the equation using AWS KMS (since the user does not control the key), you could trivially write a Cloudflare Worker (since you use Cloudflare on your API subdomain) that simply sends the (unencrypted) API response along with the email from the Supabase JWT used in the header to a server that accumulates everyone’s recording names, transcripts, generated notes and generated summaries. If someone gained access to your Cloudflare account they could also do this. You’re advertising Limitless as if you aren’t able to see people’s transcripts even if you wanted to, which is false. Even your employer can if they TLS MitM you with their own TLS certificates, which is not rare. On the other hand, Signal cannot see your data unless they modify client code, nor can your employer unless they install a modified Signal client on your device or install spyware on your device, which is reading decrypted data from memory. This is what separates encrypting at rest and E2EE (which you say your solution is just as secure as and is better than) for the end user and it feels like false advertising. Limitless, your employer and a potential hacker can all read your data, at the minimum while you’re using Limitless.