Maybe bring back NIP-18

[arthurfranca]

This is just a suggestion. The PR is just a way to reopen discussions.

Some arguments here along with previous discussion.

This would be a way to address this problem that affects this other PR (#381).

An alternative to ressurecting kind 6 reposts would be keep using kind 1 with a different tag other than e, like an m tag for instance.

[Egge21M]

We have recently implemented reposts by abstracting kind 6 logic from other clients source code. I think we should at least resurrect kind 6 reposts until there is an alternative that finds more adoption

[fiatjaf]

Kind 6 reposts are alive and well, the fact that the NIP doesn't exist doesn't prevent them from being used. I've only deleted it because it didn't reflect the behavior of Damus and wasn't inclined to figure out the exact behavior of Damus and other clients at the time to write the NIP. If someone wants to do that work and write the NIP we should definitely merge it.

[Egge21M]

At Current we build a kind 6 event without content and add the reposted notes e- and p-tag. I think this is what Damus does as well. Would be great to hear other implementers approach before writing a NIP.

[arthurfranca]

Damus puts reposted event as json string inside content. Although it seems a bit redundant as it already adds the e tag with the event id.

I've read somewhere that instead of the enconded event as json, optionally adding extra text to .content would be good (Twitter gives the option to just repost with no extra content OR write something when reposting).

But then it would be different from Damus. So if we want both things, maybe optional tag with extra content is the way to go, although bizarre.

Or we just edit the NIP to be exactly as Damus. But I don't know yet if other clients are using kind 6 in a different way than Damus. Edit: @Egge7 is using without content, which won't make Damus error out, but will be an empty repost for those viewing at Damus.

[Egge21M]

Or we just edit the NIP to be exactly as Damus. But I don't know yet if other clients are using kind 6 in a different way than Damus. Edit: @Egge7 is using without content, which won't make Damus error out, but will be an empty repost for those viewing at Damus.

I thinks it's more appropriate to use the content field for comments by the user that is reposting. Making it essentially what Twitter calls a Quote-Repost. Of course that would mean that clients would have to fetch the referenced event to actually show the whole repost or quote...

And by the way: I am more than happy to change how Current implements reposts, as soon as there is a NIP for it.

[arthurfranca]

Revisiting my NIP-26 delegation (far-fetched) comment, I noticed how Damus kind 6 is in fact meant to be used for transferring ownership (give delete rights) to the reposter. Meaning the event is effectively a copy that carries the proof of whom originally wrote it, while not letting the original author delete it.

I think it does unlock many use cases, but personally would better name it as "Event Copy".

Although for semantics of disposable Twitter-like "Reposts", I think fiatjaf's version is the perfect fit cause it is leaner. It should use a new event kind to not collide with the "Event Copy".

Or we just use the bulk Damus "Event Copy" thing for reposts too and call it a day.

@fiatjaf which path do you prefer?

1. "Reposts" exactly as Damus version (serialized json event inside content)?
2. OR "Event Copy" NIP as Damus version and separate "Reposts" NIP with new kind and empty content (optionally with comment as content for quote-reposts)?

[arthurfranca]

Did my homework. What is a repost today?

• damus: kind 6 with json content (with json not present, shows blank note)
• amethyst: kind 6 with json content. Quote-repost is kind 1 with #[index] (with e tag). So it has to count two kinds.
• gossip: kind 6 with json content OR kind 6 WITHOUT json content (with e tag) OR kind 1 with #[index]
• iris.to: kind 6 WITHOUT json content (for displaying, also considers kind 1 with #[index]` with e tag with mention marker)
• member.cash: kind 6 WITHOUT json content. Quote-repost is kind 1 with e tag with custom 'repost' marker
• app.getcurrent.io: kind 6 WITHOUT json content
• hamstr.to: Repost button not implemented but for displaying, reposts are kind 1 with #[index] with e tag
• astral.ninja: my feed doesn't load, but from the code it seems to consider reposts as kind 1 with no content/#[index] and e tag
• coracle.social: no reposts
• snort.social: kind 6 WITHOUT json content and with e tag
• nostros.net: kind 1 with #[index] or nostr:(nevent1|note10)
• nostr_ruby lib: no reposts

As you can see, some use kind 6 with json content. Some use kind 6 without content. Others use kind 1 with #[index] with etag. Others use kind 1 with e tag with "mention" marker or even "repost" marker.

Currently there is no interop so a NIP is needed to guide clients. I maintain my opinion on previous comment (prefer alternative 2 for saving disk space, but alternative 1 is ok too).

[Egge21M]

I would prefer to have it without the duplication in content, however clients SHOULD include relay hints for the event.

[arthurfranca]

@Egge7 I've ressurected Reposts as kind 6 with blank .content with optional comment inside .content. Main reason is that the majority of clients are supporting this version of kind 6.

Took the opportunity to turn the Damus version (with stringfied original event json inside .content) into a kind 9 event for Event Copy, for different use cases.

Poking @mmalmi @staab @Semisol @monlovesmango @cameri @eskema @jb55 @KoalaSat @verbiricha

[fiatjaf]

No, @arthurfranca, you're doing it wrong. According to your own research there is not a single client using kind 6 with comments. Either they have empty content or they have the reposted event in the content.

And creating a new kind doesn't help here, Damus is using kind 6, that's not going to change, and then you just break everything for no reason.

I think the NIP should say something like:

• for blank reposts, use kind 6.
• you can embed the reposted event inside the content or not, but you should always include an event tag with a relay hint regardless.
• for quote reposts, use kind 1 with an embedded tag (point to NIP-08 and NIP-27).

By the way, thank you for doing this research, this was amazing.

[KoalaSat]

As @arthurfranca said, at this moment Nostros is only compatible with the legacy NIP-08 and the new NIP-27.

If you think about what the app actually does, it just automatically inserts the nostr:... key inside the content, resulting in no difference between this and a manual paste of the user.

My point is, is the intention of kind: 6 to make a difference with NIP-27? is there really a difference? If not, it sounds to me redundant.

[arthurfranca]

@fiatjaf edited it as you suggested.

It is a shame that reposts and quote reposts ended up as different kinds.

Open for text improvements.

[arthurfranca]

@KoalaSat unfortunatelly clients were implementing things differently. Some were using kind 1 with NIP-08(deprecated) or NIP-27 and others were using kind 6.

I think kind 6 is better cause it enables easy counting by subscribing just to the reposts. (Quote) reposts as kind 1 will get mixed with replies when counting and displaying.

[fiatjaf]

It is a shame that reposts and quote reposts ended up as different kinds.

Maybe, I keep swinging my opinion back and forth on this. But it is what it is.

Kind 1 can have multiple quoted notes, so that's a good thing. And kind 6 being just blank reposts can be ignored, counted or displayed at will, which is also good. Once you put your own comment in the thing then it becomes an actual post of yours, so kind 1 makes sense there.

[fiatjaf]

Thank you very much for your valuable work, @arthurfranca, I hope things are going well in Franca-SP, your hometown.