Why Nostr? What is Njump?
2024-10-09 17:46:50

Vitor Pamplona on Nostr: In the early days of Nostr, developers often competed to see who could implement the ...

This is a long form article, you can read it in https://habla.news/a/naddr1qvzqqqr4gupzq3svyhng9ld8sv44950j957j9vchdktj7cxumsep9mvvjthc2pjuqqxnzdej8q6rswphxuunvdfnyvwa0w

In the early days of Nostr, developers often competed to see who could implement the most NIPs. Although all were optional (except NIP-01), it became a point of pride and vital for the ecosystem’s growth. Back then, there were only a few dozen relatively simple NIPs to implement. Fast forward to today, with nearly 100 NIPs, maintaining and implementing everything has become nearly impossible. Yet, the drive among developers to “code all things Nostr” remains as strong as ever.

fiatjaf (nprofile…c9z9) raised the point that everyone, even I, agrees:

nevent1q…rrrp

But how big is too big? How can we better understand the range of options available for devs out there?

I went out for a hunt in my own brain to figure out how to clarify the situation. I came up with the following 4 categories for Nostr Clients:

  • Super Clients: These apps merge vastly different domains into a single application, offering basic support for reading, writing, configuration, and data management for each use case within each domains. An example would be an app that combines a Marketplace and Live Streams under one roof.

  • Clients: These apps provide comprehensive support for a single domain, handling all its use cases in a single home. They manage the complete set of reading, writing, configuration, and long-term data management within that domain. An example is a marketplace app that helps users manage product catalogs, process orders, collect payments, and handle fulfillment and reports.

  • Mini Clients: These apps focus on read and write functionality for a single use case, including configuration management and any actions related to that specific task. For example, a fulfillment app that helps users view orders placed from another client to then pack and ship them.

  • Micro Clients: These apps have a single interface and perform one specific action. Viewing and creating a record is handled by separate micro apps. An example is an app that simply scans an order’s QR code and marks it as shipped.

Based on my made-up categories described at the end, this is how I would split our most known apps.

Super Clients

Clients

Mini Clients

Micro Clients

Super apps will try to do everything, but can’t really do most things super well. Regular-sized Clients will try to manage most of a given domain but are likely to centralize users on themselves, an unwanted effect inside of Nostr. If we want Nostr to grow in a decentralized fashion, we have to start betting on and using more Mini and Micro clients.

Author Public Key
npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z
Seen on
wss://nos.lolwss://offchain.pubwss://relay.damus.io