Damus
balas · 2w
but it technically is a fork no? because if the original nsite gets updated, the copy won't or does it?
sandwich profile picture
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.
2❤️1
balas · 2w
yeah, which leads me to some problems on how nsites require a pubkey as the domain, because in this case, users can only have one nsite that maps to their pubkey, other nsites they copy would have to use random keys that won't inherit the benefits of this flow as the key is not the one you actually ...
Flowey · 2w
So in the future we might be able to reject updates made on the original website, something similar to an app where the user isn't obligated to update the app? So in the future we might be able to reject updates made on the original website, something similar to an app where the user isn't obligated...