Nostr Web Client

Purplepag.es has had a massive revamp overnight.

As part of its mission for 2026 the board of relay directors has approved expanding business to the broader category of "lists".

When purplepag.es started, the Board choose to focus on 10002 events, for relay discovery, answering the question "where shall I find my homies' relays?"

Since then, many other relay-lists came out: DM relays, search relays, wiki relays, etc.

So, let it be known, that from this day forward, purplepag.es accepts all 1xxxx kinds.

In addition to the current kind 0 (profiles) and kind 3 (follow lists), obviously.

Also, it actively crawls for newer data from people's relays; for example, if you publish a new profile or a new follow list only to your relays, it will get it.

And, one more thing: negentropy.

Apps can quickly retrieve all the events they need for their local operations and serve things in the nostr way: local-first.

What does this mean for you?

You will also have more reliable access to finding people's latest profiles, follow lists and relay lists, but that goes without saying.

If you are a developer, purplepag.es now will give a lot more data, and way more up-to-date, particularly from pubkeys that are followed, data will tend to be very fresh.

SondreB 2w ago

The board of directors in my head would like to share their thoughts on this and why these "indexer relays" should not store anything other than 10002 (and 3 until network has migrated).

1. "indexer relays" / "discovery relays" should be analogous to DNS servers. You ask for the "IP" (domain) of the servers (relays), and you go there to look up any content.

2. Adding more events to "indexer relays", means increased amount of resource requirements. When considering global scale, this becomes a bigger and bigger problem.

3. Data (events) has a much higher chance of becoming stale and fragmented the more it is distributed.

4. Indexer relays should be in-sync as much as possible, so someone in Australia can use "indexer A" and someone in Brazil can use "indexer B", and both of them will be able to resolve someone in Croatia who uses "indexer C".

Each Nostr client should simply use one of two indexer relays to discover where to find the events of any user, including their DM relay list.

All apps need to do, is 1 query for the 10002 or 3 kind of the user, if found, it can go and query for their DM relays, their profiles, etc. on their own preferred relays. It gets data from the "source", not from some distributed "cache" storage which purple pages will become.

I don't think purple pages should store profiles either, just look at the recent example with Damus. They built a new web app to view profiles, it rendered my months old profile with invalid payment address and there was no way I could make it update (they fixed it, had a refresh bug).

Nostria hosts multiple indexer relays (call them Discovery Relays), they only do 10002 and 3 and will never do profiles, nor DM relays, etc.

Any use case built with your specific set of extended limited events also means it will put more pressure on your infrastructure, without others, including nostr:nprofile1qqsdr0fnxvmn8hxyz8cwazfm8zu9yt7qmc38ll69nkvsgn8dnej4sxckxm0xe any ability to offload your demands. Right now, we have Coracle, Purplepages and Nostria (globally regionally deployed).

To help Nostr scale to global scale, our board of directors firmly believe this is the direction for the future. Thanks 💜

Reply to this note

Please Login to reply.

Discussion

No replies yet.