This is interesting for Alex, too, nostr:npub1wqfzz2p880wq0tumuae9lfwyhs8uz35xd0kr34zrvrwyh3kvrzuskcqsyn . Then we don't have to define badges. We can pull directly from the domain.
nostr:npub1l5sga6xg72phsz5422ykujprejwud075ggrr3z2hwyrfgr7eylqstegx9z i know you done an all nighter but i fixed that favicon thing in the lerproxy
the code you wrote was trying to serve it from the #orly but it needed to be adjacent to the nostr.json handling in the reverse proxy. i have added a default icon based on the owl pic and if you put favicon.ico in the same directory as the nostr.json from the mapping.txt configuration, it will serve that instead.
as you can see on my #jumble notes i now have an ORLY owl instead of a check badge
Discussion
currently it only has favicon.ico, the spec includes a range of other formats... they can be supported for larger displays of the thing... i just did the favicon on a guess that was the thing it was requesting
Could do the one from the relay NIP and fall back to favicon. Increases likelihood to find some relevant icon someplace.
yeah, i figured that was the logic behind why you put the handler in orly, no, the nip-05 is in the reverse proxy, you pretty much are not gonna be running orly without it btw.
but yeah, i guess it would make sense to serve the icon set from the relay as well. the standard in NIP-11 doesn't stipulate format, basically you can put jpg or webp or png in there. but it's just the relay, not the nip-05
in theory, you could bundle it all into one thing, but i'd rather keep them separated, personally. i usually need go vanity redirects and static file hosting as well and that's already in lerproxy
Nip-11 captures the icon for relay subdomains. The 21 icon is from nostr1.com, but theforest.nostr1.com actually has a picture of trees.
yeah, i figured that nostr:npub10npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qzztl5h had used some common type of reverse proxy that puts them on the domains by default, probably for his web app.
and yeah, probably the web server that has the 21 icon is the one that does the nip-05s
it's tied to the nip-05 in jumble so it is simplest to just add it to the handler for the nip-05
It's because so far, I have been able to avoid storing user uploaded images. Everything in relay tools is image links. The reasoning for that is to avoid cloud lock-in and image synchronization or processing within the cluster. (each frontend would need a copy of these user uploaded images once you go down this path).
favicons kindof breaks this, ... more likely i would just pick a better icon than the 21. like a checkmark, because self hosting is king, and anything making that more complicated is not ideal.
and i pushed hard to get rid of favicons displays in all clients for relays for this reason, and now that i realize what jumble is doing, i'll probably try to push against that as well.. tho with relays i did not have to change nip11 i just had to get clients to use it. with this, it would probably need nip05 to have it. favicon fallback, sure thats fine. anyway, the price we pay for a tiny little image eh? 🕊️