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?

Reply to this note

Please Login to reply.

Discussion

yes

But then all we would have is peanut butter...

🤣🤣🤣

Sounds good to me Victor

No. What we mess up only makes us all human.

Replaceable events is not the right way to handle this use case. Instead, people should be able to issue either annotations that get shown alongside the original note, or patches that modify the note so people can see a history. Ruggability is not a feature.

I agree with this !

So you are saying the blog system of 30023 is wrong? Because this one is not any different than that.

Blog content I think is different. It would be nice if it had a history that could be audited, but I think people expect blogs to update their contents more than they expect one-off statements to be modified. One-offs are very granular, they don't have multiple component parts that may need adjustment after the fact. Even so, most blog updates usually take the form of "Update: I was wrong in point 37, @person corrected me."

Not for much longer. Now that Twitter and Threads do provide editable tweets, its only a matter of time to get into everything else.

But yes, ideally we show the history of edits.

So as if you reply to a post with:

Same_npub_says: Wrong**fix.

And the client handles the formatting display as they please on their side?

i agree we should be able to add comments to the note but not modify the original note. you should be able to edit the comment though.

you can look into how wikipedia handles this. they have a very sophisticated system for editing posts i think a lot of people could learn from.

Maybe show that it’s edited and link to the original?

This would work for simple typo fixes. Could even be just kind1s like "s/bitocin/bitcoin". You could issue these manually if your client didn't support a custom UI for editing, and read those manually if your client didn't support magically editing the original post in the UI. Or is this a dumb idea?

Clients would have to self-impose a limit on these though, we can't have giant edits.

Hopefully it remains a niche feature.

I think that would work for typo fixes, prioritized comments (addenda/annotations) would be better for substantial changes.

It’s not “ruggable” if the edit history is there. If you’re saying that a client can choose not to show the edit history, isn’t the same for annotations? (Harder to make a UI around annotations than edit history anyway)

Annotations would be impossible to show as an edit. So either you have the old note, or the old note + context. Editable notes would just get shown unless the client bothers to build an edit history feature, which they probably would not do.

Why would a client show annotations but not edit history? The UI for how to show annotations seems a lot harder to think up and get right. Meanwhile edit history as been done in many non-nostr apps already

Do you think there are places where nostr could significantly benefit from having “diff” kind?

Maybe git or Wikipedia style applications?

Google doc with Suggestions support. :)

Yeah, I think that would be really cool. I second vitor's suggestion.

As far as I know, there is no nip/nip-proposal for this topic. Am I right?

One more reason not to use Amethyst 👎

You can still use it with kind 1s.

You are going to do it whether or not people respond in favor of it or against it, so why not just do it? This thread is a waste of time. You asked “what do you all think” but what you really mean is “please support this because I like the idea.”

False. There are tons of questions I wrote in my profile that we ended up not implementing or implementing a variation of it based on people's feedbacks. This has been happening since January.

Lol ok. This idea is a shitty and unnecessary feature that will further fragment content across Nostr, but that is what you like to do with Amethyst so please by all means continue.

Viewing history of the post changes should be *mandatory*. So, a new NIP standardization is needed IMO.

Please no 🥹

Editing posts is not really that important to have a separate kind for it 🤷

Especially when there's no guarantee that past posts will even be available, why bother

We have been successfully deleting lots of posts since February. :)

respectfully no pls. delete or edit is against the 2nd thermo dynamics, unnecessary and a waste of energy.

relays and an amethyst fork should counter that

i heard you like inconsistency, so im adding more inconsistency to your inconsistent threads. There is no finality and rugging the thread to bork context is just fine..

er..id be opposed to this.

Would you be opposed to using the new kind or opposed to anyone else using it?

i wouldnt use it, and Id want it made abundantly clear in my client if i was dealing with a playground post

I believe that notes should be deletable but not editable.

So, should habla.news dissapear?

Short-form content is typically different from long-form content. It’s quick thoughts or updates, meant for quick reading. I rarely read short content twice; editing them is pointless. If your content has mistakes, just delete it and post a new one.

There is an issue with that. Some clients dont process delete events yet. So, posts get duplicated every time they happen. :(

Introducing a new kind for edits won't fix clients not implementing extant specs

I disagree. I remember when no client showed long-form content. We implemented it blending the new post into the feed and, it took some time, but others followed. Same for custom emojis, etc.

If there is use, it helps people prioritize them. If there is no use, then no one needs to worry about it :)

