Update 18.md for reposting parameterized replaceable events

[digi-monkey]

Reposting is a key mechanism that allows for the discovery of quality content. Therefore, I believe it would be beneficial to apply the repost feature to NIP-23 long-form articles as well.

[hazeycode]

Concept ACK. But should we consider making the e tag mandatory such that the repost can always be traced to the version of the event that the reposter actually ACK'd? Clients and relays can simply ignore it but the information is retained.

[digi-monkey]

Concept ACK. But should we consider making the e tag mandatory such that the repost can always be traced to the version of the event that the reposter actually ACK'd? Clients and relays can simply ignore it but the information is retained.

I like this idea. But not sure if the relay will keep the old version event of the long-form? if there is a archive relay that keep all the version of the long-form this will be meaningful.

[hazeycode]

A repost event can already link to a PRE using an a tag. But I support the notion of suggesting that it is a good idea in this NIP.

[fiatjaf]

Are you doing this somewhere?

[digi-monkey]

Are you doing this somewhere?

yes I plan to do this in the upgrade version on flycat https://github.com/digi-monkey/flycat-web/blob/develop/src/service/nip/18.ts#L8-L9

[hazeycode]

I don't think NIP-23 needs specific mention, nor that content can be used for this purpose.

How about moving the a tag recommendtion into a subsection titled "Reposting Parameterized Replaceable Events"?

[digi-monkey]

I don't think NIP-23 needs specific mention, nor that content can be used for this purpose.

How about moving the a tag recommendtion into a subsection titled "Reposting Parameterized Replaceable Events"?

sure, that is more clean. updated.

[vitorpamplona]

Amethyst supports reposting of any event, replaceable events included. I would just remove the word "also" from the new text. Ideally, users and clients should choose between reposting an a tag and thus showing the latest info of that event (useful when you trust the author to not completely change it), XOR reposting the e tag that fixes a given version of the replaceable event in the repost event (useful when you don't trust the author). Having both in a single repost makes it confusing.

[hazeycode]

What's confusing to have both? They are both well defined. Keeping the 'e' tag means there doesn't need to be trust, there is no reason to drop it IMO.

[vitorpamplona]

If you have both, which one are you reposting? The original e event or an updated event through a?

[vitorpamplona]

The issue is having 1 repost with an e AND an a tag at the same time. It's unclear which version the author wants to repost.

[hazeycode]

The 'e' tag should always refer to the event that I interact with; i.e. that is the version of the "content" being re-posted. It does not need to refer to the original event that represents the "content".

Including an 'a' tag simply allows finding updated versions of the "content".

[vitorpamplona]

ok, but if you have the two tags in a single repost, which one do I display? And why are we making it this confusing?

[hazeycode]

ok, but if you have the two tags in a single repost, which one do I display?

That's a good question. It depends on the client. Either displaying the latest or displaying the "original" but also that there is a new version available would be acceptable.

The point is that even if one client ignores the 'e' tag, the information is still there. I don't think there is good reason to throw the information away.

[vitorpamplona]

And we can do that - Amethyst will always display the newest event in the entire list (you can have multiple es and as together). But that is not ideal as guidance.

The NIP guidance should be for the author to make it clear which version he/she wants to display their followers. Don't let clients guess or we will see inconsistencies everywhere. And inconsistency is the thing that breaks even the most beautiful product.

[hazeycode]

You're right. The guidance should be to show the reposted version and a call-out to the updated version. But clients are free to ignore the guidance.

[hazeycode]

I think it is reasonable to create a new repost kind for each type of content.

I agree with this.

@fiatjaf has made good points, I revoke my ACK, FWIW.

[staab]

Composability is bad for interoperability. It's better to make a new kind.

This makes me sad, I wonder how true it is. 🤔

[fiatjaf]

More problems with using a k tag instead of a new kind:

• existing clients will all break because they all assume kind 6 contain text notes inside (even if they don't break they will still have to downloads tons of data they don't want and filter that data out on the client, only after parsing everything etc)
• uses more data

[vitorpamplona]

existing clients will all break because they all assume kind 6 contain text notes inside

Can we do a quick survey to see which ones actually break?

Don't get me wrong, I am all for being overzealous to keep things working if it is actually needed. But if clients already deal with this (I believe no one actually thinks reposts are only for kind-1s) then making decisions assuming that they are not is highly damaging to the evolution of the protocol.

[vitorpamplona]

Habla has been using Kind 6 for Long-form content for a long time now. We should have heard people complaining at some point in the past if clients aren't ready for it.

I just boosted Jack's post on Habla to see if anyone complains.

[fiatjaf]

Indeed it does. I still think we shouldn't do it and we should ask Habla to move to the new kind. I just tried it too and it doesn't break things.

But what is probably happening is that normal kind:1 social clients are having to download these giant notes and then hide them from the feed. It's just bad manners.

[vitorpamplona]

But what is probably happening is that normal kind:1 social clients are having to download these giant notes and then hide them from the feed.

That's why I think the k is a good addition. They can save some data already if they add that on.

I think this particular change doesn't break anything.

As we go on we will see less and less of this "breaking" behavior. Nostr clients these days learn very quickly to be resilient to any non-nip-compliant shit that comes in. Because there are people creating all types of weird payloads right now. There is no way to run away from it. Clients will have to become resilient.

For instance, it's extremely common to see Kind 6s with multiple e tags even though that should never happen. Which one is the boosted post? No one knows. It's whatever the receiving client wants to do.

As a client, you cannot expect Nostr payloads to be well-formatted or to follow any particular guidance no matter how well-defined it is. You have to prepare for the worst. And there is just no way to change that.

[staab]

I don't support re-posts, but I do support nevent embeds. My goal is to be able to handle any event kind and show a reasonable summary (even if it's pretty minimal). I also want to be able to show many types of event kinds in user feeds. For example, I recently added 1985-based relay reviews. I think it would be awesome for those to show up in your normal social feed — your friend rated a restaurant, that's actually pretty valuable information, and you'll be interested. It certainly beats sending pictures of your food.

