Finally I wrote again 😃. This time it's about God. (Unfortunately in german :P) https://lufrai.org/blog/antwort-von-gott

Amazing work 😎🔥💪! Did I read this correctly that even the group chats are encrypted 😮? Since I am also working on an e2e encrypted chat app (for a different use case), I am wondering how you pulled the group encryption through 😅. My own approach doesn't rely on relays, so I am able to fully encrypt the events including all metadata. I wonder how this would have to work if I were using a real relay.

Why not for automated testing? 🤓

To be fair, after further research, most databases actually do not delete data properly. If you wanna get rid of sensible data, in Postgres and Sqlite you have to run an extra "Vacuum" command, in Mysql you have to "Purge". Feels like the only scalable way for guaranteed deletion is to either use no db at all or to go multi-tenant and create dbs per entity. E.g. in my app I wanna properly delete chat rooms after some expiration time, so maybe the way to solve this is to create one db per chat room 🤔.

Noooo 😂, I wanted to know if I should use A or B, and now I end up having to choose between, A, B, C or D 🤣... Honestly though, applesauce looks intriguing 😮, thanks for the advice ❤️!

Ohhh 🤔, one uses the other? So choice is again an illusion 🤯😤!! How dare this happen in the nostr world 😤! Jokes aside 😁, thank you for the advice!

I'll check it out more closely for sure 🙂, thank you for the recommendation!

> You could also control how often group keys were rotated This is indeed an interesting feature to have 🤔. I need to think more about this :). For my short-lived chat rooms app I am also thinking about a nuke-button feature for the room owner, deleting the room instantly. Basically a radical forward secrecy mechanism 😂

Or to make it short: most humans are hypocrites 🙈.

Moinsen 🙋‍♀️🍻

I only use nostr for the signing, the e2e encryption will be a custom solution 😅

Ah 😅, gotcha. MLS indeed sounds like the best way to go, though I wonder how good it will work out with nostr relays 🤔. From what I know about the protocol, it highly depends on the ability to delete the key content on the transport service, which usually isn't guaranteed with nostr relays 🙈. I think it's best to use it with self-hosted relays that you know 100% will delete the notes. Thing is, this again largely negates nostr's decentralization qualities 🫠. Also afaik the other tradeoff about MLS is that users who join the chat late, will not see old chat messages, which not always is desired. My app has a very specific use case (shareable, short-lived chat rooms for quickly finding answers/solutions in your social graph, including for questions that are big-brother incompatible). So my summarized approach is: - Have multi-tenant dbs on the server, per chatroom. Delete the chat room db including all messages after the chat room expires (7 or 30 days). - Create an openpgp key-pair on the client, save the public key and 50% of the secret on the server, save the private key and 50% of the secret in the chat room url after the hash/anchor. Create a qrcode of that url that can be shared with trusted friends. - Have an optional extra secret that is neither stored on the server nor url. This optional secret has to be shared with friends on a separate channel for extra security. - All chat room messages are encrypted client side and stored on the chatroom db. - Ideally the server should be behind TLS with perfect forward secrecy enabled. - Users who join can send messages anonymized or signed with their nostr key. The note is encrypted and the server never sees the plain content. Users who join the chat room also have the option to send private messages to the chat room creator, encrypted with a separate public key, only readable by the chat room creator. I am also playing with the thought to have an MLS option on chat room creation - basically the feature choice between MLS and message history.

> In PostgreSQL, an UPDATE or DELETE of a row does not immediately remove the old version of the row. Aiaiai 🙈, using postgres for sensitive data maybe isn't a great idea after all? 🥴 https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-SPACE-RECOVERY

Hmmm 🤔, it looks a bit alpha-ish 🙈😁

Sure 😅, I was expecting a nostr-tools specific reason 😅. Obviously during tests its better to mock things than to e.g. connect to unreliable relays 😉👍.

So what do you prefer for nostr apps, nostr-tools or ndk? 🤔 I am building a proof-of-concept for an e2e encrypted, anonymous chat room with the ability to optionally sign messages with your nostr identity 😁.

Ist der Text an Kleinkinder gerichtet 😂? Klassischer Züri Infantilismus 🤦‍♀️...

Simple solution to the Fermi paradox: they looked at our "leaders" and came to the conclusion that we are not worthy 😅. GM 🙋‍♀️

Lets go! Humans tired of this playbook could now switch to , but they like their walled gardens 🥴

Feels a bit overengineered 😂, but cool work ❤️!!

On his screen 😂👇