nips
nips copied to clipboard
nostr-protocol
NIP-48 - multiple user encrypted message
How is this different from https://github.com/nostr-protocol/nips/pull/59 ?
Cc: @vishalxl
There is no need to create a chat room or to invite a public key. Participation is defined by global key sharing and it is simply done using p tag list.
This is pretty much exactly what I was thinking of for a group DM spec. very nice.
Don't worry about being kind4 compliant, this will need custom code by clients. This should be a different kind imo.
so the idea is whenever any user sends a new message they just generate a new global key for all participants? Anyone can do this? This might need to be spec'd on how group permissions are handled, who can add participants, etc. My concern is that this stuff is a bit underspecified, but otherwise the global key scheme encrypted to participants in the p tag is great.
The event issuer is responsible of the targeted public keys. A simple random generator can be used to create a 32 bytes sized global key. It can also be donne computing a sha256 hash of the event content before encryption.
This NIP makes encrypted chat group very easy to handle by relays.
Here is a live NIP-48 demo successfully relayed.
- [x] Event id :
d16bce2384b17c6b199c417c8b013f6c6a2016385af19bdf3f1f7bf0b2250483 - [x] Relay:
wss://relay.nostr.info
You can read here the python implementation.
@jb55
so the idea is whenever any user sends a new message they just generate a new global key for all participants? Anyone can do this? This might need to be spec'd on how group permissions are handled, who can add participants, etc. My concern is that this stuff is a bit underspecified, but otherwise the global key scheme encrypted to participants in the p tag is great.
I don't think it's possible with this approach. It's not really a "group chat room" it's just a DM that multiple people can read. I can send 10 people a DM and one of them could reply and only include 7 people on the response and/or add another 5. Each message is independent. It's more like an email than a room. The sender can include whoever they want on the to line and they'll be able to read it.
I think this NIP is valid as-is (maybe as a different kind to avoid breaking existing clients), but, to your point, this technique should really be considered for group chat too (e.g. https://github.com/nostr-protocol/nips/pull/59 ).
How would should we handle if someone was kicked out from the group chat, how should we revoked his access?
But I think this has some problems.
The new user can not read the older messages that before them joined, because the old event does not contained their pubkey and global key. Even the global key is random.
And than, how to prevent the spam message. Different to NIP-28, there is not a chat room definition event, clients only can subscribe group chat message with their pubkey, without chat room id limitation, spam broadcaster can send freely.
So I think these message should use a tag reference to a chat room create event, then other users can sign an event to join this chat room, the owner can block/mute members with sign events. Client should calculate the pubkey collection to encrypt the global key. When a user want to leave a chat room, they can delete the event which join the chat room.
