quoting naddr1qv…5rsn

Have you ever seen a relay and out of curiosity visited the https canonical of a relay by swapping out the wss with https? I sure have, and I believe others have too. When I ran https://nostr.sandwich.farm in late ²⁰²²⁄₂₀₂₃, I had thousands of hits to my relay’s https canonical. Since then, I’ve dreamed of improving the look and feel of these generic default landing pages.

With the release of myrelay.page v0.2, relays can now host their own customizable micro-client at their https canonical.

Transform your relay’s landing page from this:

or this:

to something like this:

I say “something like this” because each page is customizable at runtime via the page itself.

In a nutshell

myrelay.page is a self-configuring, Client-Side Rendered (CSR) micro-client specifically built to be hosted at relay canonicals, customizable at runtime via NIP-78. Check out a live example.

Features:

1. Dark or light theme
2. Join relay
3. Relay operator profile and feed
4. Zap relay operator
5. See people you follow who are on the relay
6. Customizable by the relay operator
   • Enable/disable blocks
   • Sort blocks
   • Add HTML blocks
   • Add image blocks
   • Add markdown blocks
   • Add feed blocks, with two layouts (grid/list) and customizable filters.

You can find a full list of features complete and todo here

Why I created myrelay.page

For several different reasons.

Firstly, the default, bland relay pages always seemed like a missed opportunity. I jotted down an idea to build a relay micro-client in early January 2023, but never had the time to start it.

Next, I’ve been ramping up the refactor of nostr.watch and first need to catch up on client-side technologies and validate a few of my ideas. To do this, I have been conducting short research & development projects to prepare and validate ideas before integrating them into an app I intend to support long-term. One of those R&D projects is myrelay.page.

Additionally, I wanted to explore NIP-78 a bit more, a NIP that came into fruition after a conversation I had with @fiatjaf on February 23rd, 2023. It stemmed from the desire to store application-specific data for app customization. I have seen clients use NIP-78, but from what I’ve seen, their implementations are limited and do not demonstrate the full potential of NIP-78. There’s more on NIP-78 towards the end of this article

The convergence of these needs and ideas, in addition to having an itch I needed to scratch, resulted in the creation of myrelay.page.

*Could be wrong, please let me know in the comments if you have examples of nostr clients that utilize NIP-78 for propagating customizations to other visitors.

Editor Flow

Now I’m going to give you a brief example of the Editor Flow on myrelay.page. There’s a lot that isn’t covered here, but I want to be as brief as possible.

Note: myrelay.page is alpha, there are bugs, quality of life issues and things are far from perfect.

Login

Presently, myrelay.page only supports NIP-07 authentication, but other authentication methods will be implemented at a later date.

In order to customize your page, you need to have a valid NIP-11 document that provides a valid hex pubkey value that is the same as the key you use to login.

Click “Edit”

Add a block

For brevity, I’m going to add a markdown block

Configure the block

Add a title to the block and a sentence with markdown syntax.

Publish the configuration

Click publish and confirm the event, once it’s been published to relays the page will refresh.

Note: Again it’s alpha, so the page doesn’t refresh after a few seconds, the publish probably failed. Press publish until it refreshes. Error handling here will improve with time.

Confirm state persistence

After reload, you should see your block persisted. Anyone who visits your page will see your newly configured page. Big caveat: Given the blessing of relays who store your configuration note, if your configuration cannot be found or you cannot connect to your relays, visitors will only see your relay’s NIP-11.

Interested?

myrelay.page is alpha and only has two releases, so if you want to be an early adopter, you’ll need the skillset and patience of an early adopter. That said, as long as you have some basic development and sysadmin skills as well as understand your reverse-proxy of choice, it’s a quick, easy and low-risk side project that can be completed in about 20 minutes.

1. Build

yarn build or npm run build or pnpm run build (note: I had issues with pnpm and cannot guarantee they are resolved!)

2. Deploy

Move the contents of build folder to your relay server (or another server that you can reverse-proxy to from your relay)

3. Update your reverse-proxy configuration

You’ll need to split your relay traffic from the http traffic, this ranges from easy to difficult, depending on your server of choice.

• caddy: By far the easiest, see an example configuration for strfry here (easily adapted by those with experience to other relay software)
• nginx: A little more stubborn, here’s the most recent nginx config I got to work. You’ll need to serve the static site from an internal port (8080 in the aforementioned nginx conf)
• haproxy: Should be easier than nginx or maybe even caddy, haven’t tried yet.
• no reverse-proxy: shrugs

If any of that’s over your head, I’ll be providing detailed guides for various deployment shapes within the next few weeks.

Exploring NIP-78

One of the special things about NIP-78 is that it is application specific, meaning, you don’t need to conform to any existing NIP to make magic happen. Granted there are limits to this, as interoperability reigns supreme on nostr. However, there are many use cases where interoperability is not particularly desirable nor beneficial. It doesn’t change the care needed to craft events, but it does enable a bunch of unique opportunities.

1. A nostr client that is fully configurable and customized by the user.
2. A nostr powered CMS that can be edited entirely on the client-side.
3. Any use case where an application has special functionality or complex data structures that present no benefit in the context of interoperability (since they are “Application Specific”).

Final thoughts

I was surprised at how quickly I was able to get myrelay.page customizable and loading within an acceptable timeframe; NIP-11, the operator’s NIP-65 and the myrelay.page NIP-78 events all need to be fetched before the page is hydrated! While there is much to do around optimization, progressive page-loading, and general functionality, I’m very happy with the outcome of this short side project.

I’ll be shifting my focus over to another micro-app to validate a few concepts, and then on to the next nostr.watch. Rebuilding nostr.watch has been a high-priority item since shortly after Jack lit a flame under nostr in late 2022, but due to personal circumstances in 2023, I was unable to tackle it. Thanks to @opensats I am able to realize my ideas and explore ideas that have been keeping me up at night for a year or more.

Also, if you’re a relay developer and are curious about making it easier for developers to deploy myrelay.page, get in touch.

Next article will likely be about the micro-app I briefly mentioned and nostr.watch. Until then, be well.