Only if everyone switches to the new kind, kind 1's are here to stay, and deletions will only get implemented if people care about them (side note, next release will have some deletion support).

That was an antipattern. We can't have a decentralized Nostr if we keep assuming all clients will implement everything.

If there is more stuff to implement that makes it so there are less "complete" clients. Users flock to the more complete clients, they get better and the other clients are left behind. With fewer clients they can agree among themselves to invent more and more features that make it even harder for other clients to compete.

Why do people always assume all clients must implement every new kind? I am not expecting people to implement this one. The feed will just look different in every client, as it SHOULD be. Some will see more, others less, others just a different set of NIPs, etc. There is no such thing as one feed.

"Oh, you didn't see my note? Use Amethyst, the other clients are broken, they are not showing my notes!"

There is never going to be a time where that does not happen. Amethyst or not... everytime I go to a different client a see different things. So, better embrace the chaos.

Remember that next time you want to edit a note: embrace the chaos!

Seriously though. I don't understand this need to display the same stuff everywhere. Clients are different and there is way too many NIPs already. It's fine.

Don't want to display the new editable posts? Not a problem. Maybe somebody will not want to display kind 1s, just replaceables.

your whole premise behind this idea was that not everyone is seeing the same thing (deletions)

you dont understand the need to display the same stuff yet want amethyst to display everything ie the same stuff lol

for me you dont understand what amethyst is good at and are making it worse in many ways

Why is the letter C, missing from your name?

choas n decentralize

For the long-form stuff I think this is fine. People get that these articles are "different". They assume they must go to some dedicated page to read them, so it's not actually causing much harm.

I think it's actually bad UX when one of these articles shows up in the normal microblogging feed.

But if we had just another note kind that showed up in some clients but not in others that would be interpreted as a bug on clients that don't show it.

Send character count as metadata

You can have decentralization and consensus among clients/protocols. It's just matter of time

popular clients will direct changes and dumb changes like this will damage the client and nostr

siloing content in new kinds is antithetical to what makes nostr successful

already we have an unnecessary divide of kind1 and kind42

amethyst is not improving but getting worse now

many are calling for features that are not being done like better filters and views, reddit view for example, antispam filters

How about... the "edit" is just the creation of a new post but bound by the initial post / post's ID?

Ex:

Post-id-1:0

*User edits and posts new edit

Post-id-1:1

And there'd be a "view post edit history" section that shows all of the posts they've edited before the latest one with the highest numeral value (ex: post-id-1:10 is shown, and :9 to :0 is shown in history)

So instead of adjusting data, it's creating new ones, and showcasing the latest one and filing previous ones.

I don’t like it, but I guess it’s one way to attract mainstream journalists and those people who can’t be human and accept their mistakes.

We already have it when we display Long-form content (Blog posts form Habla news). So, it's not really anything new. :)

I am aware. I dislike that equally 😁.

Edits should be patches IMO, not brand new events

Like a Unified Format, type of update?

Exactly

This one's getting a lot of attention.

I still like my idea of making edits a comment kind, then the client can determine how to implement the edit, such as displaying as a normal comment, in its own section, or find-replace with the option to view the original.

What do you have against penis butter?

As an admin of a relay with censorship (though still not public) I am against it 😅 If people start thinking they can edit notes, I will have to censor 10 times more, and I don't want to.

So, you dont accept any events in the ranges of 10,000 to 20,000 and 30,000 to 40,000? Because those are all replaceable.

Only notes are a threat for our regime, because that's the base from which familiarity with Nostr begins.

> base from which familiarity with Nostr begins.

for now... Notes are not the future of Nostr. Believe me, I am a kind 1 author and have an interest in making Kind 1s survive. However, it's very clear to me that this kind 1-main party is not going to last very long. :)

Actually I'm just kidding, but honestly the load on the server will really increase and it's not even clear for what. There are less pros than cons.

Yes kind 1 is dumb and probably won't last long, but still Nostr is at the beginning of the road and it's a bit early to kill kind 1 🤔 Especially since people are mostly used to notes that can't be edited.

why is kind 1 dumb?

practically. It feels like it exists only because of Twitter. Like, "Oh, well, there was something similar on Twitter many years ago, we should have it too.". And now, "Damn, it was a so-so idea. Nobody needs Twitter in 2023"

