Oddbean new post about login | logout I never heard an actual argument about why editing notes is contrary to any ideal. It sounds like an opinion without a reason.
It adds an immense amount of complexity that is better left for more specialized applications and use cases. At least for now, kind1 is the common ground everybody has and it should remain that for the foreseeable future, at the basic level it's super easy to get started, easy to read, easy to write, easy to display. If you start publishing kind1 notes with HTML, Markdown, editing capabilities or kind1 notes that depend on custom interpretation of new tags or requiring fetching or other notes for them to be rendered correctly you're breaking that. nostr:nevent1qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qghwaehxw309ashgmrpwvhxummnw3ezumrpdejz7qg7waehxw309ahx7um5wgkhqatz9emk2mrvdaexgetj9ehx2ap0qythwumn8ghj7un9d3shjtnwdaehgu3wd9hxvme0qydhwumn8ghj7un9d3shjtn0wfskuem9wp5kcmpwv3jhvtcpr4mhxue69uhkummnw3ez6un9d3shjtnhd3m8xtnnwpskxef0qyvhwumn8ghj7un9d3shjtnndehhyapwwdhkx6tpdshszxrhwden5te0wfjkccte9e3h2unjv4h8gtnx095j7qghwaehxw309aex2mrp0yh8qunfd4skctnwv46z7qpqqf4gx2x2gd639jgwqccvgm4p7vlwrfh9t8yej68e2tpa03ay55nq9rygsw
The editing stuff with new events is not bad, but I still don't like it because it breaks everybody that doesn't implement it and puts a high barrier on top of implementing anything that uses kind1. I may be wrong, and I certainly feel like it would be better to get more usage across other kinds and subprotocols other than microblogging, but still I think now is not a good time. If people really want edits, I think we should at least make it cumbersome in the UI so it's clear that it is not really an edit, but actually a gambiarra amending of the original with pieces of glued paper on top.
nostr:nevent1qqsxt67e7g0rc7a3ndkqfrwwctcsut8s37tg0pvwv8v42vpdm6s3tkspz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqqqqy4777t6
@fiatjaf is an attack on #Nostr. Good work @Vitor Pamplona amethyst is amazing 👏 nostr:nevent1qqsxt67e7g0rc7a3ndkqfrwwctcsut8s37tg0pvwv8v42vpdm6s3tkspzpmhxue69uhkummnw3ezumt0d5hsygpm7rrrljungc6q0tuh5hj7ue863q73qlheu4vywtzwhx42a7j9n5psgqqqqqqsf0k20q
Need a version of #Nostr for this meme 🤣 https://nostrcheck.me/media/34651a9392d34bf9d064e39f3c10beef74b5e28e710c07324317b687c4abd7e8/c5ecbc456ab80a62be19f54b2940c02249a9f97cd07c6083b7e75633dc3afba4.webp nostr:nevent1qqsvlaydyvq0z9xmvesg59g6hwajdkn0hrhfcprlzzxzegus6hs9m9qpzdmhxw309akx7cmpd35x7um58g6rsd3eqgsrgeg6jwfdxjle6pjw88euzzlw7a94u288zrq8xfp30d58cj4a06qrqsqqqqqp9xyqef
So, go back to my original proposal to have a separate kind that can be edited that everybody hated back then?
That's also bad.
So, don't do this, don't do that. What can I do? Either way, Edits are happening.
Some would implement that kind, others wouldn't. That's not normally a bad thing. It's part of how Nostr is meant to work. But it's bad in this case because those events would serve the same purpose as kind1 events most of the time, for most users, in most circumstances.
> At least for now, kind1 is the common ground everybody has and it should remain that for the foreseeable future, at the basic level it's super easy to get started, easy to read, easy to write, easy to display. I think it should remain the case *forever*. Other protocols will work differently, but Nostr should remain (uneditable) kind1-focused, in my view. I also have my objections to edits on Nostr. nostr:nevent1qvzqqqqqqypzprhy9yxf3vst9xv38zej9arxagsvw4sg7452k570z9yjh7djapyuqy88wumn8ghj7mn0wvhxcmmv9uq3qamnwvaz7tmwdaehgu3wd4hk6tcqyqu72u49vh94kfq6elfp50sq4prnxng42qxe7q3lhy7r89vhy65cx273rt5
Your arguments are much better. I henceforth adopt them as mine.
I dont know how its implemented or why it adds complexity to the relays, but the very concept of editing or deleting notes shouldn't be contrary to the ideals of uncensorable communication
Nostr is was never about building the "ideal", it was about building a thing that works well enough.
In the sense of "ideals of uncensorable" I didn't mean the implementation needs to be ideal, only that uncensorability is the ideal to strive for.
My point was exactly that trying to get an "ideal" in this case would sacrifice other important values of Nostr, one of them being the practicality. So no, we shouldn't be always "striving for ideals". The ideal social network would be a pure p2p thing with no IPs, no DNS.
Those are implementatiom details. What is the requirement you intend to fulfill with "no IPs and no DNS"?
The DNS system is centralized and prone to censorship. You *can* add other DNS roots, but it doesn't really solve the problem. I suppose systems like Namecoin or ENS might address the problem, if they get traction. Many on Nostr would have a problem with them because they are based on blockchains other than Bitcoin. Personally I have no issue with that, although I don't know what secondary problems they would create. The IP address space is also controlled and censored.
Decentralization > uncensorability? I doubt this is your stand. Nostr is built on IP. Lets suppose they can censor IP and DNS. From what I see, nostr already addresses this risk with its architecture. Again, you jump to solutions but haven't amswered my question. What is the underlying problem that nostr needs to solve? What are the requirements to that solution? Is it to solve the problem that people want to edit their own posts, is it to optimize relay bandwidth or is it to be a decentralized protocol? I doubt it is any of these. I see nostr's primary aim is to enable uncensorable communication with a minimalistic protocol design. Tell me why I'm wrong.
> Lets suppose they can censor IP and DNS. From what I see, nostr already addresses this risk with its architecture. Nostr addresses censorship by relays themselves. But if all involved organizations wanted it, and it's a closed market, they could censor all DNS names and IP addresses used by Nostr relays. Obviously this is hard and unlikely, which is why Nostr does provide (some level of) censorship resistance. > What is the underlying problem that nostr needs to solve? What are the requirements to that solution? From my understanding it's corporate censorship and it mostly does solve that. > I see nostr's primary aim is to enable uncensorable communication with a minimalistic protocol design. I agree. I never suggested allowing edits is against the purpose of Nostr.
>They could censor all DNS and IP addresses that relays use Even over tor ? The simplicity of the protocol is its strength. The JSON can be sent over radio in morse code.
> Even over tor ? If you use Tor to access a clearnet domain, the domain owner is the same as if you access it trough clearnet. If you are referring to .onion domains for hidden services, then obviously that's outside of the scope of the centralized DNS system and does not have these problems.
agreed. keep things simple and embrace typos.
Edits are bad because they break NIP-01, they leads to inconsistencies, they lead to more complexity (and less efficiency) and a few other reasons. nostr:nevent1qvzqqqqqqypzprhy9yxf3vst9xv38zej9arxagsvw4sg7452k570z9yjh7djapyuqy88wumn8ghj7mn0wvhxcmmv9uq3qamnwvaz7tmwdaehgu3wd4hk6tcqyqu72u49vh94kfq6elfp50sq4prnxng42qxe7q3lhy7r89vhy65cx273rt5
My user experience with unmodifiable and undeletable notes makes nostr close to unusable. When I post a note with mistakes that make it illegible, i'm faced with either replying to my own note with corrections, or posting a new note. This makes the recipient's experience degraded, and forces both parties into an idealology they have no connection to. The object to nostr isnt to make it some kind of pure programer's panacea, but to enable uncensorable communication while balancing ease of implementation to encourage adoption with enabling expansion of scope within the new communication protocol's M:N paradigm. Regarding lack of consistency of relays and potential forking of versions, this is something that exisis already with any replaceable events such as the profile information, but for notes it can easily be resolved on the client side by comparing revision data.
> When I post a note with mistakes that make it illegible, i'm faced with either replying to my own note with corrections, or posting a new note. Replying to your own note is the right path. > This makes the recipient's experience degraded, and forces both parties into an idealology they have no connection to. What's the ideology in question? @Laeserin did make some ideological points against edits, but none of the points I made are ideological. In fact, they are mostly technical concerns. > this is something that exisis already with any replaceable events such as the profile information Yes, this is true and it's possible to see different info for the same account depending on what relays one uses. Therefore, one shouldn't trust account info to be consistent. Accounts info are metadata. One doesn't generally reply to an account description or reference it. Consistency is less of a concern, but modifications are arguably more important because it doesn't simply represent a statement made at some point in time. Also, one doesn't generally identify (and verify) account info by an hash, but, rather, by the user ID, so account info wouldn't be necessarily consistent even if modifications were not allowed. > but for notes it can easily be resolved on the client side by comparing revision data. That means having to pull more data from relays, instead of stopping at the first answer which one can verify given the ID.
