I am becoming an "opinionated event kind" maxi. Nostr kinds could be designed for specific user experiences instead of general types. Like the picture kind Olas uses. Right now it accepts multiple image sizes but we could have one kind that only takes squared images for those clients to use.

It's similar to nostr:nprofile1qy2hwumn8ghj7erfw36x7tnsw43z7un9d3shjqpqdergggklka99wwrs92yz8wdjs952h2ux2ha2ed598ngwu9w7a6fsr4ma0r 's pitch of kind 1s with a 240 chars limit. We could copy kind 1 into a new kind whose expectation is to render only the first 240 chars of content and ignore all the rest. We could have Nostr clients that only render (and make the best UI for) those events.

Reply to this note

Please Login to reply.

Discussion

Having more opinionated event kinds really helps clients show specific types of content without having to filter out the stuff they don't want. that said I'm not sure if I would get as specific as square images, but it would be cool to see if something like that could work

With a tiny user base, I think you want clients to be able to use as many events as possible.

Not really. We all think that is the case, but the more we develop, the more we realize users don't want that. They just one one little thing.

I feel like every dev would just be remaking the same app in that case.

Which is kind of the case right now, at least with the Twitter clone apps.

Kind1 will be the thing that holds it all together, combined with alt-tags.

The friction to switch between apps is already so low, which is actually one of the 'unique selling points' of Nostr, so we should leverage it

Yup, great examples btw sir!

I have not seen a proper solution for how to standardize the character count though. It could be real simple if we equate things like nostr:nevent1blabla, nostr:npub1blabla and blossom::/link/hash to fixed numbers of chars.

Is polymorphism a thing to strive for of avoid here. It seems like most note kinds inherit from kind 1, but they either restrict for more specific clients, or add additional "features". I know polymorphism is not as popular as it once was, but maybe.

Sounds similar to ATProto lexicons, which I think are actually a pretty useful idea.

https://github.com/lexicon-community/lexicon/pull/23

#YESTR

(210 😜)

Good, this is why we worked on the recipe kind (comming soon).

Also, if this new 240 chars tweet kind has edits, will that make you drop edit and markdown support for kind 1?

I am never gonna drop support for edits. It's just waaaaay too used right now to remove it.

Markdown and ASCIIDoc will be enabled for all kinds on Amethyst. If users are writing on that format, we will always render it.