Nostr Web Client

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.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

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

Reply to this note

Please Login to reply.

Discussion

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

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.

Laeserin 5mo ago

You are forgetting that it is kind 24, so clients have to purposefully implement it, for it to appear.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

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

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

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.

Laeserin 5mo ago

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.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

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.