I doubt you are getting 8 hours of sleep

"Forward secrecy"

Does it assume that all or majority relays are permissionless?

I don't like it. It adds some obfuscation but doesn't really fix the problem because you have to start the conversation in the normal way (addressing the GW messages to the real pubkey) OR the receiver needs to create lists of alias' for each and every contact that they might one day receive a message from. Or am I missing something?

It fixes what's proposing to fix which is the metadata leak per message. The key alias event is similar to the conversation request on your ratchet proposal. And since wraps are already going back and forth, the public/relay is not able to distinguish between the key alias event and any other encrypted payload.

Current chat applications and email have forgotten that an address is not the same as an ID, treating the ID as the address. Emails and current chat applications send messages as [from: Alice's ID to: Bob's ID]. Regardless of how your geographical address changes, when Alice sends an email to Bob, it’s always [from: Alice's ID to: Bob's ID]. This compromises metadata privacy. However, letters work differently; they are [from: Alice's current geographical address to: Bob's current geographical address]. Keychat separates the receiving address and sending addresses from the ID, and the receiving address and sending addresses are also different. Keychat messages are [from: Alice's one-time sending address to: Bob's almost one-time receiving address]. This makes it difficult for outsiders and relay administrators to determine who is sending messages to whom.

So, the same thing we are proposing with this small change?

I think so. View quoted note →

Keychat reuses Signal protocol to update sending and receiving addresses for nearly every message.

Which is the same thing we are proposing, just just expand to use separate servers for each message as well.

FYI, NIP-04 is not the protocol anymore. It's NIP-17.

Yeah. In extreme cases, Keychat can achieve the following: changing the encryption key for each message, changing the sending address for each message, changing the receiving address for each message, changing the sending relay for each message, changing the receiving relay for each message.

You should make that the usual case not the extreme. Will Key Chat control a server as well or will it operate only with third party servers?

Users can choose which Nostr relay to use, as long as the relay supports NIP-4.

Why NIP-04? That has been fully deprecated right now. Please don't use it.

This should be a legacy issue because kind 4 was the earliest DM solution, and most clients and relays support it. We can change it later.

Additionally, we believe NIP-4 is the simplest and should not be discarded outright. It can complement other NIPs.

NIP-04 is not secure. I don't see any point on releasing something with a complicated double ratchet mechanism using that rudimentary/faulty encryption scheme.

Keychat's messages only use the kind 4 format, with encryption and decryption done using the double ratchet algorithm.

Then it's not NIP-4. You should just use a new kind otherwise current clients will not be able to decrypt it.

We need to fix the battery problem first.

I think @Sirius did this in iris

How much is it consuming for you? Somebody needs to do a comparison between scrolling through Twitter for 30 mins and through Amethyst. They shouldn't be very far from each other unless your relays are going crazy or if you don't have memory to keep profile pictures in cache.

Too much that's the problem. A comparison won't address the issue a change in settings will if we have a form of control on the feed because each request from a relay is a constant pull the feed from that & this relay. There needs to be an option to change it from constant to a customizable number if the user wants it to. I would keep mine off & only do manual pulls like how Instagram use to have. It would just be a swipe down from the top then the feed refreshes.