New proposal, one time connection keys.

Option for temporary, disposable npubs that allow sending one single message request to the unexposed main npub.

Also combined with a message request interface with PIN authentication, or fixed length audio or video identity verification clip recording presets.

Imagine if we could put an AI agent in charge of maintaining your Amethyst. You could just write a DM to the agent asking for a new feature, the agent would change the app in place and give you back to test. If things work well for you, you could submit the change to your friends. If enough of your friends like and use it, the main repo could take that in. Maybe that's the future we want.

Got it. No other option is currently available for logging into iOS apps. It’s being worked on. There is a dev building something similar to Amber for the iOS side of things, but no ETA.

Keychat's current MLS KeyPackage event is a replaceable event, which makes it easier to update and manage the KeyPackage. Events are replaceable, which means that for each combination of pubkey and kind, only the latest event must be stored by relays, and older versions may be discarded.

In addition, after a new member joins a group, an update commit is performed immediately.

Keychat can also publish the KeyPackage using NIP-EE’s kind: 443.

What do you think about using replaceable events to update and manage KeyPackages?

Really glad you like the idea of deriving the receiving address from the exporter_secret.

If the Nostr group ID doesn't change, external observers can see how frequently and at what times the group communicates, even though the ID itself is anonymous. If I remember correctly, NIP-EE just hasn't specified how to update this ID yet, but it plans to in the future.

A gift wrap event is a kind:1059 event that wraps any other event. It's a general-purpose gift wrap — the inner event can be of any kind. Think about NIP-17 DMs: external observers can only see that it's a kind:1059 event.

We've been using the metaphor of a letter: the envelope is where the sending and receiving addresses are written. To protect metadata privacy, both the sending and receiving addresses need to be updated frequently.

NIP-EE group events

{

"id": ,

"kind": 445,

"created_at": ,

"pubkey": ,

"content": ,

"tags": [

["h", ]

],

"sig":

}

In the NIP-EE group event, the content field is first encrypted using MLS, and then encrypted again using NIP-44. The NIP-44 encryption is done using a Nostr keypair generated from the MLS exporter_secret to calculate the conversation key value. Keychat follows the same approach. The public key—used as the sender address—is randomly generated, and Keychat does this as well.

The difference lies in the receiving address. In NIP-EE, the receiving address is set using:

"tags": [ ["h", ] ]

The h tag represents the Nostr group ID (from the Nostr Group Data Extension). Updating the group ID requires a member to send a commit message.

Keychat, on the other hand, uses:

"tags": [ ["p", ] ]

This receiverPublicKey is derived from the MLS exporter_secret, so it updates automatically without the need for a separate commit message.

Keychat uses kind: 1059, as it satisfies the constraints of kind 1059, enabling the integration of both MLS messages and NIP-17 DMs in a unified format.

Interoperability between the three clients in an MLS group isn’t hard, since they’re all built on OpenMLS and use shared relays.

The main difference is that Keychat uses a different “envelope” format for MLS messages compared to the other two clients. We need to write a note explaining the design rationale behind this “envelope” format, and we truly hope to have 0xChat’s understanding and support.

Anything we can read?

We strongly recommend reading the MLS specification directly, rather than relying solely on NIP-EE.

Will Keychat, 0xchat and White Noise all be able to interoperate? I can't quite picture how the UX would work if I create a group in Keychat and then somehow who uses 0xchat or White Noise wants to join.

Great to hear!

We're working on an all-in-one solution for Communitues and Private groups.

Both relay and blossom (and maybe even mint at some point).

:110percent: need that state sharing yes.

If you have your own relay that you Auth on, it can be relatively straightforward.

Or if the group has their own relay, cool stuff can be done too.

I like the incentives there.

Want great UX, frictionless state sharing, extra privacy guarantees, ... 👉 Get a relay.

Although I guess as long as you stay in your app and on your device, and everyone else in the group stays on their app and on their device, then the cryptographic state is all good and it flows?

Need a good FAQ on that somewhere, lemme know if you find one.

It's not in strangers either. I'm on latest testflight version.

I added another account same app and started a group with that one, it worked.

Ah that wold explain it.

I don't see the group, or any invite.

Trying it out but I get stuck with the loading spinner on create

It's not an event if it isn't.

😄 这次开发 android signer 的时候，记得把 nowser 也给支持一下

I just wanted to encourage Auto-Layout in case you rebuild the interface, too many apps leave it out. I think the App Store should actually require it for all new releases. I do remember it as solid in base 0xChat.

Do you support a native side or menu bar too?

I like these elements, though they could change somewhat noticeably with the rumored UI redesigns at WWDC25 in two weeks.

One more thing

- Auto-Layout UI for universal app support, eg. iPad, Mac Catalyst