Feature: private profile metadata

[SubatomicPlanets]

As far as I know, certain data, such as name, profile picture, and description, is accessible to anyone who has your public key. This makes sense for a lot of the applications that Nostr is used for, but for a private messenger app it may not be ideal.
Imagine I want to convince my friend to switch from Signal to a Marmot messenger. He wants to use his real name and an image of himself, as he did on Signal. But now he learns that anyone can access this data from his public key, and it is stored unencrypted on multiple relays!
It would be nice if there were a way to hide this info (or some of it, most importantly the profile picture) until a chat is started.

Since Marmot is used in many use cases, this would be an optional feature. Social media DMs would simply use the public profile metadata, while private messengers would use this feature. Some apps might make it a setting or use a mix, depending on what they need and how this gets implemented.

This feature would work something like this:
I start a chat with someone and can't see their profile picture (and maybe other data) until they accept my invite.
They, on the other hand, should probably see my profile picture (and maybe other data) before accepting, so they know who I am.
Larger groups would make this a bit more complicated though, so I don't know how feasible this is...

[erskingardner]

Imagine I want to convince my friend to switch from Signal to a Marmot messenger. He wants to use his real name and an image of himself, like he did on Signal. But now he finds out that anyone can access this info from his public key, and it is stored unencrypted on multiple relays.

yeah - this is a good point. nothing straightforward jumps immediately to mind so we'll have to think about how to do this in an encrypted way. in the meantime, we should almost certainly make it clear that the profile data you're editing in White Noise is going to be publicly available.

[SubatomicPlanets]

I had an idea on how to do this in DM groups (2-member groups) in a simple way. For larger groups this isn't ideal, but it still sort of works. This is the idea:

Clients still use public metadata by default, but members of a group can now send a new event kind called "private profile metadata" into the group. The event would look like this:

{
  "id": <id>,
  "pubkey": <pubkey>,
  "created_at": <created_at>,
  "kind": 27777 (or any new event kind that is in the ephemeral range),
  "tags": [
    ["description", <the "about" section of the profile>]
    ["imeta", <imeta tag for profile picture, just like encrypted media in chat messages>]
  ],
  "content": <the profile name>
}

Both the description and imeta tags are optional. (Of course this event can be structured differently, I just did it like this for now. Maybe it should put all the data in the content field like a kind 0 event...)

When Bob creates a new DM group, he immediately sends this event (if he has private profile data). When Alice accepts the welcome and also has private profile data, then she sends her own private profile event. When this event kind is received, clients can download the encrypted picture, store it, and update the UI with the new name, picture, and description.

The key here is that clients would prioritize the public data. So if a profile has a public profile picture, name, and description, then a private profile metadata event has no effect. This is powerful because it means users can customize privacy settings (like making the name and description public, but keeping the profile picture private), or different clients can behave differently. It also means you don't get any weird problems when profiles have a public picture and a different private picture (it would show a different image depending on whether you got the private profile metadata event or not. Always prioritizing public metadata fixes this).

In larger groups this isn't ideal (members would have to resend this event so the new member gets the metadata). I think it's still better than nothing since this basically allows private profile data in DM groups, and it's still fully optional. But ideally there would be a nicer way to do this so larger groups can use this feature too.

I also think the kind of this event should be in the ephemeral range. Right now this doesn't really have an effect, but if MDK didn't save these ephemeral events (see this) as chat messages, then it would be a lot better since it wouldn't enter the chat history. clients would simply receive it, save the profile data, update the UI, and move on. So ephemeral makes more sense here, I think.

If a user updates their private metadata, they send this event to all their groups again (this part is also not ideal if the user has many groups...)

Let me know what you guys think. I may have overlooked something obvious, but I think this makes sense. This way of doing it does have a few quirks (for example, you can send different events to multiple groups, so each one will have different data...), so I don't think this should get implemented as is. I just wanted to start a conversation about this feature (I really want private metadata for my app).

Edit: forgot to mention that the encrypted private profile picture would not use any group-related key for encryption. Instead, one way of doing it is using a random key to encrypt it and then putting that key in the private profile event. This means the image only has to be uploaded to a blossom server once, and any member who received the event can decrypt it.

[benthecarman]

@SubatomicPlanets we implemented a version of this in pika just creating a kind0 event and broadcasting that in the group

justinmoon/pika#368

[SubatomicPlanets]

@benthecarman That's cool, but I believe in that version the profile picture is not encrypted, right? My use case isn't really per-group profiles, I just need 1 profile where the data has to be private (only accessible to people you know).

[benthecarman]

We encrypt the profile picture to the group the same way you do normal media messages you send