you can do lots of things with kind1 like chat, reddit, forums

twitter is just one aspect, point is we have this large data set we can share between apps in different ways

i think because of that we will do better than twitter where we switch views, i am interested where we can do chat in a thread but later view it like reddit

why? clients using cross client data like kind1 is the most important part of nostr, already kind42 breaks shit

I'm not up to date on the various note kinds, but I'm mostly:

* NACK: nostr notes don't need editing, period. And it does screw up the context for, potentially, the entire reply / quote ref interactions.

* or meh, even with editing, the original versions should always be available (when possible) in the UI. And / Or always have to assume that some relay somewhere still has the original version around, anyway. Or some clients refuse to show the updated version.

So the worst case scenario can't be resolved (no such thing as truly erasing a mistake) while the more innocuous cases (just a little cleanup) aren't enough of a win to justify the effort / hassle / UI muddle of a somewhat clunky solution that maybe / probably won't get broad adoption anyway.

No, please don't destroy Nostr.

This is a tool for scammers, and politicians will love this feature of you. If historical posts could be edited, Nostr would become a den for scammers. I like the feature of Nostr that posts cannot be deleted, because the posts made by each of us, regardless of joys, sorrows, typos, and emotional opinions, represent our true selves on Nostr.

Blogs are academic essays, while short posts are about life and yourself.

They can already delete the post and rewrite it with the past date. You won't even notice that they changed it. What you are seeing is an illusion. There is nothing blocking politicians and scammers from changing their posts today. This proposal simply creates an easier way while display the last update time for the honest folks out there.

No one will blame you if you fail to stop politicians and liars. But if you prepare tools for politicians and liars to deceive people more easily, you will be denounced by people.

I know this is not your original purpose, it is just a technical discussion. Please don't do evil. This is not the purpose of our coming to Nostr.

Short article posts on Nostr are historical records of our life thoughts. In real life, we will say the wrong things, make mistakes, and have emotional breakdowns, but these are real people, not a perfect academic paper. Or not a politician who is packaged as flawless and perfect.

If your purpose in coming to Nostr is to make better tools for crooks and politicians, rather than building tools of freedom for people who pursue freedom. You can indeed do this.

he wont destroy nostr just amethyst

The alternative to this is to simply delete the kind1 post and rewrite it with a created_at date in the past. It would work today as is, but then most people and clients will not even notice the post has changed.

nostr:nevent1qqsf34sss5vdtytuqtywdg7pmkhwuefc3lw6zcd9854lxahlhlqkdmqpz4mhxue69uhhyetvv9ujumt0wd68ytnsw43qygzxpsj7dqha57pjk5k37gkn6g4nzakewtmqmnwryyhd3jfwlpgxtspsgqqqqqqsqcvjwx

Not sure about it...

Why not post a new kind 1 event with something like a "fix" tag with original event identifier?

However is not something i feel the need to have, so in my opinion the answer is no.

Because it would either duplicate in the feed or show as a reply of the original post all of today's clients.

I think editable posts would be really great.

Hi! Sorry no speak English

Creo que el no tener la opción de editar hace que se piense realmente lo que va decir ,hacer una autocrítica y asumir una alta responsabilidad de lo dicho.. sabiendo que tampoco se puede dar [del] .

Saludos desde Uruguay 🇺🇾

only if the edits and original remain

Do you mean the "edits" would be diffs against the original post? Because if so, none of the history is lost and the client can let the reader see older versions through an interface extension (if the client supports it). A diff format (last update note1xxx + diff) could potentially be backwards compatible with clients that don't support applying the diffs and the timeline could show the old post as edited again as a fresh note (similar to a repost).

Not today. But nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 has been thinking on a way to do that. Today this approach would just use the regular replaceable event kinds where most relays delete past events (up to them to keep it or not)

En discord cuando editas una publicación queda entre paréntesis (editado)

Can’t comment on the technical implementation you’re discussing with others, but from a user perspective an editable note (ideally time bound, 3min? 10min?) is clearly in demand and a nice feature. Like others I’d like to drill down into a history of previous versions. I don’t think the history should truly disappear.

While it might sound useful, I think, starting with myself, many nostriches got used to the immutability of Nostr notes. Edit history is something else as it keeps the record, but even that might not be needed for shorter posts. Unlike blog posts that are better modified in case of typos and content updates.

