Rich rendering of bech32 entities
The npub/nprofile could be rendered as the username with a link to the user profile when nostr:nevent1qqsyxwvgdaacc3hcd9rjwmjwqsfpu8guhrj37026ntl3aqw02mrprsgpp4mhxue69uhkummn9ekx7mqzyr7jprhgeregx7q2j4fgjmjgy0xfm34l63pqvwyf2acsd9q0mynuzp660g9 is implemented.
The nevent of an issue could be rendered as a link to the issue and the text could be the issue title. Similarly for proposals.
The naddr of a repo could be rendered as a repo card with the basic repo data.
Definitely.
Here are some notes on implementation:
The framework for adding rendering of components within event content is currently there.
ndk-svelte-components created a lite adaptation of coracles implementation.
I considered using those components directly but I needed customization of how nip34 event kinds render and wanted more customization of how other events rendered.
I've added TypeScript support to the core of coracles approach whilst removing some coracle specific dependencies.
It currently support new lines, links and images.
I have implemented this for npub and nprofiles in commit 44fb751eca41de2859562a724ac9a567080a75d9.
Still need to do this for events such as note, nevent and naddr.
I had a utopian dream of completely abstracting the UI from the data fetching layers so UX designers could more easily make changes themselves.
Also wanted storybook and the playwright tests to cover all UI components in such a way that they could just pass in the objects needed without fetching data.
I've moved away from that with the above change. although it could be added back in by passing required data (such as each mentioned user's User object to the components/events/EventWrapper.
Something tells me this is more trouble than it is worth. In previous roles that something would be colleagues or someone doing a peer review.
Once you start supporting NIP-19 it becomes a bit tricky. Are you using a local DB? You can still pre-populate it with the events you use in the storybook/tests and don't hit the relays at all. NDK supports caching policies such as NDKSubscriptionCacheUsage.ONLY_CACHE or NDKSubscriptionCacheUsage.CACHE_FIRST that make this relatively easy.
testing previews...
issue kind looks like this: nostr:note143mz8wa4pjxgdywqr0qv04mvwwrvmzun50rkcrxzcfuc00fy7hdqlemquc
patch kind looks like this: nostr:note12ff8f5y6jynx93ud8rywp5a9qgmcgq3s6x622c9s0780rlytnvpqpnrxnh
repo kind looks like this:
nostr:naddr1qq9kw6t5wahhy6mndphhqqg4waehxw309ac82unsd3jhyetvv9ujucm0d5pzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqvzqqqrhnylrpk39
patch kind with multi line commit message: nostr:nevent1qqsrtp7rtws6ftann22wd9w4jvrtnfzwcxuwmnwtnws32x0ju8aptkspp4mhxue69uhkummn9ekx7mqzyzsq3hh327t0h2dq6matqn5064cgj2zanl2stkj6s0lg4t2h5dty68mwzhf
This could be further enhanced by:
1) better previews for other kinds (eg wiki)
2) the ability to open specialised kinds in NIP-89 clients
3) the ability revealing threaded conversations of embedded events
resolved by these two commits:
commit 7dba21cece8b78635d7569627aba95cc20291993 - embedded events
commit ea07b55491e278ea0a4d6e70b5fe436055cad337 - show repo, issue and patch as preview with link to event
These commits haven't been pushed yet, have they? Cuz my ReadMe still looks sorta ugly.
Those commits render links within nostr event contents. Rendering of nostr links in the readme requires intergration with the svelte markdown component. It cannot be eaily bolted on so I'll need to fork or reimplement the markdown component to add supoort. This needs to be done anyway for markdown replies, etc.
now implemented in https://vnext.gitworkshop.dev
