Nostr Web Client

an example of the retardation of #nostr kinds, instead of using industry standard #mimetypes

i'm writing a full text index, and i've made a decent filter that ignores symbols and URLs and suchlike

so, actually, which event kinds even have content fields that you even want to search? textnote kind 1 and articles? there will be more, thanks to the awesome folk at nostr:npub1s3ht77dq4zqnya8vjun5jp3p44pr794ru36d0ltxu65chljw8xjqd975wz so i will have to update the kind whitelist in the future to cover their cases, but just imagine... what if i could just filter on a mimetype prefix of "text"

omg! what a revolution!

to not have to constantly scan through hundreds of bullshits and their format definitions to figure out if they might contain relevant content to your search engine's hunger for actual fucking text

nah, what a stupid idea. only been in use for 20 years it's surely not stable at this point

*cough*

Reply to this note

Please Login to reply.

Discussion

🇵🇸 whoever loves Digit 7mo ago

Could we still make MIME types for events?

Silberengel 7mo ago

We are. MIME types in the `m` tags and Nostr-specific classification in the `M` tags.

Silberengel 7mo ago

Examples:

https://njump.me/naddr1qvzqqqr4tqpzplfq3m5v3u5r0q9f255fdeyz8nyac6lagssx8zy4wugxjs8ajf7pqydhwumn8ghj7argv43kjarpv3jkctnwdaehgu339e3k7mgprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdqq4xzetndac8xttxv93xcetn946x2um5ve5kcefdvfujmsuxwdhhqttk946x2um5v3shgcgm3ujq5

https://njump.me/naddr1qpzkzetndac8xttxv93xcetn946x2um5ve5kcefdw35x2tthdakxvtt5w4exuety94eksetsdpjhyepdxgkky7fdcwr8xmms94mz6ar9wd6xgct5vyq3kamnwvaz7tm5dpjkx6t5v9jx2mpwdehhxarjxyhxxmmdqgs06gywary09qmcp2249ztwfq3ue8wxhl2yyp3c39thzp55plvj0sgrqsqqqa2e5puf3m

Danny, the cyber guy 7mo ago 💬 1

I agree with nostr:npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmleku, implementing numeric kinds was a design misstep in the Nostr protocol. Numeric identifiers are inherently more difficult to memorize, standardize, and use correctly, also they create confusion.

A better approach would have been to implement standardized mime types or namespaced types instead of numeric kinds, which would have created a more intuitive and self-organizing system.

while I absolutely think you should use the `m` tag with your use case, I also think that we're early enough in nostr that we can still add mime-types as a replacement for kinds.

Silberengel 7mo ago

I actually like the kinds, as they're an easy way to find the relevant spec for some particular implementation (just search for all of them listing the kind number), and they allow numerous similar implementations to occupy the same space, without having to agree on a spec.

But the M space they occupy should be defined. Also, kind numbers only need to be unique _within a particular M space_, which means the devs working within that space need to keep a list of the kinds. Nobody needs to keep a full list.

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

nobody has bothered to keep a list either, should be a necessary part of a PR merge to add your new kinds to the list

Silberengel 7mo ago

There is the NIP repo ReadMe.md list, but many kinds aren't on it.

The ReadMe list additions are the only PRs that usually go through.

il_lost_ 7mo ago

oh the NKBIP-06 https://njump.me/naddr1qvzqqqrcvgpzphtxf40yq9jr82xdd8cqtts5szqyx5tcndvaukhsvfmduetr85ceqyghwumn8ghj7mn0wd68ytnvv9hxgtcprdmhxue69uhhg6r9vehhyetnwshxummnw3erztnrdakj7qqgde4ky6ts95crvfahkt7

they were looking for common rules, but I don't know if they succeeded in the end

https://github.com/nostr-protocol/nips/pull/1800

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

nope, nostr isn't gonna move into the nineties and add mimetype tags

that's why it's fortunate that i am an esteemed data architecture expert for the best nostr project

and fortunate that they are all old school people who understand that what works for WWW should be valid and prevail on a much newer protocol

il_lost_ 7mo ago

one part will do right

Silberengel 7mo ago

WHY NOT JUST USE M TAGS?!!?

WARUM IMMER EXTRA WURST?

Es ist zum kotzen.

Niel Liesmons 7mo ago

M tags instead of what? Kinds?

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

