I'm proposing this. Just remove the event kind list from the NIP repo and put it in a wiki page and basta.

https://wikifreedia.xyz/nip-event-register

nostr:nevent1qqsd2x8g7k95n64x9f9umj00dv2hwmqmeg5gxwrc3ghswjne7k3tcxqpz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzplfq3m5v3u5r0q9f255fdeyz8nyac6lagssx8zy4wugxjs8ajf7p0e6vtq

Reply to this note

Please Login to reply.

Discussion

LOL they already have other webpages listed as sources. Everyone normal has to squabble and grovel over fucking NIP PRs like a damn serf.

It is nice to be the king.

That just pissed me off, to no end.

And look nostr:npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmleku event kinds don't have to have stupid-ass NIP names, anymore.

Just have to be the right person suggesting it.

Et voilà!

i already made such a list, even has a function to fetch the strings from the kind numbers

ah, speaking of better ways of doing things aside from nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn making changes to the relay chatter that has broken its ability to fetch events from #replicatr - testing only on #nostrudel master branch modified to only talk to one relay, it's working beautifully... i can even blow events at the relay from a fresh database and go to global on nostrudel and the page keeps filling up with more and more events, it's awesome

so aside from making sure the #layer2 event storage is working, i can do fun stuff now like forking all the pieces of the codebase into their own independent sections, like how khatru, eventstore and go-nostr are independent pieces

with the pieces apart i want to start work on writing a full set of documentation on it which i will eventually want to share to wikifredia or at least incorporate it into what has been done like your piece there

i quite like this model of owning your own version, it means that people can compete to make better versions and everyone wins

But that would result in more organic innovation and a lot of people don't want that.

Everything is so commie.

i think that we are in a transition now

there will be much disagreements but the best answer will win because there is no company or person or group who really can stop the bulk of interested people doing what they all think is better

soon we will have several competing implementations of nostr integrated and decentralised hosted git repos too, that's gonna change the picture

i say, FUCK GITHUB FUCK MICROSOFT FUCK REGISTERED CORPORATIONS!

we are gonna show the internet how you do it 😎

#YESTR

cen.com/wp-content/uploads/2022/01/clapping-gif.gif

I like doing it in the Nostr Wiki because that lowers the technical barrier to entry and allows us to really "own" our changes and employ WoT to order/search versions, and stuff.

I'm going to dig up the NIPs I've seen floating around the Wiki already, and use their njump event address as hyperlinks, instead of the GitHub URL.

programmers are terrible at documentation, it is really best if semi-technical folk do this anyway, so i'm excited to hear about this initiative

not saying programmers shouldn't learn how to write tho

I'm also just tired of the commie committee stuff, where I have to go beg people who aren't interesting in a topic and/or aren't informed of the topic and/or have me muted or ignore me, to come evaluate my proposal on a topic. Only the people who give a damn and want to talk should even be in that conversation, but all of those people should have a low barrier to entry to join the conversation or submit a counter-proposal or a new version.

Anything else is just stupid control freak bullshit.

Hey, check it out. Click on the NIP-01 link, to see how it works.

Not all of the links work, yet. I'll put in initial entries where they're missing, tomorrow, as I have to go finish something for school now.

https://wikifreedia.xyz/nip-event-register/dd664d5e4016433a8c

I meant, all of the links work, but I need to copy-paste some of the NIPs from the repo into an initial wiki entry.

Is nostr finally going to be where the NIPs live?

🌎🔫

Reactions all messed up. 😂

Was trying to reply "Always has been."

#YESTR

nostr:npub1m3xdppkd0njmrqe2ma8a6ys39zvgp5k8u22mev8xsnqp4nh80srqhqa5sf could you do me a favor and add your zettelwiki events to the table? Want to see what it looks like when someone else edits it. Or do you have to copy it or...? No idea. 😂

oh sooooo cool that you're doing this

non-hierarchical NIPs was the germ idea that led me to make wikifreedia

https://nips.wiki

my version of nostr now links to this registry

The link doesn't seem to work.

I just changed the DNS record of it; it might take some time to update because DNS sucks so much

it's just a 301 redirect to https://wikifreedia.xyz/nip-event-register 😀

