How does nostr feel about highlights in the social feed?
A) #YESTR
B) don’t care
C) verboten
D) what is a highlight?
#asknostr
nostr:note1u97gzx20gp6tjwysgegwsc95mj92ylanprpmxz5dv3pwd565g7ysqyl8dr
Discussion
#Yestr
D
On various nostr apps, you can highlight and/or see highlights of various things - tweets, long form articles, webpages, and even PDF documents.
https://github.com/nostrability/nostrability/issues/61
Jumble.social highlight example
A
A
I think folks should be able to share highlights to their feed, such as quoting it within a kind 1, and have it show up, but it shouldn't go straight to the feed as soon as the highlight is made.
> but it shouldn't go straight to the feed as soon as the highlight is made.
Why?
Say I am highlighting something I want to comment on. If the highlight goes to the feed immediately after it is made, there the feed will show the original highlight, and a few minutes later, my quote-post with my comments.
Also, if the highlight ahows in the feed on its own, without any context, it might be assumed that I highlighted it because I agreed with it, but my quote-post with my commentary might make clear that I highlighted it in order to disagree with it.
Now, if there is a way to add comments at the time of making tje highlight, so that it only shows in the feed once, I would be all for it.
> Say I am highlighting something I want to comment on. If the highlight goes to the feed immediately after it is made, there the feed will show the original highlight, and a few minutes later, my quote-post with my comments.
This problem is solved by scheduled posts.
> Now, if there is a way to add comments at the time of making tje highlight, so that it only shows in the feed once, I would be all for it.
This exists. It’s either referred to as quote comment highlight, or annotations.
iOS damus, and lantern support creation. See highlights matrix for more details.
Yes. Highlights & annotations are content discovery as much as they are content. There are very few kinds that have that capability.
I dont care, as long as alt-tags are supported and used, everyone can do whatever they want
What do you mean by “alt-tags”?
Nip31
Can you share a 1-2 examples of app implementing this in practice?
No, that is the problem, because it should be implemented everywhere by everyone in all cases
Article on habla has the alt tag https://njump.me/naddr1qvzqqqr4gupzpwa4mkswz4t8j70s2s6q00wzqv7k7zamxrmj2y4fs88aktcfuf68qqjk67fdwajk26mn955rzwptxyujjttfdckhyetkd9jhwtfjxqhnqdf0xgcrydg2sg8h5
product listing on shopstr
I don’t see a shopstr link anywhere in the linked article when I open with havla
The alttag is here:
"Product listing: Sunflower - Testing"
This should be enough and is fine. Eventhough the client you are using does not render kind30402 events, it can display that string making it clear what it is, i.e. a product listing, of a sunflower.
Nip 89 integration should subsequently give you the hints as to what clients you could use to render the event, if you are interested.
Is this not in the user facing UI?
Is it solely in JSON blob, and not surfaced to the user?
I dont understand, can you clarify?
Where are you seeing “Product listing: Sunflower - Testing"
In the example long form article as seen by habla?
I see that in the JSON of the second example he mentioned, under the tag 'Alt'. The JSON can be inspected on njump at the bottom by clicking 'Show more details'.
In the first example, the alt tag is:
"This is a long form article, you can read it in https://habla.news/a/naddr1qvzqqqr4gupzpwa4mkswz4t8j70s2s6q00wzqv7k7zamxrmj2y4fs88aktcfuf68qqjk67fdwajk26mn955rzwptxyujjttfdckhyetkd9jhwtfjxqhnqdf0xgcrydg2sg8h5"
The idea behind the alt tag is that any client that supports it, but does not support the kind in question, will render what is in the alt-tag, instead of breaking (showing some error like "cant load event" or whatever)
Excellent. Note that although i might have preferences on what is out in the alt-tag, it does not really matter all that much, anything is better than it not being there.
Combine it with nip89 and Nostr as a whole functions so much better.
This way you can always just reference whatever event in a kind1 note, and be rest assured nothing breaks and is at worst, suboptimal. Also takes away pressure from kind1 clients to keep up with stuff if they dont want to.
yes but you have to paste nostr:event (preview) if you paste nostr:naddr assume that the reader is in a client that shows that kind
#YESTR
one of my favorite kinds, yes please!