no, it's to tell the client what format of text is in the content field

this would end the bullshit about not allowing markdown in kind 1 notes, for example

Niel Liesmons 7mo ago

True.

But it's not really even MarkDown and AsciiDoc that we're using here.

We've got nostr : nevent links, invoices, custom emoji, inline profiles, etc...

Time to also have clear definitions of these nostrified versions imo:.

- Ntext

- NDown

- NosciiDoc

Silberengel 7mo ago

It's Nostr-flavored markup, but it's based upon Markdown or Asciidoc.

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

nostr flavored as in it recognises nostr: prefixed entities right? or are you supposed to use link: with those?

Silberengel 7mo ago

Yeah, it handles Nostr entities in a sensible manner, basically.

You can see how that works in my latest PR. The Nostr Markup logic is actually complex. That's how the problem of the disappearing links came about. I'm not disappearing them, with my parser, I just add an internal link behind them, and then the user is free to choose.

Sometimes external links are broken, after all, or you're someplace with slow Internet and avoiding websockets.

Silberengel 7mo ago

I've spent weeks figuring out how to do all of that stuff. Have a headache. 😂

Silberengel 7mo ago

Yeah, I'm only building one editor, with a choice of Markdown or Asciidoc, as the basis. Why bother with plaintext? There is no such thing as plaintext.

Silberengel 7mo ago

1. This is *not* plaintext.

2. This isn't either.

3. You can write `anything` into a textbox.

:heart:

Silberengel 7mo ago

Also, who died and said you can't use [[wikilinks]] in every note?

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

plaintext is from the before time, before Smalltalk at Xerox PARC

as soon as it stopped being a dynamic version of a TTY there was no more plaintext

even TTYs got colours and styles and blinking and underline and shit, not long after the arrival of GUIs

Silberengel 7mo ago

As soon as you're like

* First of all

* Secondly

* And don't forget

It's markup. Someone can make that pretty, for ya.

Daniel Wigton 7mo ago

Hmm. This is a decent point. I am not thinking nostr specifically, but I have kicked around the idea of having all data identified by a context hash H("nostr/note/kind 1") would be an example. Then applications could create their own data types. But it isn't super useful for searching without a mimetype.

Food for thought.

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

yeah, my recommendation is an M tag that uses standard mimetypes

for now, textnote and article are pretty much plaintext and markdown for now, but they should have always had a mimetype tag attached to them

having to write code that analyses content fields to divine their type is the epitome of retarded protocol architecture

slapsquat 7mo ago

Oh, this, but a list!

I also don't get the 1337ness of single character keys. Somewhat as retarded as kinds but yeah, tolerable.

Silberengel 7mo ago

For indexing.

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

it's just to limit how many indexes the relay's event store has to make to max 52 different kinds of tag keys, these are required to enable search, if you don't index them the only way to search is to exhaustively iterate through the records which would be insanely slow, but if you let any tag key be required to be indexed the database is again going to be very slow

fiatjaf added this because he knows about database indexes, his code in the eventstore repo is quite extensive and actually even has a little bit of documentation

slapsquat 7mo ago

While clever, we are still optimizing database logic at the protocol level.

Anyway, we can keep a small int kind for CORE event types. My argument is against the rest of the bloat which will never be enough.

Nothing stops a relay backend from pre processing mimetypes and translating each - for the ones that have indexing interest - by using an unique small int. Neglectible pre processing overhead.

Silberengel 7mo ago 💬 1

I'm using `m` for MIME types and `M` for usage/category

slapsquat 7mo ago

Nostr kinds: early optmization syndrome

We WILL run out of kinds and then there will be proprietary kinds like 42069 primal bs giveaway. So retarded.

What was the point? Save some bytes? There will be fighting over nostr kinds. The sooner we abandon those, the better.

An m ordered list field with "mimetypes" that would be handled as CSS does with fonts - fallbacks.

[nostr/hyper,nostr/note, ..., text/plain]

Clients/Relays handle/index however they prefer. Voila

Niel Liesmons 7mo ago

Good point :writinghand:

Silberengel 7mo ago

You learn a heck of a lot about Nostr, if you hang out with backend devs.

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

which is how it should be and why we should be given a bit more respect

nostr is a protocol, the clients are just clients, they could just as easily be pulling from any data source, they are not as important for the capabilities of the way the data can be moved around