Tiny notes (210 max chars) #1710
Conversation
|
👀👀👀
Are you ripping out markdown from amethyst kind:1s? 🍿 |
|
Sir, this is kind 25. Kind 1s don't change. :) |
|
|
||
| Reactions MUST use [NIP-25](25.md) with a `k` tag to `25`. Clients MUST only download and display reactions that include the `k` tag in notifications. | ||
|
|
||
| Zap Events MUST also include the `k` tag of the source event. Clients MUST only render zaps that include the `k` tag in notifications. |
There was a problem hiding this comment.
We need to update NIP-57 to allow for this; many zappers don't accept the 9734 if it has a tag they don't like, I ended up having to remove k tag from Olas zaps.
There was a problem hiding this comment.
We will need to make this work. Otherwise all clients will see all the other clients notifications and it will just confuse users.
Exactly https://github.com/nostr-protocol/nips/blob/master/10.md?plain=1#L19 |
|
I think entities, like mentions and links should count as 1 character (that's what my 140-chars relay does) |
Could be as well, but I still want the pre-cached names and quotes in there. The Client should be able to layout the post without any other event and that includes the @NAMEs and quoted events. |
|
What happens if I publish a |
Receiving clients are going to crop it. And supporting relays should reject it. Your message ends up not showing up anywhere that matters (the clients that support this kind and care about it) |
|
This might be a little too opinionated, particularly with regard to how things should be rendered. But I like the approach. I do think character counts for entities/images should be defined. |
|
FYI: Twitter had a 140 character limit because the tech initially was for SMS. It wasn't because 140 is somehow a magically good cutoff. I think this idea is silly and virtually pointless but if people start using it I will be compelled to support these in gossip, bloating things further. |
|
what is the usecase? |
|
There is a passionate amount of users on Nostr who want a character limit on Kind 1. I don't think we should change Kind 1, but we can create a kind just for them. I just used that opportunity to figure out a different way to define kinds to be more prescriptive on what Clients supporting that kind must and must not do so that the experience is elevated on all supporting clients. |
|
I agree with the idea of creating different kinds and being more strict about them, but I think "tiny notes" is too close to kind 1 to justify a change. Kind 1 is already "microblogging". Unlike with kinds 20, 21 and 22 there is no reason to believe these tiny notes will have any content that wouldn't fit naturally in kind 1s. |
|
That's kinda the point. These opinionated kinds can serve as specific implementations of generic kinds like kind 1, 20, 21 and 22 for those who want to build a different user experience with pretty much the same type of payload. I think this is just the beginning. There are a lot of specific user experiences that cannot be built on generic kinds because there is too much trash on that kind that breaks the desired experience (tiny notes in this case). As we move into the future with better and better clients, there is a good probability we will see many (dozens) sub-types of kind 1s and others. |
a client can put limitations on kind 1, show kind 1s with limited chars, or just summarize them, and configure their default relay to accept 140 char kind 1s only. then it would be the same thing + more clients wil support it. |
|
also, what of i want to build a client with 150 char limit? i can't create a nip for it. |
Not easily. The client has to download everything and then filter only the small new threads. Since most kind1 are replies and bigger, the client will have to download a TON of data before seeing the first useful events. Having to use specific relays to filter down Kind1 content sucks. Also, the whole point is to not mix with the regular kind 1 feed. Implementers of this kind don't want to see small kind1s just because they are small and miss all the rest the author is writing. They want to see posts from people that WANT to post only small tweets. It's more consistent to just migrate to a new kind and build a community over there than trying to figure where each post will show up based on size and the amount of imetas that were added. |
You can. And you most definitely will if you think 150 is a good number and different than anything else. That's the beauty of Nostr, people will do what they need to do to satisfy their users. There is nothing we can do about it. |
|
In a more general point, we started by hosting images and videos with just kind1. Then we realized that it was dumb and created NIP-94 for a feed of external files. Then we realized NIP-94 is too general and created Video event kinds. Then pictures were also migrated to Picture Kinds. #1704 made me realize even the Video kinds are now too general. We are almost always moving to new kinds that are more specialized versions of the older kinds. And this will keep going. |
i agree that this is the good point about nostr. and we should not stop it. but when we try to make it an standard its a little different. what do you want from an nip? before i posted a comment on another pr here and talked about it. i think making more maybe i create a restricted list of nips somewhere and added some tags like whatever this is for clients or relays. this would be easy and useful for devs who are implementing something specific. |
check: #995 (comment)
don't you think it would keep stuff broken/incompatible for a long time or even forever? |
That's a fallacy. It's better to do LOTs of specific NIPs than a few super generic ones. NIPs are not standards. They just describe what's out there. Because people can do whatever they want, it is very likely that we will have 1000s of NIPs describing exactly the same thing with small differences. And it will all be good because each Client is just concerned with their own domain. They don't even need to read the 1000s of NIPs to code.
That's just the way things are. I still process the old [index] way of citing users and notes on Kind 1 just because there are millions of notes that use that system. Old stuff will always be there. And that's why it breaks new user experiences. |
What if I want to post a video and a short blurb about the video? and maybe a picture, then some more text, then another picture, and with a subject and with with PoW? Composition lets us do that, combinations that nobody could reasonably write a NIP for. By moving everything into separate kinds we lose composition. |
|
Kind of. As you can see, this PR uses a lot of compositions from other nips. To me there are 2 types of NIPs:
The root objects are always specializing to get closer to a desired user experience. And the non-root objects move to the generalized/ compostable direction. |
|
Love it, especially the "Cached Information" part. It feels like kind-1 2.0. I really appreciate the effort from the big client dev since it’s too late to fix the broken kind-1 (kind-1 replies are actually broken, though). This brings a refreshing perspective for client developers who have reluctantly implemented the broken parts and pretended that were great for users. |
|
This should be configurable via a tag like |
|
The title of the PR has been changed to avoid unnecessary confusion. |
I don't think event kinds should be general with tags to make them specific. It doesn't work. It tries to put too many different communities into the same bucket and people start asking why some things show in client A but not in client B while both support the same NIP. It's terrible for user experience. Each kind should have its own culture around it. With many apps that support that specific culture. If you want a different culture, like ALL CAPS, then build a different kind so that apps can be developed JUST FOR THAT. Generalization is the killer of innovation. |
This is my first stab at making a VERY opinionated kind whose Clients only render these types of events.
Read here