its a bottomless pit of scope. i sometimes secondguess everything and am like, is just one relay enough? but look at haven even they couldnt get DMs to live alongside regular relay... anywayyyy lol.
still, it's almost neverending. oh and now u need an nwc relay too.. 😎
yeah, i'm implementing a complete NWC client library and simple CLI too to make sure it's all working rn. then i'm making a subscription manager, all the configs, the special events it will use to store the configs, and the "only visible to you" privilege check so it can message you without the user needing a client that groks DMs - not that any of them do anyway.
it seems every kind# requires a separate set of rules, so breaking it down by endpoint (in my case by relay) is the only way to make it work in a generic for UI type way. but that may not matter if the UI is the code editor.
i don't believe in kinds, also. i think that they are a redundant, unclear and ambiguous, and arbitrary special tag.
almost none of the letters available for indexable tags are in use, either, there's a wide open field that nobody is treading.
i'm gonna show them how it's done.
the client will be the dumb part in my conception of nostr. clients should always be dumb, because most client devs are dumb and feature creep is extreme with dumb devs. i mean, aspirational, ok, i will grant that but i know from my dealings with jetbrains IDEs that the more features they add, the less of them actually work
focus on making the essential things work, and never drop that ball.
and two more clients have nip17 now and both are saying problems with auth.nostr1.com. i literally have troubleshooted every nip17 client that exists, but i kinda have to draw the line now, i literally was only running it for testing tho, but not of clients. i swear it works damnit!!
this meme of "an app for everything" is retarded. narrow the scope. what do users need? kind 1 feeds, relay based and follow based. direct messages.
the "only visible to you" message filter on the relay side will enable me to probably do a fork to #jumble that the DMs have a tag signifying they are a kind one DM and then create a new view in jumble that only shows those, grouped by the OP author/mentioned for simple group chats as well.
this will work anyway, in users of other clients kind 1 feeds, transparently, it just won't be as neat if they don't filter. i might use hashtag filter in fact, then, as many clients have hashtag searches and filters you can make a filter for DMs and voila, simple DMs that just work™️
uncomplicated, and routing around the DM privacy braindamage of the nostr rockstar devs retardation
