I love the idea of URLs with nostr entities and inline relay hints.
This type of URL syntax also models nostr architecture very well. Instead of specifying a host location and then the desired resource like most URLs, we specify the desired resource, and then the host locations where that could be found, which is exactly the architectural paradigm shift that defines Nostr
We probably want to double-check RFC 3986 to help define some of the details.
For example, we probably want to use “nostr:” instead of “nostr://“ because the “//“ denotes an “authority” (Section 3.2) that controls the namespace of the remainder of the URL, which would not be the case since the protocol would define the meaning of the query parameters.
Furthermore, I am not sure if we can repeat keys on the query parameters, and if it would be compatible with most URL parsing libraries. Section 3.4 of the spec doesn’t seem to forbid it, but might be good to test with major libraries. If not, maybe comma separated values on the relay hints could work as well
cc hzrd149 (npub1ye5…knpr) I think this type of URL syntax would work well on Blossom too
danieldaquino / Daniel D’Aquino
npub13v…zl3l8
2024-11-19 19:07:46
in reply to nevent1q…pzhj
Author Public Key
npub13v47pg9dxjq96an8jfev9znhm0k7ntwtlh9y335paj9kyjsjpznqzzl3l8Published at
2024-11-19 19:07:46Event JSON
{
"id": "f12bfb2877cc4b5dd08065a640bf2cca5a92f24eaf0e90504170ad0f85f330af",
"pubkey": "8b2be0a0ad34805d76679272c28a77dbede9adcbfdca48c681ec8b624a1208a6",
"created_at": 1732043266,
"kind": 1,
"tags": [
[
"e",
"ac0ca4127014f8e55209b6b8d0069318f7b5dbbcc022b97c161d10876ccb2376",
"wss://nos.lol/",
"root"
],
[
"e",
"35af2d35b4dec4c8a8f76157b0366626a605fdc9fcc6e46896c1de2c027a9432",
"",
"reply"
],
[
"p",
"460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c"
],
[
"p",
"7fa56f5d6962ab1e3cd424e758c3002b8665f7b0d8dcee9fe9e288d7751ac194"
],
[
"p",
"3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d"
],
[
"p",
"17538dc2a62769d09443f18c37cbe358fab5bbf981173542aa7c5ff171ed77c4"
],
[
"p",
"06b7819d7f1c7f5472118266ed7bca8785dceae09e36ea3a4af665c6d1d8327c"
],
[
"p",
"32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245"
],
[
"p",
"266815e0c9210dfa324c6cba3573b14bee49da4209a9456f9484e5106cd408a5"
]
],
"content": "I love the idea of URLs with nostr entities and inline relay hints.\n\nThis type of URL syntax also models nostr architecture very well. Instead of specifying a host location and then the desired resource like most URLs, we specify the desired resource, and then the host locations where that could be found, which is exactly the architectural paradigm shift that defines Nostr\n\nWe probably want to double-check RFC 3986 to help define some of the details.\n\nFor example, we probably want to use “nostr:” instead of “nostr://“ because the “//“ denotes an “authority” (Section 3.2) that controls the namespace of the remainder of the URL, which would not be the case since the protocol would define the meaning of the query parameters.\n\nFurthermore, I am not sure if we can repeat keys on the query parameters, and if it would be compatible with most URL parsing libraries. Section 3.4 of the spec doesn’t seem to forbid it, but might be good to test with major libraries. If not, maybe comma separated values on the relay hints could work as well\n\ncc nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr I think this type of URL syntax would work well on Blossom too",
"sig": "91db5b89f06e47593fdf9916259d48f8c6ff451836d37d97111604ec79ff91a85a0d7b0785e8d8eb53c02de89491e528ce2c228cb6e4aed2f5b4824e477f34b1"
}