Frenstr
This nip is (an attempt to) define semi private events to be shared among friends in a standard social media style fashion.
Friends list
The friends list is a private, replaceable event, intended to provide a client with a list of users the user has added to a friends list. This should be unassociated with followers/following, and is instead supposed to list which users are intended to be able to see private posts.
{
"id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>,
"pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
"created_at": <unix timestamp in seconds>,
"kind": 3810,
"tags": [
["d", "<list name 1>"],
["p", "<pubkey1>", "<pubkey2>"],
["d", "<list name 2>"],
["p", "<pubkey1>", "<pubkey2>"],
]
"content": " ",
"sig": <64-bytes lowercase hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
}Ideally relays should only provide kind 3810 events to the client of the event's owner itself through something like NIP-42 (likely, in practice, requiring a custom relay). They can provide multiple lists of npubs the creator wishes to provide certain events to (e.g. "family," "friends," "coworkers,") which would be used in NIP 3811 events.
Private Posts
{
"id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>,
"pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
"created_at": <unix timestamp in seconds>,
"kind": 3811,
"tags": [
["a": "<pubkey1>", "<pubkey2>",],
// ...
],
"content": <markdown enabled arbitrary string>,
"sig": <64-bytes lowercase hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
}
Most of kind 3811 events should act the same as a standard nevent. With the exception of rendering markdown, users should be able to reference events, users, reply, and more. However, when posting a kind 3811 event the user should select a list from a kind 3810 event and the client should populate the audience tag with the npubs in that list. Relays should then only provide the kind 3811 nevent to users in that list. Replies should follow the original post's audience list, for example, if Bob and Alice are friends and Bob replies to Alice, then the reply should only be visible to Alice's friends.
Goal
The goal here is to replicate something that resembles the privacy of a traditional social media service (what an oxymoron, I know). Relays would have all data unencrypted, and you'd have to rely on both relays and your friends to keep the data private. Clients would also ideally ignore kind 3810 & 3811 posts that were not intended for them, not displaying them if accidentally broadcast to a relay that did not filter them, and hiding replies by users that were not supposed to be able to view the event.
These events would be intended for semi private discussion between friends, and while it would not be ideal for content that could cause great damage if publicly distributed, would be aimed towards semi private discussions that would be more private than standard fully public microblogging.