our users talk to their users tho
and this makes friction in a way that highlights what a dark pattern the threads are
Discussion
I'm not going to design something, just to irritate someone else. I am going to build precisely what I want and nothing more or less.
if you simply remove the root tag, but keep ONLY the direct mention of the replied to event, and the replied to event, you don't close the door to the other users on other clients.
but it ends hellthreads for our users, at the same time, and by rendering the reply-only e reference as a quote
it's simplifying the thing, achieves the same visual result, uses less data, and creates an incentive for users to move to the better client.
this is strategy. it's also simpler to implement, doesn't require using nevent entities, it will still appear as a reply to the other clients who will get the notification, and see what it relates to
it's an exploit of their pattern that works against them.
people WILL like it better, and it's a simpler solution than just only allowing quoting. it just removes the head of the double linked list
anyway, you just gave me the idea is all.
in a few days i start learning how to build nostr front end stuff and this means i have a new project in my mind. ultra simplified, even simpler than jumble.
You are forgetting that it is kind 24, so clients have to purposefully implement it, for it to appear.
haha, you know how i feel about kinds.
special, retarded tags for commie bureaucrats of the nostr authority
it might be normalized for you but it will never be normalized for me.
data structure theory has been probably my second great love after low level GUI and input/network interfaces, and third love was the application of that in creating interactive systems
and i'm not participating in the nip circus. i will design my kind 1 events to interop reasonably with other clients where there is a reason to, but disregard the bad parts of the design.
i want to get in their face, as well as win allegiances to others who have been stepped on by them
also, i'm not doing the typical boy thing of trying to help the girl.
you just inspired me, so the relation here is muse and poet.
Mleku, we're dev friends. You don't need an excuse, to talk with me about our pet hobby.
I just disagree. I see a point of the kind number, but also the m/M tags (the AI automatically understands the purpose of the sample events, when they're in the json, for example).
Kind includes use case information and you'd have to find some way to sub for that, but it is best-defined with a key, so that it can be independently and asyncronously defined without a central authority.
see, that's my point
a kind number needs a registry more than a descriptive tag name. a P tag would be perfect to signify protocol. you don't need permission to put "P":"stella's awesome protocol" and nobody is gonna fight with you about that (i'm just being silly regarding the actual name but the point holds).
kind numbers are supposed to signify protocols so when you look at what people have designed, there is protocols with multiple tags and protocols with single, ever increasing varieties of tags. the semantics of tags and kinds are clearly intertwined. kinds are just a kind of tag, IMO.
it has lost its meaning because nobody defined one. it is indexed, it can be filtered the same way as a single letter tag, and its semantics are absolutely intolerably ambiguous, and not human readable.
dealing with making a reasonable index of them in my codebase was one of the most tedious tasks of the whole thing, second only to debugging.