### #Amethyst v0.73.1-alpha: New Private Message & Small Groups Protocol

This is an **alpha** release of the new GiftWrapped DMs. Please do not consider anything to be actually private until we have a **stable** version. This is early and there might be bugs that leak information.

You can activate this mode by clicking on the Incognito icon on the Chat screen. For now, only Amethyst supports this NIP. Thus we recommend only testing with other Amethyst users. Coracle and 0xChat are finishing their implementations in the upcoming days/weeks.

The claims of this new method are:

- Messages are encrypted with a superior XChaCha algorithm to each participant's public key individually.

- Chat participant identities, each message's real date and time, event kinds, and other tags are all hidden from the public.

- Senders and receivers cannot be linked with public information alone.

- Minimal trust in counterparties: Counterparties cannot expose verifiable details of your message, including the metadata, without exposing their entire user and all of their other messages (private key)

- There is no central queue, channel or otherwise converging event id to link or count all messages in the same group.

- There is no moderation role (i.e. no group admins, no invitations or bans)

- There is no chatroom secret that can leak or be mistakenly shared

- Messages can be fully recoverable in any client (that implements NIP-24) with the receiver or the sender's private key

- The protocol's messages can flow through public relays without loss of privacy. Private relays can increase privacy further, but they are not needed.

- The protocol is extensible to make any other event kind fully private (private likes, private reports, private long-form content, etc)

This implementation is very similar to how Slack manages direct DMs to multiple users. If three users are having a conversation and want to add a fourth person, the forth's user will not see the past. This guarantees maximum privacy: only the receivers of a message at the time of writing will ever be able to decrypt it.

In the near future, we will implement Forward Secrecy through:

- Users will be able to opt-in for "Disappearing Messages" that are not recoverable with their private key

- Users will be able to also opt-in to sharing messages with a new key exclusive for DM backup and recovery.

Details:

- Support for NIP-24 Private Messages and Small Groups

- Support for NIP-59 Gift Wraps & Seals

- Support for NIP-44 Versioned Encrypted Payloads

- Support for XChaCha encryption algorithm

- Fix: Loading of Alby's NWC URI

- Fix: Only requests notification permission once.

- Fix: Show reposts and reactions in search

- Fix: Signed byte used for array slice inside the TLV by nostr:npub1xpuz4qerklyck9evtg40wgrthq5rce2mumwuuygnxcg6q02lz9ms275ams

- Fix: Global feed only shows events from Global-active relays by nostr:npub10npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qzztl5h

- Updates Dutch translations by nostr:npub1w4la29u3zv09r6crx5u8yxax0ffxgekzdm2egzjkjckef7xc83fs0ftxcd

Download:

