NIP-AD: Nostr Web Addresses#2406
Conversation
|
Insanely cool! |
|
I'm assuming |
|
No, if relays don't exist use "relay.damus.io". |
|
Very interesting. What are you working on that inspired this? In a client like Ditto, I suppose I would fetch every URL I see in any event, and potentially "enrich" the way it's displayed. |
| 2. [NIP-5A](5A.md) nsites: `nsites.com/something` resolves to an nsite event. | ||
| 3. Hosted feeds: servers can create feeds using whatever algorithm they want and publish those simply as a `{"ids": [...]}` filter, or something else. | ||
| 4. People that have websites and blogs fueled by Nostr content can have those sites exist both natively inside Nostr and to people living outside. This also works for `https://njump.me/nevent1...` or client-specific URLs like `https://yakihonne.com/nevent1...`. | ||
| 5. This fixes pasted links: when a user pastes a URL on a Nostr client the client can preemptively try to resolve that URL into an event and make a native reference instead. |
There was a problem hiding this comment.
Implementers should be considerate of the usecase: "your client shows it like that? Look how my client shows it: https://webclient.xyz/nevent1..."
People should still have the option to click the original link and not have it completely replaced by something else. Of course it depends on the type of client and type of link.
I don't think any wording needs to be changed, just wanted to note it.
|
|
||
| Such URLs, when pasted on a Nostr client, can be turned into a single event (specially when the filter has `"limit": 1`) or a list of events, and handled accordingly. When used in a normal web browser it can just render HTML like any normal web URL. | ||
|
|
||
| To get the Nostr counterpart of any URL, call that URL's domain at path `https://<domain>/.well-known/nostr.json?ad=<original-path>` and look for a key with the desired path in the resulting object. That should contain an object with `{"filter": {<any-nostr-filter>}, "relays": [<relay-to-use>, ...]}`. `"relays"` is optional. If it doesn't exist the `kind:10002` "write" relays of the authors in the filter should be used. |
There was a problem hiding this comment.
There's slight ambiguity in what <original-path> should be. Clients should probably drop any hash but include any query string. Servers should percent decode so a URL like this still works:
https://golf.com/.well-known/nostr.json?ad=%2Fplayers
and this:
https://golf.com/.well-known/nostr.json?ad=%2Fplayers%3Fplayer%3DMario%26player%3DLuigi
There was a problem hiding this comment.
No, let's drop query strings entirely. They are super annoying.
|
|
||
| Such URLs, when pasted on a Nostr client, can be turned into a single event (specially when the filter has `"limit": 1`) or a list of events, and handled accordingly. When used in a normal web browser it can just render HTML like any normal web URL. | ||
|
|
||
| To get the Nostr counterpart of any URL, call that URL's domain at path `https://<domain>/.well-known/nostr.json?ad=<original-path>` and look for a key with the desired path in the resulting object. That should contain an object with `{"filter": {<any-nostr-filter>}, "relays": [<relay-to-use>, ...]}`. `"relays"` is optional. If it doesn't exist the `kind:10002` "write" relays of the authors in the filter should be used. |
There was a problem hiding this comment.
Using ad as the parameter is slightly bothersome. Why am I thinking about the resurrection of Christ while I'm implementing Nostr URL resolution? NIP-05 doesn't say nostr.json?05= it says nostr.json?name=. So I would think nostr.json?url= or nostr.json?path=
There was a problem hiding this comment.
It's not about Christ; @fiatjaf wants to sell us ads, obviously
There was a problem hiding this comment.
Everything is arbitrary, but I'm fine with ?path=.
|
Instead of |
Too late, I used relay.nostr.band but it doesn't work; I'll try again tomorrow |
Why? It can be whatever url you wanted to be |
Just so that a client won't need to request Though I'm not sure if the idea is good, cause there are benefits to not using |
This is good too, but I really think doing that preemptively before publishing the event (of course it has to be done by the publisher) is the most important thing, otherwise events will be full of broken links in the near future, instead of what could have been static Nostr references. |
My main motivation was the NIP-29 groups use case, but its scope got a little bit overblown and then @pablof7z's suggestion on the other PR made it even bigger. |
|
I am very afraid this will cause people to abuse URLs too much and tie Nostr to the broken DNS game, but I'm hoping for the best. |
I think the opposite, readers can parse and display whatever they want, but publishers should not re-write users' intent. We had this same debate a long time ago when people proposed doing this to any link that included an |
So you think it is better for Nostr if people start filling events with dead links? That's a hard thing to defend. I'm not advocating for rewriting of user intent, just a nudge into the correct direction (which in 99% of the cases is what the users want anyway). Clients already suggest you to fill the note with a |
|
Both are true |
5 participants
The successor to #2393.
Read here.