nip31: template-based "alt" tags for known kinds

[fiatjaf]

Clients hardcoding alt tags are not very trustworthy. alt tags tend to be garbage in a long-enough timeframe.

This fixes it with hardcoded rich templates that anyone can implement very easily without having to do it manually for each kind.

alt tags can still be used as a fallback.

Readable: https://github.com/nostr-protocol/nips/blob/6b56a0b2063ac60ca3bf720ddd12b3b335f1407b/31.md

[staab]

I like it, although it would be nice if we could remove conditionals to keep the parser stupidly simple. Why HTTP instead of publishing templates as events?

[fiatjaf]

I'm retarded, let's publish templates as events.

[fiatjaf]

I'm also ok with removing conditionals, they just sounded useful in some cases, but they're probably not worth the hassle.

[vitorpamplona]

+1 for alt templates.

But I am against having a list of kinds and templates in this NIP. I find that practice very confusing for people that are implementing other NIPs. Each NIP MUST have its alt template in itself (e.g the Picture NIP should have an ["alt", "<template>"] there.

I am also against {{content}} in templates, otherwise it will just duplicate content, which can be very big, everywhere. It's should be {{content.take(100)}}.... That's what Amethyst does.

[fiatjaf]

The idea of templates is that they will be just rendered on the client, at the time an event is being displayed.

The idea is absolutely not to render these templates and shove them in an alt tag at the time an event is being created.

In fact in the long run I hope we can get rid of alt tags entirely, at least for the top-1000 most common kinds.

But if you got confused about that then I must reword the NIP.

[vitorpamplona]

ohhhh, I misunderstood this.

I don't think we need trusted providers. At least I would not use them (I wouldn't send DMs to a server). I would rather prefer a little library that takes any Event object and gives me a string based on hardcoded templates made by the lib author. All local.

I was actually going to suggest we move beyond alts and added opengraph tags (image, title, description) to each event so that It can be rendered as a link preview on our apps. The link would then open a third-party app when the user clicks on it.

But the more I think about this the more I prefer doing this at the reference level: put the opengraph tags inside the nevent, naddr1 uris so that they can be immediately previewed.

[pablof7z]

so is the idea that app developers will write these alt-kind templates? how will rendering clients know which template to use?

[fiatjaf]

I would rather prefer a little library that takes any Event object and gives me a string based on hardcoded templates made by the lib author.

Library authors can do it, but if you're very fancy you can also have a library that fetches from a provider at compile-time. All these modes of operation are suggested in the proposal. The idea behind providers is just that there could be divergence about what exactly to write for each kind and the text style, that kind of thing, but that is probably a very minor concern.

how will rendering clients know which template to use?

I don't follow the question. Each kind has a template. Client developers decide what templates to use (or they can be super fancy and allow users to pick from a set of options, but this is probably too much). All the information is already in the event itself anyway.

---

Ultimately these templates are just lightweight implementations of a full-blown event view. In some cases they can be almost sufficient, in others they can be just slightly better than nothing, but the idea is that app developers won't have to think about implementing a view for every kind, as with the "alt" tag.