This is just my personal opinion, but I believe the biggest reason developers and client apps should support kind: 1111 is that it drastically reduces timeline noise and enables a unified commenting experience across all types of content🔥
Specifically, here are four reasons why I highly recommend supporting it:
1. Clear separation of the main feed and comments
Currently, both regular posts and replies are created using kind: 1. As a result, the main timeline is often flooded with back-and-forth conversations between other users. Supporting kind: 1111 allows the system to clearly distinguish between standalone posts and comments, creating a much cleaner and more readable timeline for users.
2. Generic comments for all types of content
While kind: 1 is primarily intended for short text exchanges, kind: 1111 is designed as a universal commenting standard. It allows comments to be attached to any type of content using the same logic, whether it's long-form articles (kind: 30023), videos, badges, files, or even external URLs.
3. Simplified thread structure
Traditional kind: 1 replies often cause compatibility issues (like broken thread UI across different clients) due to the complex rules for specifying e tag root and reply markers. kind: 1111 simplifies this by clearly defining what the comment is responding to, making it much easier for developers to implement and render threads properly.
4. Reduced bandwidth and relay load
When a client needs to load only the comments attached to a specific post, the REQ sent to the relay becomes much simpler. Fetching only the necessary data reduces network traffic and improves overall app performance.
If Damus supports kind: 1111, I imagine comments would load even faster than they currently do when opening a post's detail view. Furthermore, since many other clients already support and publish kind: 1111 events, Damus users are currently missing out on these comments and are forced to switch to other apps to read them.
These are my thoughts on why it would be great to see this implemented. Conversely, I would genuinely love to hear your perspective and any technical or design reasons you might have for holding off on it🙏
nostr:nevent1qqsqgkkjkerwncsks7h06fujcle7nu32lty4pvayh2dys757rzevxpcpz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzqvhpsfmr23gwhv795lgjc8uw0v44z3pe4sg2vlh08k0an3wx3cj9qvzqqqqqqynd9nqa
Specifically, here are four reasons why I highly recommend supporting it:
1. Clear separation of the main feed and comments
Currently, both regular posts and replies are created using kind: 1. As a result, the main timeline is often flooded with back-and-forth conversations between other users. Supporting kind: 1111 allows the system to clearly distinguish between standalone posts and comments, creating a much cleaner and more readable timeline for users.
2. Generic comments for all types of content
While kind: 1 is primarily intended for short text exchanges, kind: 1111 is designed as a universal commenting standard. It allows comments to be attached to any type of content using the same logic, whether it's long-form articles (kind: 30023), videos, badges, files, or even external URLs.
3. Simplified thread structure
Traditional kind: 1 replies often cause compatibility issues (like broken thread UI across different clients) due to the complex rules for specifying e tag root and reply markers. kind: 1111 simplifies this by clearly defining what the comment is responding to, making it much easier for developers to implement and render threads properly.
4. Reduced bandwidth and relay load
When a client needs to load only the comments attached to a specific post, the REQ sent to the relay becomes much simpler. Fetching only the necessary data reduces network traffic and improves overall app performance.
If Damus supports kind: 1111, I imagine comments would load even faster than they currently do when opening a post's detail view. Furthermore, since many other clients already support and publish kind: 1111 events, Damus users are currently missing out on these comments and are forced to switch to other apps to read them.
These are my thoughts on why it would be great to see this implemented. Conversely, I would genuinely love to hear your perspective and any technical or design reasons you might have for holding off on it🙏
nostr:nevent1qqsqgkkjkerwncsks7h06fujcle7nu32lty4pvayh2dys757rzevxpcpz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzqvhpsfmr23gwhv795lgjc8uw0v44z3pe4sg2vlh08k0an3wx3cj9qvzqqqqqqynd9nqa