- [Play Edition](https://github.com/vitorpamplona/amethyst/releases/download/v0.73.1/amethyst-googleplay-universal-v0.73.1.apk)

- [F-Droid Edition](https://github.com/vitorpamplona/amethyst/releases/download/v0.73.1/amethyst-fdroid-universal-v0.73.1.apk)

Reply to this note

Please Login to reply.

Discussion

RI on cue with another update 😁

Once it's vetted, just make it default

Just imagine not earning bitcoin while playing on your mobile phone! Are you really sleeping on that?

For more infos read our latest habla post:

https://habla.news/a/naddr1qqxnzd3exyurgvf3xsurxv3jqgsfpr28k6zr6ymqsrr3k6d9fe76gjufa7q6cjfrmkr4jqna52ln3tgrqsqqqa28m97f5n

Keep going nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z!!! You are doing the lord's work!

This will change a lot things 👇

nostr:note1kn8ynagvx506hf3dq2wjzht6zdehqefn760tmnqseh5g2zks896q2gl3p3

"...until we have a stable version..."

*looks on screenshot*

"this is quite stable"

nostr:npub1fw5wsmfdj7ykmjfn0sl9qp533y7hx96h9lvplz6pmhd9mzwn9hjqvq2rfr olha aĂ­ o que estĂĄ chegando no estĂĄvel.

Want use ametyst on ios or website

I actually soft released coracle's the other day. Only available when using private key login however, so it is not recommended for use, only tinkering with a disposable key. I have some open PRs to nos2x, nostr tools, and alby to add support for nip 07.

ohh.. that's why I couldn't find it. :)

It's behind a "feature flag", aka a feature no one uses

đŸ”„

Exciting to see. I’ve wanted to be able to wrap all events as encrypted.

I’m curious if you considered using MLS?

https://datatracker.ietf.org/group/mls/about/

Also, I think Wrapping alone is not enough because the receiver can always unwarp and simply re-broadcast the wrapped event. The one we did forces another Seal event of an unsigned event.

The Wrap has the receiver. The Seal is signed by the sender. But only when both are open, you can see the contents.

The Wrap without a Seal means the receiver can either expose the inner event if signed OR, if you don't sign the inner event, the receiver will not be able to verify who the sender is.

Seals alone are signed by the sender, but don't have a destination or any other ptags. So, they are not that useful by themselves.

Fantastic. Y’a une implĂ©mentation PC Windows/Linux ou iOS ?

C'est encore tout neuf et en very beta test.

Je suis super chaud. J’ai pas encore compris fondamentalement l’intĂ©rĂȘt d’un truc aussi compliquĂ© et j’ai une solution bcp plus simple en tĂȘte. Mais je suis ravie de voir que sa avance. On a vraiment besoin de ça

Plus simple ?

vas y dit pour voir

L’idĂ©e gĂ©nĂ©rale ça serait de crĂ©er deux utilisateurs et de donner la clefs Ă  tout les membres du groupe. Qd tu envoies un message tu fais un DM entre ses deux utilisateurs en tirant au hasard l’expĂ©diteur pour que d’un point de vue extĂ©rieur ça ait l’air d’une conversation par DM classique entre deux utilisateurs et personne ne peut connaĂźtre les participants du message. Cela serait un canal de discussion qui serait le group chat.

A l’intĂ©rieur de se canal, les messages doivent ĂȘtre signĂ©s avec la clef privĂ©e NOSTR des utilisateurs pour qu’on sachent qui parle et que se soit infalsifiable.

Également je propose de crypter tout les messages via RSA ou ElGamal grĂące Ă  PGP. Car on peut faire du multisig 1 of n se qui est particuliĂšrement adaptĂ©. Ces clefs publiques peuvent ĂȘtre Ă©changĂ©es via le rĂ©seau de DM NOSTR classique, pas dans le canal, directement entre les utilisateurs.

Ainsi, une personne qui récupérerait les clef du canal de discussion récupérerait juste des messages crypté avec aucune info sur les destinataires ni les expéditeurs. Juste du RSA ou du ElGamal.

Le seul moyen de crack ce truc est de recup la clef privĂ©e d’un des participants, mais c’est le cas de n’importe quel group chat.

Pour la forward secrecy, je propose qu’une nouvelle clef RSA ou ElGamal soit Ă©changĂ©e par DM entre les participants en dehors du canal, par DM to le X message en fonction du niveau de forward secrecy dont on a besoin.

🔾Aucune modification du protocole n’est requise.

🔾Seul les clients doivent mettre en place cette mĂ©canique.

🔾Je pense mĂȘme Ă  dev un client qui fait uniquement ça
 mais malheureusement avec le bĂ©bĂ©, j’ai pas le temps.

L’idĂ©e gĂ©nĂ©rale ça serait de crĂ©er deux utilisateurs et de donner la clefs Ă  tout les membres du groupe. Qd tu envoies un message tu fais un DM entre ses deux utilisateurs en tirant au hasard l’expĂ©diteur pour que d’un point de vue extĂ©rieur ça ait l’air d’une conversation par DM classique entre deux utilisateurs et personne ne peut connaĂźtre les participants du message. Cela serait un canal de discussion qui serait le group chat.

A l’intĂ©rieur de se canal, les messages doivent ĂȘtre signĂ©s avec la clef privĂ©e NOSTR des utilisateurs pour qu’on sachent qui parle et que se soit infalsifiable.

Également je propose de crypter tout les messages via RSA ou ElGamal grĂące Ă  PGP. Car on peut faire du multisig 1 of n se qui est particuliĂšrement adaptĂ©. Ces clefs publiques peuvent ĂȘtre Ă©changĂ©es via le rĂ©seau de DM NOSTR classique, pas dans le canal, directement entre les utilisateurs.

Ainsi, une personne qui récupérerait les clef du canal de discussion récupérerait juste des messages crypté avec aucune info sur les destinataires ni les expéditeurs. Juste du RSA ou du ElGamal.

Le seul moyen de crack ce truc est de recup la clef privĂ©e d’un des participants, mais c’est le cas de n’importe quel group chat.

Pour la forward secrecy, je propose qu’une nouvelle clef RSA ou ElGamal soit Ă©changĂ©e par DM entre les participants en dehors du canal, par DM to le X message en fonction du niveau de forward secrecy dont on a besoin.

🔾Aucune modification du protocole n’est requise.

🔾Seul les clients doivent mettre en place cette mĂ©canique.

🔾Je pense mĂȘme Ă  dev un client qui fait uniquement ça
 mais malheureusement avec le bĂ©bĂ©, j’ai pas le temps.

C'est aussi trÚs compliqué (il faut décrire le workflow et le format des messages trÚs precisemments). Par ailleurs il y a un échange de clef privée aux membres ce qui en soit est problématique.

Ça ressemble Ă©galement Ă  des messages wrappĂ©

Oui, mais sans avoir Ă  ajouter un kind inutile Ă  mon avis. Y’a 0 server Ă  modifier si tu le fais pas. Tout les server accepte la fonction DM, et c’est suffisant. Pour moi c’est inutile de rajouter des complications Ă  ce niveau. Un autre avantage c’est que d’un point de vu extĂ©rieur, si tu ajoutes un kind, tu lĂšve l’ambiguĂŻtĂ© de savoir se que c’est.

Tu sais que sur Nostr la grande majorité des nips n'induisent pas de modification de relai ?

Typiquement je bosse sur une date vending machine (nip90). C'est totalement neutre cÎté relai.

Je le répÚte mais si tu penses que ton idée est bonne, tu peux juste décrire un nip avec le workflow trÚs précisement (y compris la maniÚre d'échanger la clef privée du canal DM).

Autre pont. Tu parles de chiffrement reposant sur l'Infra a clef public RSA / elgamal.

Ça veut dire qu'un utilisateur doit en plus de sa clef Nostr avoir une clef RSA ?

AprĂšs avoir fait quelques recherches, il semble que c’est le plus adaptĂ©. Mais cela doit ĂȘtre une clef jetable. Si non tu as pas de FS.

J’ai pas fini de faire le tour des nip sur la question. Avant de poster un NIP, je prĂ©fĂšre tout lire pour ĂȘtre certain de ne pas polluer le truc avec une idĂ©e dĂ©jĂ  dĂ©battu.

HonnĂȘtement je prĂ©fĂšre arriver directement avec du code qui marche.

Je ne vois pas en quoi les échanges des clefs privée du canal sont un problÚme.

Qd a RSA/ElGamal c’est seulement les clefs publiques qui sont Ă©changĂ©es Ă©videmment

C’est marquĂ© dans le post du coup ! Et bien vivement que se soit le cas !

The real alpha is you 💜