Ah, hey, cool! 👍

Going to add that to my profile, as the link is neater.

🔥🔥🔥

I love it how NIP-56 describes an “1984” event as “reporting” 😂

You mean, you want to split your repo up into a collection of repos, like nostr:npub1s3ht77dq4zqnya8vjun5jp3p44pr794ru36d0ltxu65chljw8xjqd975wz did?

yeah, it's hard to do it when you are building the parts at the same time though... but it's pretty stable now so i can split the pieces, the nostr library is pretty much rock solid now, the relay and the event store need more work

i also want to separate the different event store implementations as well, so there is the badger one, and the abstract two level one with a concrete example form using two badger eventstores behind it, and later i can adapt some of the other stuff...

but i also am not sure the interface is exactly designed right because the network connection and the query logic are not really properly decoupled in the relay, it may be fixable at that level though

Yeah, tricky. We started out with one repo and now we've got like 11 and a complex build process. 😂

But it's so nifty, fr.

yeah, my code, my hosting, my neat short imports 😁

also, i very much want to separate my Go code from the rust and shitcoin stuff that is associated in the monorepo

complex build processes are not in my repertoire, i chafe and chafe and chafe until i have simplified them

i intend to make nostr clients in the future but only after i've redone a GUI DSL i made for gioui.org which i can use to literally deploy one codebase everywhere (ios, android, mac, linux, windows and web) - i have had a couple of short bursts trying to finish that job, the upstream broke my library so much but i will resume that work in the future

one language, all platforms, front and back end, compiles in 5 seconds, that is what i'm talking about, and that it isn't industry standard says that programmers like to doomscroll while they compile and get paid for it

I tried to spark discussion around a “simpler” and more “decentralized” solution a while back .. to solve the same problem of “kind bloat” by clients and relays.

nostr:note1e4xhar74ew32435v5whqgu7np5hx9rlx7yumtya6u9qynasjv4sqc49wdg

One thing I don't completely understand is why every Nostr event kind uses the exact same data structure.

JSON is very flexible, we could simply define additional fields to our hearts' content. Instead, `content` always has to be a string, and the most flexibility we get is to define tags as arrays within arrays.

Array-based tags are stupid, IMO. It's needlessly difficult to parse. All you need is a few common top-level fields (pubkey, sig, kind), and the `kind` field tells the client what other *top-level fields to expect on this JSON blob.

For a JSON-lover's protocol, we're really underutilizing JSON.

YES! Please let’s clarify and fix this. Thought it was only me.

I don't think anyone knows why this is.

JSON is trash, very unfriendly for human editing

the more complex you make the structure the less likely that it will be adequately handled by the majority of clients

you have to be able to form the data into the format that the hash that the signature is on, no matter how rearranged the fields are in the object, adding more fields leads to more chances of code failing to put it in the right order and not getting the matching hash

also did i mention that JSON sucks?

YAML would have been better

But yaml is for humans editing the content of a file manually, and we usually have clients do that.

humans can't practically do the ID or signature but all the rest we could... and an actual human friendly format is easy to make consistent, gofmt does that all day long for me, there is very little elbow room for how it's formatted, only really adding line breaks the rest is fixed, and the line breaks can easily be removed, and line breaks are perfect field separators, because they have no other purpose, unlike brackets and commas and semicolons and colons

having gone through the process of writing parser code for text formats the simple thing of comma separation and not the use of a terminal comma has huge implications not just for the fact you can't cut a line and move it without taking care of the comma positions, in the parsing logic it's an extra comparison and branch to check if it's the last field and omit the comma there

if i were to say what format the structure should take, it would be derived from Go's syntax, which is designed for consistency and easy human editing

Well, I guess there's no reason why a relay couldn't accept yml events. 🤷‍♀️

yes, also the actual ID is not necessary to send out, you just parse it into the fields, arrange in the canonical array format, and then you have the hash, it would be possible to actually remove it from the structure, as it's redundant

it's only sorta purpose might be in quickly getting the ID to reference it in another note

i'm not saying that there is any real need to change any of it, just that it's possible to make it more sleek

Ah, I didn't think about the hash not matching.