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?
Thread
Login to reply
Replies (16)
I like @fiatjaf 's take. Let's focus on more usability so we can onboard users with an experience that rivals twatter. Gizmos later.
Great discussions down there 👇
View quoted note →
Terrible idea. What about splitting Amethyst into multiple apps instead?
Code is open. Anyone can fork it and create all those versions. I like one client that does it all.
To me, kind:1 should always be uneditable. It's the whole point. Adding more editing functionality feels like bloat. It makes sense for a blog post, but not for a tiny post.
Yes. Implement editing feature with option to the edit history be visible or hidden (deleted)
Hard no.
I think unnecessary. I like that things cant be edited here, makes it more authentic.
🤙
what about edits that have a history? ie you keep the original note and all edits
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 @fiatjaf
View quoted note →
Se la nuova nota evidenzia ciò che è stato editato sarebbe interessante.
Anche se in realtà habla.news è già ottimo per questo.
Sennò personalmente preferisco l'immutabilità tipo blockchain.
Siamo già liberi di scrivere quello che vogliamo, almeno che ci sia un po' di responsabilità in ciò che scriviamo.
Just thinking:
Maybe a reply to one's own post could be considered as "update" and the clients can then handle this (either per default show the latest update, show full history, etc.
I'm late at the party. I agree with the position of @fiatjaf, @ hodlbod, @semisol, @npub1qqqq...n47m and many others: no new kind for kind-1 edits.
However I like the patch idea, for small edits/addendum. It could be implemented as a simple kind-1 reply with a special tag. This way it would be always visible in the same thread; clients can choose to use it to overwrite the parent and let the user inspecting the history. In this case they should also manage (merge?) replies and reactions.
But to make it usable on every client the patch format should be really simple and understandable in plain text, something like like a quote (>) paradigm. This would also permit to use the edit manually on clients that formerly doesn't support it.
Examples of edit and append:
~the bat is on the table
the cat is on the table
+PS: the original source is xxxxx
I love that my notes are forever just like a #blockchain even with all the typos coming from my new spellchecker-less #android keyboard. It is certainly a good thing for documenting this wild ride into the new frontier of social media and for accountability's sake if we want to be better than X.
View quoted note →
replacing kind1 notes is a bad idea