Re: [PATCH] Draft for adding expiration mutelist

[William Casarin]

Hey!

Thanks for doing this. Expiring mutes is definitely a cool feature.

A few comments:

On Thu, Jan 11, 2024 at 10:39:57AM -0700, Charlie Fish wrote:
>---
> 51.md | 17 +++++++++++
> README.md | 87 ++++++++++++++++++++++++++++---------------------------
> 2 files changed, 61 insertions(+), 43 deletions(-)
>
>diff --git a/51.md b/51.md
>index 47ed899..44cad9c 100644
>--- a/51.md
>+++ b/51.md
>@@ -80,6 +80,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]

Only strings are allowed in tag arrays.

Also, do petnames and relay hints really matter for mutelists? The
parameters from kind1 events don't have to be the same just because it's
a p or e tag. This is a different context and I think it's reasonable to
have different parameters here.

["p", "a55c15f5e41d5aebd236eca5e0142789c5385703f1a7485aa4b38d94fd18dcc4", "1735689600"]

Maybe we can make a note of this somewhere because I'm sure someone will
bring it up.

> ```
>diff --git a/README.md b/README.md
>index 678818d..bf963d6 100644
>--- a/README.md
>+++ b/README.md
>@@ -182,49 +182,50 @@ Please update these lists when proposing NIPs introducing new event kinds.
>
> ## Standardized Tags
>
> [..]
>+| ----------------- | ------------------------------------ | ---------------------------------------- | ------------------------------------- |
>+| `e` | event id (hex) | relay URL, marker, expiration timestamp | [01](01.md), [10](10.md) |
>+| `p` | pubkey (hex) | relay URL, petname, expiration timestamp | [01](01.md), [02](02.md) |

I think this is just confusing to add this here, since this parameter
it's not tied to every kind. I think this is a issue with this table in
general. Maybe we can just not put it in here and keep it in the NIP
specific to mutelists.

>+| `a` | coordinates to an event | relay URL | [01](01.md) |
>+| `d` | identifier | -- | [01](01.md) |
>+| `g` | geohash | -- | [52](52.md) |
>+| `i` | identity | proof | [39](39.md) |
>+| `k` | kind number (string) | -- | [18](18.md), [25](25.md), [72](72.md) |
>+| `l` | label, label namespace | annotations | [32](32.md) |
>+| `L` | label namespace | -- | [32](32.md) |
>+| `m` | MIME type | -- | [94](94.md) |
>+| `r` | a reference (URL, etc) | petname | |
>+| `r` | relay url | marker | [65](65.md) |
>+| `t` | hashtag | expiration timestamp | |
>+| `alt` | summary | -- | [31](31.md) |
>+| `amount` | millisatoshis, stringified | -- | [57](57.md) |
>+| `bolt11` | `bolt11` invoice | -- | [57](57.md) |
>+| `challenge` | challenge string | -- | [42](42.md) |
>+| `client` | name, address | relay URL | [89](89.md) |
>+| `content-warning` | reason | -- | [36](36.md) |
>+| `delegation` | pubkey, conditions, delegation token | -- | [26](26.md) |
>+| `description` | invoice/badge description | -- | [57](57.md), [58](58.md) |
>+| `emoji` | shortcode, image URL | -- | [30](30.md) |
>+| `encrypted` | -- | -- | [90](90.md) |
>+| `expiration` | unix timestamp (string) | -- | [40](40.md) |
>+| `goal` | event id (hex) | relay URL | [75](75.md) |
>+| `image` | image URL | dimensions in pixels | [23](23.md), [58](58.md) |
>+| `lnurl` | `bech32` encoded `lnurl` | -- | [57](57.md) |
>+| `location` | location string | -- | [52](52.md), [99](99.md) |
>+| `name` | badge name | -- | [58](58.md) |
>+| `nonce` | random | -- | [13](13.md) |
>+| `preimage` | hash of `bolt11` invoice | -- | [57](57.md) |
>+| `price` | price | currency, frequency | [99](99.md) |
>+| `proxy` | external ID | protocol | [48](48.md) |
>+| `published_at` | unix timestamp (string) | -- | [23](23.md) |
>+| `relay` | relay url | -- | [42](42.md) |
>+| `relays` | relay list | -- | [57](57.md) |
>+| `subject` | subject | -- | [14](14.md) |
>+| `summary` | article summary | -- | [23](23.md) |
>+| `thumb` | badge thumbnail | dimensions in pixels | [58](58.md) |
>+| `title` | article title | -- | [23](23.md) |
>+| `zap` | pubkey (hex), relay URL | weight | [57](57.md) |
>+| `word` | keyword or phrase | expiration timestamp | [51](51.md) |
>
> ## Criteria for acceptance of NIPs
>
>--
>2.39.3 (Apple Git-145)
>

[Charlie Fish]

So I've only really worked with 1 nostr client (Damus). But my question would be if other clients have code that has them in a certain order. So if they expect that in a tag array if the first value is "p" that the 3rd value is always a relay URL, then this proposal would cause problems.

Which is why I implemented it the way I did. ie. not having differing tag structures dependent on the `kind`.

But I like the simplicity of your approach. And I agree that relay URL and petname are useless in this context.

[William Casarin]

On Thu, Jan 11, 2024 at 11:05:43AM -0700, Charlie Fish wrote:
>So I've only really worked with 1 nostr client (Damus). But my question
>would be if other clients have code that has them in a certain order.
>So if they expect that in a tag array if the first value is "p" that
>the 3rd value is always a relay URL, then this proposal would cause
>problems.

Yes if they make the assumption that p tags always have these params.
Damus was technically coded it this way as well, before we switched to
the TagConvertible protocol which adds more flexibility for parsing tags
in different contexts.