Replying to Avatar ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ

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
0e
slapsquat 7mo ago 💬 3

Oh, this, but a list!

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

Reply to this note

Please Login to reply.

Discussion

Avatar
Silberengel 7mo ago

For indexing.

Avatar
ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 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

0e
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.