I don’t know the specifics that make IPFS slow, but I’m skep...

Technical Debt

npub14w4qnk43lsllls2qnldj3vfcxtx5qvtsf3xlvxv9yha8afrxhmfqju3rwx

hex

097d6d8ea0880a9e463f63f3a694cee20555b5d43a134c7bf152264096be985e

nevent

nevent1qqsqjltd36sgsz57gclk8uaxjn8wyp24kh2r5y6v00c4yfjqj6lfshsprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgs2h2sfm2clc0llc9qflkegkyur9n2qx9cycn0krxzjt7n753nta5s8yh8l6

Kind-1 (TextNote)

2026-04-20T21:32:50Z

↳ 回复 weev (npub1weev88wc43slz6jjlq2h30ltmd0ccu9utfe8wet2kkax0w6epavqw409xg)

> but discoverability of “unpopular” content is slower Sure, but a social pinning model and IPFS peer graph makes this irrelevant. We’re not talking ...

I don’t know the specifics that make IPFS slow, but I’m skeptical it’s something that could be fixed easily without some sort of hairy drawback (otherwise it would’ve been fixed upstream already). Your proposed solution would help offload blossom servers but not propagating notes themselves.

I don’t think it’s fair to say “this is just a side channel” to deflect issues because it opens a terrible precedent, why should a dev support the “bad” transport instead of just supporting the canonical one?

Don’t get me wrong, if you look at my past notes you will know I’ve been tooting the P2P horn, the problems with tying features to specific relays etc. but I also appreciate the pragmatic approach nostr devs have taken to get something off the ground.

My point is, I think we should learn from past experiences (also see Zeronet) so we don’t repeat the same mistakes.

原始 JSON

{
  "kind": 1,
  "id": "097d6d8ea0880a9e463f63f3a694cee20555b5d43a134c7bf152264096be985e",
  "pubkey": "abaa09dab1fc3fffc1409fdb28b13832cd4031704c4df6198525fa7ea466bed2",
  "created_at": 1776720770,
  "tags": [
    [
      "e",
      "ace6846e172101ee88ee9ce48880539e77923bddb1ff7e0b0fc2376290a5ca98",
      "",
      "root"
    ],
    [
      "e",
      "701643bcecc3c720388564c43963f283885ca10ec7b9cd1e5bc2fe8875a16752",
      "wss://relay.damus.io",
      "reply",
      "7672c39dd8ac61f16a52f81578bfebdb5f8c70bc5a7277656ab5ba67bb590f58"
    ],
    [
      "p",
      "23d12ef8751e5ee267fb6341d7c41b9434a1b99869e0212eb34d56abb6b12e8a"
    ],
    [
      "p",
      "7672c39dd8ac61f16a52f81578bfebdb5f8c70bc5a7277656ab5ba67bb590f58"
    ],
    [
      "p",
      "930ccef12372dd2f16057cfc54f0dbd94335d8b51b4e2737236b00cab718fcd9"
    ]
  ],
  "content": "I don’t know the specifics that make IPFS slow, but I’m skeptical it’s something that could be fixed easily without some sort of hairy drawback (otherwise it would’ve been fixed upstream already). \nYour proposed solution would help offload blossom servers but not propagating notes themselves. \n\nI don’t think it’s fair to say “this is just a side channel” to deflect issues because it opens a terrible precedent, why should a dev support the “bad” transport instead of just supporting the canonical one?\n\nDon’t get me wrong, if you look at my past notes you will know I’ve been tooting the P2P horn, the problems with tying features to specific relays etc. but I also appreciate the pragmatic approach nostr devs have taken to get something off the ground.\n\nMy point is, I think we should learn from past experiences (also see Zeronet) so we don’t repeat the same mistakes.",
  "sig": "e72c7267e08f7fc087cba085aa02a2fbbce052c57d6aa774560bbcc513017e1f4201b672fba211131a0a57c5b6fdaa23390754e7d01567a07578c850b761884e"
}