I believe the convenient feature of ✏️ #editing past posts will serve as another compelling reason for users to switch from Twitter to Nostr

dumb

Why? Don't you like an idea of editing past posts?

orwellian revision history, fixing typos sure but keep all the notes

My initial reaction was sure, why not. Delete is important, and edit is just like deleting + posting + some UX sugar.

But on the other hand much of Nostr’s power is its simplicity. Adding another kind puts a little more burden on new clients. Maybe good enough delete is good enough. Twitter didn’t have edit for a very long time.

The issue with delete is that some clients dont delete yet. So, if their user is only they end up seeing 2 posts. Which I think it is worse than not showing some new kinds yet

Hm, good point. But I think most of the clients that don’t support delete do so for philosophical reasons. So are they more likely to display the kind 300111 maliciously and not respect the edits or to not show it at all? I think in the long run if 300111 gets traction they will just show it without edits and we’ll be back to square one. It’s an assumption though.

17 years?

Is Twitter really that old? Yikes that makes me feel old.

With technology, I always think if a thing can be done, it will be done. If not Amethyst, some client will eventually do it...

Plurality

It will impose huge overhead on all clients and kill Nostr.

Do you consider replaceable events an overhead?

Yes, they are very annoying to deal with, but that is made simpler by the fact that they are not expected to be displayed in realtime in a constantly updating feed that may or may not be cached locally and/or by relays.

Kind 1 notes are easy to deal with in this "live" scenario: they either exist or they don't. All events always have the same id, so it's easy to match and cache and I'm probably forgetting a dozen other arguments that me and others have given in the past against having editable events.

So do you prefer that we just delete the event and send a new one with dates in the past? I initially didn't want to do that because it would create duplicated events in the feed of clients that don't implement deletion yet.

I think that is bad too, accepting the fact that things don't change is probably the best way, but seems much simpler to implement and not very harmful to clients that don't implement it.

Probably the most honest UI, if you want, would be to have a "nuke" button that tries to delete everything, but decouple that action from the act of creating a new note. Let people manually delete and then make a new one.

+1 for decoupling. You can "delete", and then post a new one.

Clients following the delete request can choose how to display it in the UI.

In all other clients, it would be cool if it just looks like a quote tweet of the old note.

==

Benefit of quoting each of the edited versions - you can wee what engagement/comments were there with the specific previous versions of the note.

==

UX-wise, in terms of other users experience (who might have responded/boosted/quoted) your old note - I don't see any clean way how to allow edit without actually NOT hiding the previous versions.

post nsec to kill account

no

Event Twitter has a lot of trouble with editable posts, sometimes you are reading a post and it has a message saying "there is a new version", and then you click on that and it doesn't exist anymore or other shenanigans. I don't know how it's implemented internally, but I imagine it wouldn't be too different than this, except for the fact that they have a single codebase.

In Nostr it would either be unusable chaos or everybody would just resort to using the same client.

Replaceable events suck. Why use them on WikiNostr? Edit history is important.

A delete button would be great.

already

relays wont use it and people will stop using amethyst

Kills and all yours friend.

🕷️

Thieves and corrupt yours fried.

🕷️

Yours friend

🎚️

In and yours friend.

😉

Gagged and yours friend

🪬

After you and yours friend

🌹

License to nostr

🫶

Agree it is good to keep the kind segregated. Makes sense as it will definitely create some noise in the signal. But this will happen one way or the other. The question is what is best. Obviously we want to avoid as many legacy creations as possible. But no one knows the future exactly!

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?

nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6

nostr:nevent1qqsf34sss5vdtytuqtywdg7pmkhwuefc3lw6zcd9854lxahlhlqkdmqpz9mhxue69uhkummnw3ezuamfdejj7q3qgcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqxpqqqqqqzz6gum9

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 nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6, nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn, nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj, nostr:npub1qqqqqqyz0la2jjl752yv8h7wgs3v098mh9nztd4nr6gynaef6uqqt0n47m 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.

nostr:nevent1qqsf34sss5vdtytuqtywdg7pmkhwuefc3lw6zcd9854lxahlhlqkdmqpzemhxue69uhk2er9dchxummnw3ezumrpdejz7q3qgcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqxpqqqqqqzlclejh

replacing kind1 notes is a bad idea