Adding ability to have expiring mutelist items

I’m working on implementing mutelists in Damus, and users are asking for the ability to have mute list items expire.

After talking with @jb55, one important design decision here is that tags in a kind:10000 mute list do not have the same parameters as kind1 events. For example, we do not include relay URL or petname as those do not make sense in this context. Instead the 3rd element (index: 2) will be the expiration time.

This is something that I’m currently developing for Damus, and wanted to submit this proposal before I get too far into the implementation to gather feedback.

Signed-off-by: Charlie Fish <contact@charlie.fish>
This commit is contained in:
Charlie Fish 2024-01-11 11:20:03 -07:00
parent 8331354947
commit 9ddb1bc658
No known key found for this signature in database
GPG Key ID: 5166A0FA37D2A28F

19
51.md
View File

@ -32,6 +32,8 @@ For example, _mute lists_ can contain the public keys of spammers and bad actors
| Interests | 10015 | topics a user may be interested in and pointers | `"t"` (hashtags) and `"a" (kind:30015 interest set)` | | Interests | 10015 | topics a user may be interested in and pointers | `"t"` (hashtags) and `"a" (kind:30015 interest set)` |
| Emojis | 10030 | user preferred emojis and pointers to emoji sets | `"emoji"` (see [NIP-30](30.md)) and `"a"` (kind:30030 emoji set) | | Emojis | 10030 | user preferred emojis and pointers to emoji sets | `"emoji"` (see [NIP-30](30.md)) and `"a"` (kind:30030 emoji set) |
Mute list (kind:10000) can contain an optional timestamp for each tag, indicating when that given mute item should expire. Clients SHOULD ignore tags where the current timestamp is greater than the expiration timestamp. If no expiration timestamp is provided, clients SHOULD assume the mute item is indefinite (until a more recent mute list is relayed).
## Sets ## Sets
Sets are lists with well-defined meaning that can enhance the functionality and the UI of clients that rely on them. Unlike standard lists, users are expected to have more than one set of each kind, therefore each of them must be assigned a different `"d"` identifier. Sets are lists with well-defined meaning that can enhance the functionality and the UI of clients that rely on them. Unlike standard lists, users are expected to have more than one set of each kind, therefore each of them must be assigned a different `"d"` identifier.
@ -80,6 +82,23 @@ Some clients have used these lists in the past, but they should work on transiti
} }
``` ```
### A _mute list_ with the items expiring on January 1st 2025 00:00 UTC
```json
{
"id": "a92a316b75e44cfdc19986c634049158d4206fcc0b7b9c7ccbcdabe28beebcd0",
"pubkey": "854043ae8f1f97430ca8c1f1a090bdde6488bd5115c7a45307a2a212750ae4cb",
"created_at": 1699597889,
"kind": 10000,
"tags": [
["p", "07caba282f76441955b695551c3c5c742e5b9202a3784780f8086fdcdc1da3a9", "1735689600"],
["p", "a55c15f5e41d5aebd236eca5e0142789c5385703f1a7485aa4b38d94fd18dcc4", "1735689600"]
],
"content": "",
"sig": "1173822c53261f8cffe7efbf43ba4a97a9198b3e402c2a1df130f42a8985a2d0d3430f4de350db184141e45ca844ab4e5364ea80f11d720e36357e1853dba6ca"
}
```
### A _curation set_ of articles and notes about yaks ### A _curation set_ of articles and notes about yaks
``` ```