Private Event #739
Private Event #739
Conversation
|
@arthurfranca what do u think if we rename it as |
|
In many cases (DMs and group chats), it's feasible for clients to download all relevant messages. In other cases (large groups), a better approach would be to invite a relay's own pubkey to the group so it can 1. decrypt and index messages, 2. respond to regular REQs, and 3. serve the encrypted version of the event. This would probably need its own NIP so relays can signal support. Defaulting to full trust is less easily undone than starting with minimal trust and incrementally introducing trust as a group scales. It also leaves open the option to do this in other ways, for example with a DVM that does the decryption/indexing/authentication. |
|
I am not against the idea, but I have not had the need to add these extra filter possibilities to GiftWraps yet. |
|
@fernandolguevara I borrowed the "private" concept from the Simple Group Chat PR.
@staab The trend seems to be using gift wraps without "k" tag for inner event kind. The downside is requiring thin clients to download all kinds of gift wrapped events it may not even support/care. Also the created_at time window filter must be atleast 1 week for fetching recent events because of created_at shuffling.
Won't this not only entrust metatada to the relay but also content? |
|
Speaking as a thin client developer working on large groups, so far so good.
Yes, that's a good point. I realize I mis-read this NIP, I thought you were suggesting publishing the event "privately" instead of encrypting it. I see now that you're sending the encrypted event + metadata. That being the case I'm not 100% against this, but I would like to wait to see how people solve this in the wild before merging a standard. I think this problem can probably be solved outside the protocol. |
@staab Yes that's it. In fact, one can send encrypted or unencrypted events. For example it could be an encrypted kind 14 DM event directly without gift-wrap/seal/rumor package. Or encrypted kind 1 to be read by close friends only, encrypting a copy for each one of the close friends using their pubkeys (no need to add tags: ["p", ...] edit: as the access would be already restricted to each pubkey). But it could also be used for "hiding" cleartext NIP-28 group chat messages with a member list. |
@vitorpamplona adding some metadata to giftwraps, such as true created_at, real p tag, and a k tag, may help out clients not willing to store and sort (created_at) events client-side. They would need to fetch much less events. Perhaps giftwraps/seal/rumor should be ditched entirely, using the real event like the kind 14 DM event. Though I know you and staab had already put lots of effort on giftwraps/seal/rumor. |
|
I strongly believe gift wraps solve more problems than they introduce. There are lots of ways to make encrypted events indexable. |
As I said, I do not see that need from any client yet. And, of course, that need comes with the huge tradeoff of much less private events when such information is being shared with relays. There might be a use case for it, but I just don't see it right now. I don't know why would anyone go to the trouble of gift wrapping things if they are going to disclose attributes of the event to the relay anyway. Maybe there is a super specific use case of a personal relay just for this but I don't see it yet. |
Yeah the reality is this can be seen as a gift wrap alternative proposoal because both are methods to protect event metadata leakage. But this one is not only for entrusting metadata to relays but mainly for setting access control lists (ACL). So the metadata protection part is more of a side-effect of ACLs. |
Yes, I think this makes it potentially complementary to wrapping, but it's not a replacement. |
|
I'm against this. If this is how people want to roll, I'm back to suggesting that DMs should be done outside of nostr entirely. Why would we unsecure what we worked so hard securing? Either you hide metadata or you don't. If you want to expose metadata, then don't use giftwraps. Giftwraps give you an approximate time and a recipient. That is all that should be exposed, and that is all you really need. |
|
@mikedilger thanks for the comment. It looks like giftwraps are already being embraced by some client authors at least for DMs. |
|
@mikedilger sent me a GiftWrap kind 1. So, at least 2 clients are also working on private feeds. :) |
|
My earlier comment was in respect to using this for giftwrapped DMs. This could still be used otherwise and I won't outright stand against such a thing. But I suspect due to the costs involved few relays would implement it. @vitorpamplona I never sent you a giftwrap! You can't prove it! Also, I didn't appreciate kind 14 when I sent that. |
arthurfranca
force-pushed
the
private
branch
from
04bdd65
to
0ef710f
Compare
|
I add that while #784 Unbounded Lists (made up of many events, but just one for each list member) paired with Private Events make it possible to publish just 1 private event for each message in the case of private feeds and private chat rooms. In contrast, in an 1 million subscriber scenario, #716 Gift Wraps would have to publish one million events per each message. |
|
Just commited changes to make replies also private. |
|
Way too complex. Relay can't know beforehand by looking at the REQ filter if the requested events require AUTH and who should AUTH. |
Considering DMs and gift wraps, it bothers me the downgrade to DX because a client can't anymore filter by:
Here I propose trusting author/created_at/"k"or kind/"p" (and other one-letter tags) metadata to relays, introducing a new client-to-relay message.
The NIP suggests NIP-43 usage because NIP-42 slows down event fetching with awkward flow.
Read text here