Tangential to this actual issue, but germane to the discussion. Interoperability is of course paramount, but having a powerful protocol is also extremely important.

[fiatjaf]

That's why I think the k is a good addition.

Sure, we can do it with the k tag, but we go back to my previous point: is using k better than using a new kind? No, it is not, as I argued above.

As a client, you cannot expect Nostr payloads to be well-formatted or to follow any particular guidance no matter how well-defined it is.

I know, but still the guidance should be as best as possible for those who want to follow them. And you can always unfollow people that are trying to screw you by sending bogus events to your feed. If the spec mandates bogus events then that becomes impossible.

[fiatjaf]

Other two points in favor of a new kind:

1. Existing clients that are sending kind:6 events for reposts don't have to update their implementations to add a k tag with value of 1, they can just keep existing.
2. And to @staab's point, clients should be able to pick what type of content they want to display in their feed. It's very easy today for a client to use a filter like {"kinds": [1, 6], "authors": [...]}. If they want, they can add 1985 or whatever other kind they want in that same array -- but if now we have kind:6 events that require an extra k tag then they will need a new filter, it puts more burden on relays, more work everywhere, more data to send, more possibilities of failure etc.

@pablof7z you asked to be mentioned here.
@verbiricha your webapp is destroying the world.

[pablof7z]

I disagree with this position; nostr gives us incredible composability, and NIP-31+NIP-89 make it so this composability is not bad for interoperability; quite the opposite is GOOD for interoperability, as a kind:1-centric client all of the sudden gains access to marketplaces, song distribution, note taking, and whatever (~all) other use cases we end up building in nostr.

Why create kind silos now that we have these primitives for cross-kind interoperability? I would have agreed with @fiatjaf's heart-wrenching "Composability is bad for interoperability. It's better to make a new kind." but with those two NIPs this is no longer true, and in fact, this seemingly-chaotic composability can (will) unlock functionalities that were simply not possible before nostr. (yes, I repeat myself)

---

