this is a typical example of an aspiring, well meaning developer (ok maybe she is only working on docs and specs) but how the bloat impulse is a really really severe discipline problem and doubly hard to solve for a decentralised project

no, we don't need to add a new NIP just to cover more kinds of labels

no, actually, most of the nips probably belong as changes to others

please, can we think about NIP consolidation at this point?

like, can we make the tags field optional and move it into labels? what are tags but labels?

logical decomposition of architecture drastically improves the speed of development, let's fuckin go!

nostr:nevent1qvzqqqqqqypzphtxf40yq9jr82xdd8cqtts5szqyx5tcndvaukhsvfmduetr85ceqy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qpqlpcu3j4zshmw0wc2f3s6mgrjfqsq4zzc7wcrxg5wjjgdhwk5exdqg264yx

Reply to this note

Please Login to reply.

Discussion

I just posted that I reviewed it and it doesn't need a new NIP.

And I'm not only working on docs and specs. Ouch.

what else then?

i'm not meaning this to dismiss you i'm just not your manager!

you write so much so it seems like you are a docs person so idk, just a surmise, idk what kind of code you can write, enlighten me

Python CLI and OpenAPI, at the moment, but they're coming out after the SDK 1.0.0.

nice, so, really, python and swagger!

oh they used to call it swagger but now that's not cool and it's called openapi

heh... so you design apis, and you have an adequate understanding of algorithmic logic

you understate yourself, that's the two main things you need to know to be a programmer

I'm not really a core developer. Like, I'm not programming the relay management methods, or whatever.

Swagger is an implementation of the OpenAPI spec.

was the other way around once

I haven't been using it that long. I haven't worked this closely to the client, before. More test automation and devops stuff, or DBM.

I write docs, too. I do everything.

And I'm just a girl and we like to chat.

We're working on a C++ SDK, among other things.

Agree.

At any rate, isn't a label a particular type of tag structure? With a defined namespace?

And a highlight is an event that refers to another event or a URI. It uses a tag, but that's not the point of the NIP. The point is the specified selection.

The problem is less consolidation than a lack of process architecture. There could be a tag, with labels and highlights beneath it. A level down.

yes, nip-32 is literally a kind of tag structure beyond the tags

you wouldn't need the event tags field if you just used labels instead

instead of publishing an event with tags you would publish the event and then the label for the tags tied to the event

it's simpler, and the whole history of protocols shows that this is the right approach and eventually complicated shit like events with tags gets overwritten by a simplified event without tags and a separate label

Well, that would be a breaking change to NIP-01 and NIP-10, tho, among many others. Almost a Nostr v2.0.

But I don't understand the topic enough, to know if that would be an improvement, or not. Would have the benefit of never having to change the core event structure. Just have different label configs.