Semantically, yes. Where I take pause is that by virtue of h...

sandwich

npub1uac67zc9er54ln0kl6e4qp2y6ta3enfcg7ywnayshvlw9r5w6ehsqq99rx

hex

9b2131b27926f413dbae1c0d394c34b380597e888451a7475c25066c6c7fa767

nevent

nevent1qqsfkgf3kfujdaqnmwhpcrfefs6t8qze06ygg5d8gawz2pnvd3l6wecprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgswwud0pvzu362lehm0av6sq4zd97cue5uy0z8f7jgtk0hz368dvmcgw90j5

Kind-1 (TextNote)

2026-03-25T12:35:54Z

↳ Reply to balas (npub1nmr6w7qk0ta36vxysv77jv3d5rqghfc6d8sez8240rf3gja4vsmsd2yha8)

but it technically is a fork no? because if the original nsite gets updated, the copy won't or does it?

Semantically, yes. Where I take pause is that by virtue of how this works, you downstream isn't editable, until you upload something entirely new; and then it's completely disjointed. With upstream, we're working out how broadcast optional updates safely.

The thought process behind how this works is really just about leveraging existing blobs and offloading changes to nostr. Once anything changes in the blobs it's just another deployment.

It's an inverted fork maybe?

The high-level ecosystem of how this works is also greatly different. Basically, the blobs keep multiplying until "perfection" where it is no longer necessary to make any changes to the blobs, because any changes required can be done dynamically via nostr.

It's something else IMO.

Raw JSON

{
  "kind": 1,
  "id": "9b2131b27926f413dbae1c0d394c34b380597e888451a7475c25066c6c7fa767",
  "pubkey": "e771af0b05c8e95fcdf6feb3500544d2fb1ccd384788e9f490bb3ee28e8ed66f",
  "created_at": 1774442154,
  "tags": [
    [
      "e",
      "1d39174ec889998b2f5547e56a172422395d1f9c2eebccbb9b79dabeca7f12e8",
      "wss://nos.lol/",
      "root",
      "e771af0b05c8e95fcdf6feb3500544d2fb1ccd384788e9f490bb3ee28e8ed66f"
    ],
    [
      "e",
      "00000abb3622bde6fb1d4d9b5d4f0cd0fc641a9952f6851611bf251374b6370a",
      "wss://nos.lol/",
      "reply",
      "9ec7a778167afb1d30c4833de9322da0c08ba71a69e1911d5578d3144bb56437"
    ],
    [
      "p",
      "fc7085c383ba71745704bdc1c6efcf7fab0197501de598c5e6c537ac0b32a4cb"
    ],
    [
      "p",
      "ed5cfd82e57e0d79fa7888264432d1d7b6dddde361616a2bd32ad8532f526915"
    ],
    [
      "p",
      "9ec7a778167afb1d30c4833de9322da0c08ba71a69e1911d5578d3144bb56437"
    ]
  ],
  "content": "Semantically, yes. Where I take pause is that by virtue of how this works, you downstream isn't editable, until you upload something entirely new; and then it's completely disjointed. With upstream, we're working out how broadcast optional updates safely. \n\nThe thought process behind how this works is really just about leveraging existing blobs and offloading changes to nostr. Once anything changes in the blobs it's just another deployment. \n\nIt's an inverted fork maybe?\n\nThe high-level ecosystem of how this works is also greatly different. Basically, the blobs keep multiplying until \"perfection\" where it is no longer necessary to make any changes to the blobs, because any changes required can be done dynamically via nostr.\n\nIt's something else IMO.",
  "sig": "f590500357977637f9aab83a6a6084838f1422e57f886672c105fc45c965e9e6f967d696955526297b586657c0bdf62bdcc1983d9742e852a0549dd3e3806f70"
}