I would say that the figure of 1000 notes for a feed is too ...

semisol

npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj

hex

11ceef288f49c34d05e5136faa6e642a1d2a11e97ccc787ea7a1adad1235b3ca

nevent

nevent1qqsprnh09z85ns6dqhj3xma2dejz58f2z85henrc06n6rtddzg6m8jsprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgs99d9qw67th0wr5xh05de4s9k0wjvnkxudkgptq8yg83vtulad30gvgzurk

Kind-1 (TextNote)

2026-06-19T22:01:08Z

↳ 回复 事件不存在

16f4118bfe308282821c93dc87f2f52efc6b1aef90cfb3e7f093cac50809f80e...

I would say that the figure of 1000 notes for a feed is too much. It is usually enough to fetch 100-200.

Even in this case, advanced relays like Nostr.land already apply compression to the sent data.

The codepath duplication caused by kind 1 is limited. It would be treated like a reply either way, with slightly different parsing.

A migration to kind 1111 is simply not possible. It would involve the sequential migration of every post, with interaction from every author, to keep the IDs consistent. A half-complete migration would be useless.

For a switchover date, it would be hard to coordinate this. 50% of what, for example? Users? Clients? Who defines the “everything” set?

This could be implemented as a filter optimization, rather than a break. The benefits of kind 1111 for kind 1 posts are negligible, considering that a majority of the data usage from clients come from images, not relays.

Many clients also have a replies-inclusive feed, which users already switch to frequently.

原始 JSON

{
  "kind": 1,
  "id": "11ceef288f49c34d05e5136faa6e642a1d2a11e97ccc787ea7a1adad1235b3ca",
  "pubkey": "52b4a076bcbbbdc3a1aefa3735816cf74993b1b8db202b01c883c58be7fad8bd",
  "created_at": 1781906468,
  "tags": [
    [
      "e",
      "a4fb5332f58c8ffef52752765315788c33cb12a72340cede1510e375079a21da",
      "",
      "root"
    ],
    [
      "e",
      "16f4118bfe308282821c93dc87f2f52efc6b1aef90cfb3e7f093cac50809f80e",
      "",
      "reply"
    ],
    [
      "p",
      "0461fcbecc4c3374439932d6b8f11269ccdb7cc973ad7a50ae362db135a474dd"
    ],
    [
      "p",
      "56e2613abec15c3f9b07ceaaa301eaa6a0af5500546a1715b83be86a20245741"
    ],
    [
      "p",
      "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52"
    ],
    [
      "p",
      "e771af0b05c8e95fcdf6feb3500544d2fb1ccd384788e9f490bb3ee28e8ed66f"
    ],
    [
      "p",
      "52b4a076bcbbbdc3a1aefa3735816cf74993b1b8db202b01c883c58be7fad8bd"
    ],
    [
      "p",
      "3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d"
    ],
    [
      "p",
      "460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c"
    ],
    [
      "client",
      "Nostur",
      "31990:9be0be0fc079548233231614e4e1efc9f28b0db398011efeecf05fe570e5dd33:1685868693432"
    ]
  ],
  "content": "I would say that the figure of 1000 notes for a feed is too much. It is usually enough to fetch 100-200.\n\nEven in this case, advanced relays like Nostr.land already apply compression to the sent data.\n\nThe codepath duplication caused by kind 1 is limited. It would be treated like a reply either way, with slightly different parsing.\n\nA migration to kind 1111 is simply not possible. It would involve the sequential migration of every post, with interaction from every author, to keep the IDs consistent. A half-complete migration would be useless.\n\nFor a switchover date, it would be hard to coordinate this. 50% of what, for example? Users? Clients? Who defines the “everything” set?\n\nThis could be implemented as a filter optimization, rather than a break. The benefits of kind 1111 for kind 1 posts are negligible, considering that a majority of the data usage from clients come from images, not relays.\n\nMany clients also have a replies-inclusive feed, which users already switch to frequently.\n",
  "sig": "d0542bdd5dbd33c39ba2eacf5d0a721c331e8c1b80be7a4dc9b4da83422cb46c71c7b84e98b057df16de7009962055816d12993d9313daa519fc7c14e823d6a0"
}