> Asking relays to compute WoT so you don't have to upload l...

Leo Wandersleb

npub1gm7tuvr9atc6u7q3gevjfeyfyvmrlul4y67k7u7hcxztz67ceexs078rf6

hex

832e74890220f8386086fcf0ab0fecc5dfc3b23ca42542603cc3c95920eb803b

nevent

nevent1qqsgxtn53ypzp7pcvzr0eu9tplkvth7rkg72gf2zvq7v8j2eyr4cqwcprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgsydl97xpj74udw0qg5vkfyujyjxd3l706jd0t0w0turp93d0vvungjfr7kv

Kind-1 (TextNote)

2026-02-21T19:59:25Z

↳ 回复 ee11a5df... (npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c)

In general I agree with both of you. Filtering can be done either side. Personally I prefer client-side filtering and dumb relays because it puts me...

Asking relays to compute WoT so you don't have to upload long lists of pubkeys has performance consequences and I'm not sure if it is better or worse.

The relay could

  • cache lists
  • work with lists from events for direct follows
  • explicitly take a follows-degree argument to do the heavy lifting for the client

I find most important that these views on nostr are pubkey dependent and not relay dependent. If I provide a giant filter using my 3rd degree follows, the relay could instead of building giant DB queries with it, filter results by that list or compress the list into a probabilistic filter using a tiny fraction of the original space to apply that logic of post filtering.

The requester should be charged for any such kind of heavy lifting.

原始 JSON

{
  "kind": 1,
  "id": "832e74890220f8386086fcf0ab0fecc5dfc3b23ca42542603cc3c95920eb803b",
  "pubkey": "46fcbe3065eaf1ae7811465924e48923363ff3f526bd6f73d7c184b16bd8ce4d",
  "created_at": 1771703965,
  "tags": [
    [
      "e",
      "bbb18519803ac7084915c3dcb3e8cc507664ca1d3633d09147ff3b8599fa19ad",
      "wss://relay.damus.io/",
      "root",
      "46fcbe3065eaf1ae7811465924e48923363ff3f526bd6f73d7c184b16bd8ce4d"
    ],
    [
      "e",
      "c839273123ee0a6367cd3b2b7721fdc71e7535661d7193aa3c6e5c684b4b61dc",
      "wss://relay.damus.io/",
      "reply",
      "ee11a5dff40c19a555f41fe42b48f00e618c91225622ae37b6c2bb67b76c4e49"
    ],
    [
      "p",
      "3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d"
    ],
    [
      "p",
      "ee11a5dff40c19a555f41fe42b48f00e618c91225622ae37b6c2bb67b76c4e49"
    ],
    [
      "client",
      "jumble"
    ]
  ],
  "content": "\u003e Asking relays to compute WoT so you don't have to upload long lists of pubkeys has performance consequences and I'm not sure if it is better or worse.\n\nThe relay could\n\n* cache lists\n* work with lists from events for direct follows\n* explicitly take a follows-degree argument to do the heavy lifting for the client\n\nI find most important that these views on nostr are pubkey dependent and not relay dependent.\nIf I provide a giant filter using my 3rd degree follows, the relay could instead of building giant DB queries with it, filter results by that list or compress the list into a probabilistic filter using a tiny fraction of the original space to apply that logic of post filtering.\n\nThe requester should be charged for any such kind of heavy lifting.",
  "sig": "2f36da13d8db64542cd60aabd8d3b4468d51222f8506a371fe928889f7e0b5cf3b22bd8108039099f6beb825259ca94b5a14cff92538c3c0483eac32ebce7dc1"
}