Maybe instead of thinking about it as a "style" layer it is more helpful to think about it as a "quality" layer. So nostr is the protocol for the object itself, this other layer indicates some kind of quality of the object.
I'm not a developer and I'm not paying close attention to what's happening with the evolution of the nostr protocol, so maybe this already exists or maybe it's nonsense, but my understanding is that there's a danger here to bloating the protocol.
My thought is that, without modifying the underlying nostr protocol, is it possible to build a parallel styling protocol that clients can implement in their own way, or choose not to implement? An analogy would be that this could serve sort of like a CSS layer to nostr's HTML?
The solution in this case for editing could be some kind of "tag" that indicates the user intends the post to be "deprecated" and if the user goes back to the post and assigns the tag, the clients can honor it or not using their own implementation of the style for that tag—for example, greying out the text or adding strikethrough?
The idea being that the style layer can be separate from the data protocol—and optional and customized—and that way not bog down the underlying framework?
This also gives the clients some room to flex differentiation in their interpretation of the style tags?
nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6
Discussion
No replies yet.