certainly not, these are just nostr events; there's nothing special being done by wikifreedia at all; it purely interacts with nostr events so you can certainly get the same list of wiki pages in other clients
Discussion
Okay, #njump displays it, at least, but only as json and offers no client to spring to. Not very useful.
But look how nicely nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr has it showing in Nostrudel. Almost an entire Wikiclient.
Okay, nostr:npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr my feature request is.
1) The user can add a wiki address (nostr:naddr) to a readme, and have it display nicely with the title tag (or the "d" tag, if the title is empty), and when someone clicks on it, it opens in wikifreedia.
2) If they add a full wiki address hyperlink, it is displayed the same way, but opens to wherever the link points to.
3) If someone adds a wiki address hyperlink to their metadata "web" array, it is displayed like in 2) and not as a mere hyperlink, so that documentation is always easily recognizable and standard-displayed as a flat "button" in the right-hand panel.
Once nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 gets around to adding wiki coverage, we can use njump.
I'll do it once we have two wiki clients being used by more than 10 people.
there are DOZENS of us
DOZENS!!!

First we need to extended rich rendering of bech32 entities beyond npubs to events. this is tracked in:
nostr:note1rs5shxk8ems0d878tymvntej4zcv4rvg7ntcpac5539xrcvvntss2vqxds
Then we need to enable launching unsupported events in other applications. Perhaps NIP-89 would be better than hardcoding my favorite client (eg wikifreepedia) for each kind?
Your 2) is a good idea. There are some some interesting UX options for when note recommends viewing a nostr event in a particular client by linking directly to it.
I'm not sure about 3). Wont it be clear from the context that it is the wiki landing page for the repository?
PS: I just created a NIP-89 application handler for gitworkshop.dev. nostr:naddr1qqxnzde3xc6rvv3n8qun2v3eqgs2qzx779ted7af5rt04vzw3l2hpzfgtk0a2pw6t2plaz4d2734vngrqsqqql8ky0uzvz
you can recommended for nip34 event kinds here:
glad to see this
yes, I agree that it would be better to use NIP-89 (but I'm biased 😂) than hardcoding wikifreedia (ok, but I'm biased there too haha)
incidentally, can you add a NIP-31 alt tag to your kind:30617 events?
3 is optional. Just thought it would look cool. 😂
Everything else sounds fine, as far as I can understand it.
nostr links within event content are now displayed. There are previews for repos, issue and patches.
I'm now thinking it would be a lot better to display a wiki instead of the ReadMe on the repository homepage.
What do you think nostr:npub1wqfzz2p880wq0tumuae9lfwyhs8uz35xd0kr34zrvrwyh3kvrzusk cqsyn nostr:npub1l5sga6xg72phsz5422ykujprejwud075ggrr3z2hwyrfgr7eylqstegx9z nostr:npub1896p07z8xngpct5ma00mdrad4gqfnwfwdqcl706wrm25ajynahhs27x5ge?
This would require adding support for showing wiki content but that's no bad thing. Showing the ReadMe by querying the server's Web API feels dirty. Different git server implementations use a different API. Its just not a great setup.
this is another good reason:
nostr:note1zlhpa7jnkthezrenxw8efae3dx69550x5xa8qtrtlf05s7snmh7srahcsl
I actually meant this issue:
nostr:note1m5qmedug327a9q6a4nv8ehgg4sjn5gm00nf0nxmqtzyemfnaaypssszx8d
Looks like an option that can be set by maintainers, and default can be wiki or a long note ( readme ). At some point in time some settings will be require for a repository. I prefer local only client only, no server side, and cached if is possible.