I do like the k tag, in fact, I had the same idea while writing highlighter; beyond being able to quickly find kind:9802 reposts with a {kinds:[6], "#k":[9802]} filter, the k tag also would allow a kind:1-centric client to decide whether to fetch the reposted event or to simply ignore it (which it shouldn't imo).

[fiatjaf]

the k tag also would allow a kind:1-centric client to decide whether to fetch the reposted event or to simply ignore it (which it shouldn't imo).

How can the kind:1 client ignore it? All kind:6 events will come when the kind:1 client requests {"kinds": [1,6]}, no matter what is their k tag, because the kind:1 client doesn't know about these tags, also all the other kind:1 clients are not writing k tags on their repost events.

[fiatjaf]

[fiatjaf]

If you really want to use the k tag, then at least make a new kind "generic_repost" that supports the k tag and leave the current behavior of kind:6 unchanged.

[vitorpamplona]

If you really want to use the k tag, then at least make a new kind "generic_repost" that supports the k tag and leave the current behavior of kind:6 unchanged.

Not to disappoint but I'd say kind:6 has already changed (months ago). The NIP is just very outdated and doesn't match events in the network anymore. Asking it to go back won't delete the events that are already there. We might as well embrace it by now.

[staab]

If you really want to use the k tag, then at least make a new kind "generic_repost" that supports the k tag and leave the current behavior of kind:6 unchanged.

The draft for #468 could support this use case very easily.

[fiatjaf]

Not to disappoint but I'd say kind:6 has already changed (months ago). The NIP is just very outdated and doesn't match events in the network anymore. Asking it to go back won't delete the events that are already there. We might as well embrace it by now.

What has changed about it?

[vitorpamplona]

Not to disappoint but I'd say kind:6 has already changed (months ago). The NIP is just very outdated and doesn't match events in the network anymore. Asking it to go back won't delete the events that are already there. We might as well embrace it by now.

What has changed about it?

The fact that we have 1000s of reposts on replaceable events, other multiple 'e' stuff, and reposts of non-kind 1s.

If clients have been using it without any issue for months, why should we change the client and not the NIP?

I am against any policy document that goes against the practice of it.

[vitorpamplona]

It's also good to remind everyone that NIP-18 never claimed that it was designed for Kind 1s only. Clients using it for any other kind are actually fully complying with the NIP.

[fiatjaf]

You don't have to be such a purist, you can be more pragmatic.

Let's forget the past mistakes and create a new generic_repost event.

[pablof7z]

Let's forget the past mistakes and create a new generic_repost event.

ACK

[vitorpamplona]

You don't have to be such a purist, you can be more pragmatic.

Pragmatic person in me says: "Shit is working. Stop regulating things that work".

Let's forget the past mistakes and create a new generic_repost event.

People are free to create one if they think it's better. Amethyst will fully support it. Amethyst will also fully support the current use of Kind 6 for anything people will actually use it for, complying or not to a NIP.

[fiatjaf]

Pragmatic person in me says: "Shit is working. Stop regulating things that work".

You're not thinking about the long term. Also I just literally posted an example of a thing that is not working.

People are free to create one if they think it's better. Amethyst will fully support it. Amethyst will also fully support the current use of Kind 6 for anything people will actually use it for, complying or not to a NIP.

We must keep the ecosystem open for all the people who want to make apps and don't have a full-time team dedicated to their apps like you have on Amethyst (yes, you are the team). Also we should try to not bother people who may not be interested in implementing every new thing someone else comes up with and just wants to keep using their app as they always did.

[vitorpamplona]

We must keep the ecosystem open for all the people who want to make apps and don't have a full-time team dedicated to their apps like you have on Amethyst (yes, you are the team).

I am nowhere near full-time.

Also we should try to not bother people who may not be interested in implementing every new thing someone else comes up with and just wants to keep using their app as they always did.

I don't think we have any choice in this. Anyone can do anything in nostr.

In this kind6 case, they have been and will continue to receive non-kind-1s boosts no matter what we do here.

[mikedilger]

Can we do a quick survey to see which ones actually break?

A quick peek at the code shows that gossip was assuming the events inside of kind-6 were "feed related" events. When it gets around to displaying them, if they are not supported by gossip, they get displayed as "NON FEED RELATED EVENT" rather than dropped entirely, an issue I could fix. But I would still be downloading events that I couldn't display.

Not to disappoint but I'd say kind:6 has already changed (months ago).

Existing kind-6 events don't have 'k' tags.

There will always be these "bad" kind-6 events that embed weird-undisplayable-kinded events, and gossip for example will just drop them. But I'd rather not download them in the first place. Kind-16 #610 let me deal with 'k' tags and avoid downloading them, and creates the composability everybody is clamoring on about, while fixing future kind-6 events so less and less of them will be wastefully downloaded.

[fiatjaf]

@digi-monkey I hope #610 is solving all your problems.

https://habla.news/ has also already stopped sending kind:6 and is sending kind:16 now: verbiricha/habla.news@026b678

[digi-monkey]

@digi-monkey I hope #610 is solving all your problems.

https://habla.news/ has also already stopped sending kind:6 and is sending kind:16 now: verbiricha/habla.news@026b678

cool, a new kind is better for this