Oddbean new post about | logout
 This is all I can do at this point:

nostr:naddr1qqyxzepcx3jnxc3nqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823ckhuthw 
 Good #Nostrday 🤙 
 What, post a link to a client that doesn’t load? 

https://m.primal.net/Lvlq.png 
 Don't use primal. 
nostr:nevent1qvzqqqqqqypzplfq3m5v3u5r0q9f255fdeyz8nyac6lagssx8zy4wugxjs8ajf7pqyghwumn8ghj7mn0wd68ytnvv9hxgtcpr3mhxue69uhhg6r9vd5hgctyv4kzumn0wd68yvfwvdhk6tcqyz0atz0pf8wqfv0t0uu7zf2yxkv8m360l8r65pq80uzzy3rczxx7yqwgdw4
nostr:nevent1qvzqqqqqqypzp22rfmsktmgpk2rtan7zwu00zuzax5maq5dnsu5g3xxvqr2u3pd7qyt8wumn8ghj7mnfv4kzumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezuamfdejj7qpqfxjzw5dahvpfwt88ypza744k6dxmls28h9e7ucvv9eqg0v57edqs6ftxju 
 What would you suggest on the web? At least in appearances, it is the most polished client. I hate using my phone all the time.  
 Nostrudel with these settings: 
nostr:nevent1qvzqqqqqqypzp22rfmsktmgpk2rtan7zwu00zuzax5maq5dnsu5g3xxvqr2u3pd7qyt8wumn8ghj7mnfv4kzumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezuamfdejj7qpq2wp5qf68u8jyah2g4zw3nhhv4jwu2f4al7rf93ldnkr07nnh56zsqcu42e 
 coracle 
 Telling people not to use one of the most popular nostr clients is not a tenable solution to these issues. Do better. 
 are people really pushing edits to kind 1? why has this conversation suddenly reemerged? 
 Its simply choices by individual devs

https://github.com/nostrability/nostrability/issues/120

https://github.com/nostrability/nostrability/issues/118 
 thanks for the reference.

for the record: terrible idea. 
 why do you think its a bad idea? 
 too long 

didn’t read alldat 
 On Facebook, I see edit scams all the time. Someone makes a post about a missing dog or something, tons of people share it around, and later it gets edited to something trying to sell $10 sunglasses. As ridiculous a technique it may be, it hinges on people's emotions to work. Whether they sell any sunglasses or not is beside the point. Over time, the people sharing those posts become reluctant of what may be legitimate information & the actual missing dog gets no coverage. 

Aside from complexity & centralization risk, there's a lot of moral reasons to avoid it, especially when delete is getting adopted. From a user standpoint, if missing context or a typo is that big of a deal: delete it, repeat it. It's not hard. #forevertypo  
 I support deleting not so much editing. And I don't mind if my note is not really deleted, I just don't want it to appear on my feed. If it's still accessible by alternative means I'm fine. 
 That scam wouldn't work with a short edit window, which is exactly what all decentralized protocols with editing are doing. 
 Is it really so bad?
I was speculating here https://stacker.news/items/756409/r/dtonon?commentId=757681 that they have some AI to check potential abusive edits when the context requires it (great exposure and many responses/reactions already recorded).
Maybe I overestimated these big tech circuses.

Btw, I agree, delete and delayed sending is everything we need. 
 oh wow. I'd never come across that. but wouldn't be surprised.  
 imo, it would be simple enough for clients to do automatic typo corrections, conservatively, anyway

but i hadn't heard of this kind of scam before, and it definitely is an issue, so i'm leaning towards the option of "show newer versions" and always show the original first to users, if you are going to support it at all

fundamentally i don't see why not but the scam potential definitely makes the original more important and less vulnerable to manipulation 
 i mean default to "show original"

fiatjaf is right that it increases the complexity of the protocol, but fundamentally if every edit post or diff update refers to the OP of the thread, a filter that just searches for the op itself and all events that put an "e" tag to that event will find the whole thread in one simple two part filter 
 Showing the original first probably wouldn't go over very well with people legitimately editing typos (or adding missing words 😂) why would  anyone click through edits when the original is hilarious or clear enough to extrapolate the intended meaning?  
 I reread that twice to make sure I had all the words in there 😅 
 haha...

nah, i have an idea though... the edits should appear as a series of sliders, so it shows the original first, and when you slide it, it shows what branches off from it... this way everything stays in context and the "no edits" and the anti-change-after-lots-of-share scam effect is weakened

if people edit, then you just click/swipe left to see the newer versions and it updates the children of that post

also consider the problem that happens when someone mentions a post, and then it gets materially changed like what you talked about... the interface should show the one that is linked, and this could be an after-original update, so if i boost your second version, in my boost post it shows the second version, but if i were to boost the original, it shows the original

retaining the context is really important i think... and allowing viewers to see the old versions is also a good thing, keeps people honest 
 I would use that to tell stories...

Once upon a time (swipe) there was a girl as tiny as a thimble(swipe) 😅 
 i like that a lot... let's get hzrd149 to implement it on nostrudel 
 as in, show whichever version is referred to in a boost/embed/quote, but show the slider arrows and make it a "slider" so on touch interfaces it can be swiped left and right, like one of those stupid time scroller things that are popular for landing pages, and make one setting "show original or show newest" in the settings and respect that in the display when the original is referred to... so if someone wants to see the newest, it shows the newest, but when you swipe, it changes the tree underneath it as well 
 lol it would be neat, but it really sounds like a different feature than an edit at that point, for me  
 it can do both! 
 #forevertypo 😤😂 
 yup, it's just a new dimension for chat threads, that's all

better than some bullcrap about redacting your own bullshit 
 t=y, appreciate the discussion above & below 
 Off-topic: notice how using kind:1 to announce other kinds end up hurting the other event by splitting comments in two places 🧐 
 I don't think it hurts, I think it's interesting to see how people reacted differently and possibly from different clients/contexts. 
 Valid point of view 
 This is actually a reason I don't plan to write articles on Nostr (although I might) and only use my blog instead and share them.

Kind 0 and kind 1 are the only two kinds in the only mandatory NIP: they are Nostr. Everything else is an addition. So I can assume they are supported.

If I write the article, then share it, there will be two places to comment it on Nostr.

(In practice none gives a fuck about my articles and I'm terribly slow at writing them anyways, so it's not like it's much of a difference for me personally). 
 I think reposting (kind 16) the kind 30023 article wouldn't have the said side-effect. Although when reposting,  one can't include additional text like when quoting with kind 1 events.

Not sure about kind 16 reach though. 
 agree 
 hm could maybe define a new tag for replaceable events, that forbids replacement after a certain timestamp? 
 How can you verify that the timestamp is real? 
 ok, yeah good point... 
 Depends on the timeframe, but even then nip03 wont really help because in most 'attacks'/scams it would be easy to prep it in advance 
 The edit window is always just a thing that clients do, see e.g. https://xmpp.org/extensions/xep-0308.html

The whole point is that it's not guaranteed to show the edit everywhere, and that clients can choose what they think is the most reasonable course of action. 
 It just means that the mentioned scam is not a good argument, since this is not happening on other protocols that support edits currently. 
 Sorry, I see what you mean now. The relay would have to reject edit messages that are too late, because the client could be offline and doesn't get a timestamp from the relay, only from the sender. But people don't want smarter relays, so that's out of the question I guess.

Delayed sending on client-side is definitely better than not trying to solve it at all! 
 I see!