PacStandardTW on Nostr: I'm not a developer and I'm not paying close attention to what's happening with the ...
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?
Vitor Pamplona (npub1gcx…nj5z) fiatjaf (npub180c…h6w6) I am considering enabling Amethyst to write a replaceable kind 1 (new kind:30111) to allow users to edit their past posts at will.
It would work in a similar way Habla News works, but using Kind 1's style of small posts instead of markdown and long-form content of kind:30023.
Of course, we could also write kind:30023 (blog posts) directly, but it would pollute most of the Blogging interfaces with short posts.
What do you all think?
Published at
2023-09-22 04:41:05Event JSON
{
"id": "8ec56e572cd317507a2e7ff35ed75a8da1035b324ddacaa80ba949a67fb94188",
"pubkey": "ae8e1ab9c597abbc3f69d7b5bbc50da5ec5c23b07883553f523affa2dcbb4b31",
"created_at": 1695350465,
"kind": 1,
"tags": [
[
"e",
"98d6108518d5917c02c8e6a3c1ddaeee65388fdda161a53d2bf376ffbfc166ec",
"",
"mention"
],
[
"p",
"460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c",
"",
"mention"
],
[
"p",
"3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d",
"",
"mention"
]
],
"content": "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. \n\nMy 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? \n\nThe 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? \n\nThe 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? \n\nThis also gives the clients some room to flex differentiation in their interpretation of the style tags?\n\nnostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6\n\nnostr:nevent1qqsf34sss5vdtytuqtywdg7pmkhwuefc3lw6zcd9854lxahlhlqkdmqpz9mhxue69uhkummnw3ezuamfdejj7q3qgcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqxpqqqqqqzz6gum9",
"sig": "4e40bb9938e44c8ad2687abc45809177a5f79ea700b5159622d9ea41b97a64f14f40694c4a50cbdb00b67f71b45012050e8edf2d070541e15bd347f39f08b671"
}
