nostr:npub1m4ny6hjqzepn4rxknuq94c2gpqzr29ufkkw7ttcxyak7v43n6vvsajc2jl are you guys going through with that horrible encoding for 30040? please please please, can you guys switch to tags? decoding json twice is so horrible it hurts my feelings

Reply to this note

Please Login to reply.

Discussion

At the moment, we have the "d" tag for the title and a longer title and author in the content. I just copied your Highlighter format. 🤷‍♀️

Thought the spec was updated on wikifreedia, if not I will do so tonight. For 30040: Keep content empty and use the d tag for titles. Anything else is optional, and should be done through best practices.

It was updated last week.

Thank you. 💜

d tags for human-readable title are not a good idea as you can't change it

I use it as a nicer-to-have URL, because then you can do domain//d-tag, but, since you can't change the d tag it's better to keep a title tag with the human-readable/editable value

I think 30040s should follow NIP-23's format as closely as possible to avoid having a bunch of differently-named tags that mean the same thing

"title", for the article title

"image", for a URL pointing to an image to be shown along with the title

"summary", for the article summary

"published_at", for the timestamp in unix seconds (stringified) of the first time the article was published

🤔

What about the author?

If "author" is in tags use that, otherwise use the petname of posting npub?

We currently have no "author" or "title" tag in 30040. Only "title" in 30041.

Yeah. To make it symmetrical with 30041 and 30023 we can use the title tag in 30040. Author is optional because by default we can assume the author is the npub. If the author is noted in the tags, then its a signal that the content isn't original to the author.

Are tags mandatory and that's why you want it in the content?

i was trying to base it off of the metadata+content relationship as depicted kind0 and kind1 for users. Being nip01 it seemed like best practice.

The other part is trying to isolate the list aspect of kind 30040 from the metadata.

Yeah, this is a fundamental decision. Let's wait for the PO to respond.

I am leaning towards moving the title and author information into the tags.

However, as I've been thinking through the problem, another question popped up: How is the order in which "child" events are to be displayed encoded? Is it implicit in the tag order?

Maybe the content field would be better used to provide some sort of display hint so that clients are more likely to display the indexed content in the correct order.

Yes, tags are represented by an array, and arrays are ordered by nature, but a bunch of other event metadata may be contained in tags that isn't immediately relevant to the indexed article contents.

Everybody regrets that kind 0 has embedded content like that and we are trying to move away from that horrible structure, but ok…

I am not aware of any such discussion.

yeah, complex and inflexible unlike embedding escaped JSON in the content and tag fields

i dunno about the content in zaps though, i had a big problem handling that at first because i didn't realise it could have anything other than ... well, like, URL text, but yes, zaps have JSON inside them

We're just going by what we see in the specs. We are not privvy to any discussions going on wherever. Most devs aren't. 🤷‍♀️

it is a very opaque thing, you have to be a rockstar to have the inside scoop it seems

I keep being told "everybody knows this" "everybody is discussing this".

Is this "everybody" in the room with us, today?

I know of no such discussions and I'm starting to get irritated at the assumption that I'm supposed to know what other people are talking about wherever.

It’s being discussed informally here in nostr on kind:1s, not structured or formalized or in some secret group or relay; it’s like “we’ve been talking about covenants on bitcoin for years”, not that there was some explicit invite-only meeting; just a popular topic that keeps coming up over the last years.

We haven't been here for years and we haven't been part of those discussions. If you want to change the NIP-01 spec, let's go ahead and change it. Someone arriving later shouldn't have to guess where something is headed. You're expecting us to fork off a spec that doesn't yet exist.

Liminal was assuming that NIP-01 contained the expected standard and tried to fit his stuff to that, which was very reasonable.

We can submit a PR for NIP-01, as well.

Isn't original to the npub*

"d tags for human-readable title are not a good idea as you can't change it"

Since we're dealing with parameterized replaceable events, isn't that a moot point? If you need to change the human-readable title, just replace the event and give a new set of tags.

https://wikifreedia.xyz/nkbip-01/npub1m4ny6hjqzepn4rxknuq94c2gpqzr29ufkkw7ttcxyak7v43n6vvsajc2jl

I have the "d" tag in the examples, but I can add it to the text and make it more explicit.

decoding json twice should be illegal

yup

(en|de)coding horror