nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj your auth system is a bit broken, i have seen it fail to auth a lot in recent times
I will add additional notices, but it may be due to clock desync.
You want minimum overhead? Iād recommend building a stripped down Linux image. The kernel is pretty minimal
well, you would need to reimplement everything from NVMe/AHCI drivers to memory allocation to a filesystem yourself.
But why? Why do this?
I remain squarely in the āNo Editā camp.
I prefer the authenticity of un-edited notes. Thereās something raw about them, especially in contrast to the manicured, artificial feel of most social* media nowadays (which means we should probably expect Gen-Z users to prefer No Edit, as well).
For one, typos are not that big of a deal, at least in the microblogging context. If anything, theyāre endearing. And I hadnāt even considered the attack risk that Derek is pointing out, before today.
Furthermore, retracting a bad take with honest accountability is a lot more meaningful than editing or hiding something you wish you hadnāt said.
I donāt imagine a āmaximum number of editsā would really gain traction, either. Who picks the number? Do we increase the blocksize (er, I mean, edit count) when more users join the network?
It just feels antithetical to the āfreedom and user choiceā ethos of Nostr.
*Outside of social media, itās possible that other event types, such as long-form notes, or events used for things like healthcare in nostr:npub1hqaz3dlyuhfqhktqchawke39l92jj9nt30dsgh2zvd9z7dv3j3gqpkt56s's NosFabrica, could benefit more from editability.
But even then, there would be issues. One strength of Nostr is that (unlike Bitcoin) we donāt require universal consensus: different relays hold different content, and thatās okay. Itās okay primarily because we know that ā1 nost = 1 nostā. This flexibility makes nostr more dynamic and scalable, but it depends in part on No Edits.
Edits would not be universally implemented, so what happens when some clients and some relays implement edits? How does a user verify that a specific signed event is actually the right version? How do relays stay up-to-date, especially if some relays are No Edit on principle and insist on storing and serving the original (or all versions) of a note?
For the more āformalā use cases, perhaps implementing multiple versions of a note could work, where a new (āeditedā) note is signed with a reference to a previous version. This would be backward-compatible with clients or users who consider themselves āedit disrespectorsā (ha).
If some clients do choose to honor edits, they should give their users the option to ignore the feature, and simply display a so-called āedited noteā as a second, separate event with a reference to the original note.**
Because thatās the reality of what transpired, and truth is good. Itās like nostr:npub1rqe7upz9nl4jef9wdyx47vfxnt2g3357tl5s8fpt2vkxwlz2s9cq9w3jdt said: no edits in life.
**Having not reviewed the edit NIP (and I assume there is at least one), itās possible that this is exactly how itās intended to be implemented. But even so, it seems clear to me that the drawbacks of editing easily outweigh the benefits.
No Edits also incentivizes us to write a little more carefully, a little more thoughtfully ā a habit that is woefully lacking in traditional social media.
To me, itās an easy choice. I love the authenticity of unedited notes.
Iām grateful that the nostr:npub18m76awca3y37hkvuneavuw6pjj4525fw90necxmadrvjg0sdy6qsngq955 team has (at least historically) viewed edits this way, as well. Iāll continue to vote with my time, attention, and sats, through my choice of client, and by requesting every version of everyoneās notes from every relay.
All of that said, I would appreciate the opportunity to read a well-laid-out argument in favor of implementing edits. I believe in what Iāve written, but it doesnāt mean Iām right. (āStrong opinions, loosely heldā). I could be missing some key technical aspects of Nostr that would satisfy the objections I raised, and Iām here to learn whenever I can.
I want Nostr to win (whatever that means), so Iām a fan of nearly any good-faith efforts to #grownostr š«” nostr:note1e4xlux4r4gda2sq50yn5tm8gl2xpq4906xtud72yeuw74c542ggs0xmfpf
Also, how do you enforce edit counts or timestamping when this is not centralized?
depends. if they are implementing the protocol how they say they are, VPNs only add a marginal improvement
While ārelay feedsā have no fucking ordering context, require trying to somehow decipher the clientās intent from unlabeled REQs, and require you to host a publicly accessible server to even be able to share it,
DVMs are half-baked in terms of design and it being made by the same people that make other shit ideas like attaching money to a key everyone puts into every client should tell a lot nostr:note1qqqtmzann6vlrty8rmm4sdutt6mt2ezx8hqa902hvj0x8qx5qdtqvvw5qv
hallucinations cannot be prevented with diminishing returns as training time and model size increases until the entire model is bigger than the amount of information in the training dataset nostr:note17qjdza4uweh3vzljpdc6dll035q8jc3976zk8w7x5jnvkau5ekyqpzg0ny
Except when it doesnāt match my political beliefs š if then, it should be removed to āmake NIPs apoliticalā
And standards are meant to be apolitical, and avoid fragmentation. If people want this, then let them have it.
No one is forcing you to implement or use it :) nostr:note1f74fwgluan8jdwhz5xlh49qv4edx8wztcggrzjv4026c5nk208qqsl7n4k
Better but categories?
yes.
categories -> dropdown is better, with a few pinned quick access presets