NIP-93: backwards-compatible alternative media URLs

[fiatjaf]

full text: https://github.com/nostr-protocol/nips/blob/alt-urls/93.md

[fishcakeday]

I think it is essential to support multiple URLs. I am not sure if it is supported in any other NIPs, but it would be good to specify how we can provide alternatives when we have more than one URL. Maybe something like, alturl or alturl[n], e.g., alturl1, alturl2, alturl3…

[fiatjaf]

In the current form the NIP already supports multiple URLs, you have to specify the original URL and then the replacements.

I guess having alturl1 and so on could be better as they would save some bytes -- but also make replacement harder.

[fishcakeday]

Good point! Thanks

[dtonon]

I would accept the kind:4001 only from the original note owner, it is tricky to manage a priority queue of events in a decentralized environment, which leads to possible attacks. At least at the beginning, to see how things flow.
Or I would make it optional using a tag in the kind:1; this could be by default non permissive, with a client preference.

Something like this:

"kind": 1,
"content": "I just painted this: https://wallpapercave.com/wp/wp5960277.jpg",
tags": [
    ["4001-by-others", "permit"],
...

I would also invite the clients to show that an image has been replaced with a mark.

[jb55]

seems like something I might add to https://github.com/damus-io/dips/blob/master/01.md . I still like the variadic tag method damus uses here, as you don't need to duplicate the url each time, and there is one tag per image so they are grouped nicely.

[staab]

Kind 4001 seems like it might as well be broader, as a generic edit event. I don't much like adding mutability to notes to solve this problem, if links rot, let them rot. I also don't like variadic arguments because they break extensibility.

Otherwise, this solves the problem of posting multiple versions of the same url, but not the content addressing problem. Image hosting already has too many half-baked and incompatible solutions already (NIPs 94, 95, and 96), which don't really compose to solve all the problems. We should at least try to add this in a way that leverages those NIPs where possible.

What I want from a solution is content-addressing, where you have the id of the image (I believe the closest thing the other NIPs give us is the ox, although maybe a 1063 could be used as a canonical id — but of course, that has to be hosted and no one is going to care about them most of the time), and can de-reference it if all the "hints" are invalid. nfile provides the image's id (ox or whatever else is better), and multiple urls.

The main weakness of this is that it's not backwards compatible, but it provides the same UX as other rich content (nevent, nprofile). If it's ok for users of extremely simple clients to copy/paste nevents into njump, or paste urls into the browser bar, it's probably ok for them to have to paste nfile into njump too. And keep in mind that nfile will not be widespread, since it's only necessary if users want that durability. I plan to use it in coracle only if someone uploads an image to multiple image hosts.

I have a rough draft of this here: #899. The problem with it though is that nfile isn't really the same as other entities, since it doesn't really have anything to do with nostr itself, and overloads the relay field. So I'm happy with a different format that solves the same problem. #521 also tackles this, but it feels too open-ended and hacky since it overloads the meaning of url fragments in an effort to be backwards compatible. Really, it's not backwards compatibility we're talking about here, since we're not breaking anything, we're only adding a new format. So I think a minimally human readable format will be fine for this.

Edit: @jb55's imeta tag is actually pretty compelling to me. alturl, ox, and a NIP 94 id could easily be added to it. It also supports the naive use case where content isn't parsed. I might just use that instead.

[fiatjaf]

Kind 4001 seems like it might as well be broader, as a generic edit event.

This would be an unnecessary abstraction that would just add complexity for no gain. We have enough kinds to have different functionality segregated in different events and clients to implement just the parts they want.

I also don't like variadic arguments because they break extensibility.

This is another issue that only exists when you want super generic solutions. A generic solution is by definition one that is not specific enough, thus you must leave a lot of room for someone else to specify things later. Bit if an event kind is very straightforward and specifically directed at one very small goal (like this proposal here), then you don't need extensibility.

The same reasoning applies to imeta. imeta deals with displaying images in a nice and fast way, which to me is a very different goal than rescuing notes for which images have died.

if links rot, let them rot

I personally agree with this, and I don't expect much usage of this kind:4001 thing because I think most people won't care -- but so many people are complaining about it I acknowledge that I may be biased and the problem might be real -- and this proposal is so far the best solution I could find for it (regardless of the specifics of the form specified in this NIP that can probably be improved).

What I want from a solution is content-addressing

I think this is both unachievable with a satisfactory solution (see IPFS) and a false goal that wouldn't really help anyone. I could expand on this, but I will do it elsewhere eventually.

[vitorpamplona]

I personally agree with this, and I don't expect much usage of this kind:4001 thing because I think most people won't care

They will care when somebody buys the domain name and displays child porn instead of their original content.

I agree with @staab that this is just a different way to do event edits. It doesn't make much sense to allow people to change URLs freely but not what they have said about them. If we are already going half the way, why not go the full way?

What I want from a solution is content-addressing

I think this is both unachievable with a satisfactory solution (see IPFS) and a false goal that wouldn't really help anyone. I could expand on this, but I will do it elsewhere eventually.

Nostr does content addressing all the time. We constantly have to search for events that are not where they were supposed to be. If you think content-addressing is unachievable, you are saying that Nostr shouldn't exist. But it does.

[fiatjaf]

If we are already going half the way, why not go the full way?

Because this is much simpler, it is optional, it is backwards-compatible. This is not about editing images, it is about saving them only in catastrophic situations.

Also this proposal includes people proposing image replacements in other people's notes, which is completely out of scope for editing notes in general.

Nostr does content addressing all the time. We constantly have to search for events that are not where they were supposed to be. If you think content-addressing is unachievable, you are saying that Nostr shouldn't exist. But it does.

Not really, what we do (or should be doing) in Nostr is to search for events where people have said they are publishing them. Events are ultimately owned by someone, which is the crucial difference that enables this. General-purpose "content-addressing" doesn't have ownership, there is no clue about where to find things -- and just giving people a list of URLs is not content-addressing.

[vitorpamplona]

This is not about editing images, it is about saving them only in catastrophic situations.

It doesn't matter. People will use it to edit images.

Not really, what we do (or should be doing) in Nostr is to search for events where people have said they are publishing them.

Sure, then do the same for images. As long as we can verify the hash, it should be fine.

General-purpose "content-addressing" doesn't have ownership

Not really. There is always content ownership, either explicitly or implicitly.

[mplorentz]

This nicely solves the problem of link rot, and there are a lot of fragile links on Nostr right now. I don't see a better way to retroactively solve it for notes that have already been published.

I also want to boil the ocean and support content-addressed media on Nostr, but that seems disjoint from this NIP.

[fiatjaf]

This idea is being revived at hzrd149/blossom#39