Nostr is great. It’s a technological paradigm shift that will change the way we use the web. I’ve written about what it is and why you should care here:

Social Networks in 2030

Prediction: Social Networks of the 2030s, will be different to Social Networks of the 2020s, and in some ways, will come to slowly resemble the Social Networks of the mid 2000s and early 2010s.

Social 2.0Aleksandar Svetski

But, for all the promise it holds - it’s still very early, and building on or with it comes with a host of technical and UX challenges. This essay is a reflection on our ‘building on Nostr’ journey and a challenge to “Nostr-purity” or “Nostr maximalism.” It’s written by me (a non-developer), so some things may not be 100% technically accurate. Feel free to enlighten me in the comments.

Building on Nostr

From the outset, we chose to be a Nostr-first business. We considered Satlantis a Nostr client (app) and really believed that Nostr would take off in 2024 and the flourishing ecosystem would create tailwinds to drive us forward.

Turns out, the tailwinds never came, and if anything, Nostr became more of an anchor for our product, both technically and in terms of UX. Yes - the ecosystem did grow a little, but the sobering reality is that Nostr is still very much in the early stages.

Nostr is about the long game, and the funny thing is we all know this - it’s a protocol, not an app - but many of us, including myself, Pablo and others really thought 2024 was the ‘lift off’ year. The truth is, we’re still building the foundation. This is going to take time and we have to re-adjust our expectations. Which is fine! I have no problem with that. I’d just prefer being honest about the stage we’re at and adjust the approach to how we build.

Distributed systems come with drawbacks - especially in the early days. They create new designs spaces, but they also come with limitations that are not conducive to how users expect products to function.

A few examples:

1. Nostr allows people to bring their follower list with them. Great. Problem is, every app (client) connects to different relays, showing different follower counts, and often not fetching the same content or notifications. This confuses the hell out of users (bad UX) and worse, forces us to listen to more relays, and build large, convoluted user databases & webs of trust that bloat infrastructure costs.
2. Nostr has a calendar event kind (NIP-52), allowing people to post meetup-like events which any Nostr-client that reads that ‘event’ kind; can display. Two problems here. One is that Nostr events can only be signed by a single key (there are ways to potentially do multi-sig, but the UX is complicated). One result of this is that events cannot have a co-host! When speaking to events managers and meetup organisers, almost ALL required co-hosting as a standard feature. Second; part of the incentive to make calendar events Nostr-native was that other Nostr apps would help increase total activity. Turns out, there are no serious players adding this event kind. So in the end, we took on extra technical debt, and limited the usefulness for the feature, for no benefit.
3. Nostr content is great, but it does not index well on Google - unless it’s been formatted properly. (Try for yourself. The #1 Primal power user is Paul Keating. Search for his name + Nostr and see what comes up in Google). As a result, content posted on our app, and most Nostr apps doesn’t get crawled - at least not directly on site. There are Nostr-apps which transform Nostr content into crawl-able format, but that means the content does not necessarily point to our site. Not great if you’re trying to grow a business. Also very confusing for general users.

There are many more examples, but ultimately, building entirely Nostr-native comes with technical debt, extra complexity, and worst of all, slowness - which the modern app-user is really not going to settle for.

These downsides far outweigh the potential benefits of building purely on Nostr, ie; the potential growth of the network and the interoperability with other serious applications using similar event kinds, etc.

That all being said - there is a way forward. The solution came to me on a flight.

Building with Nostr

If we start with the assumption that Nostr will be around for a long time, and that it will ultimately win, we can also infer that its success will take time to materialise. The compounding effects will be small in the beginning and are only likely to be significant later this decade - or maybe not even until the 2030s.

This is perfectly fine for a protocol, but we as a business cannot wait for that, nor can we afford to handicap our product “for the good of the network.” For Nostr to succeed, the apps being built on it must succeed - and they must do so without depending on grants from Jack, Open Sats, HRF, et al. They need to compete in the free market, which means they need to be real products with real utility.

News flash: what matters to real users is not Nostr, but the product they’re using and more importantly, the problem it’s solving or the service it’s providing. This requires customer-centricity, which in many cases does not mean Nostr native. And that’s ok.

There’s no need to rush. Remember: Nostr isn’t going anywhere. Instead of complicating things for the sake of being purists, we can take a more sensible and practical approach. We can integrate Nostr in stages, as and when it makes sense. Here’s how we’re thinking about it:

• Satlantis-native (Built on our own infrastructure: not an event kind of any sort.)
• Nostr-compatible (Similar to the above, but embeddable in Kind 1’s or similar)
• Nostr-native (a native Nostr-event kind for the specific feature, eg; NIP-52 calendar events)

Not everything has to be in the third bucket. As a business, we can be as Nostr as is practical, depending on the value being delivered to the user, the difficulty of doing it and the distribution benefit (are other apps doing it or are we the only ones?)

Today, for example, Nostr is a great broadcast medium for Kind 1 events. Almost every Nostr app supports it. Instead of us making calendar events native, we could build them ourselves on our infrastructure, but make it super easy to “share to your feed” on Satlantis by embedding them inside a Kind 1 post. In this way, we can:

1. Use Nostr as broadcast medium to increase our user’s potential audience size.
2. Increase the amount of new content being posted on Nostr
3. Give users all the features they want (co-hosts, speed, link your Meetup / Luma / Eventrbite account, etc)
4. Build it faster, easier and with less lag/bugs/issues.

Overall. Good for us, good for the user, and yes, also good for Nostr (even though it’s not 100% optimal).

The same goes for merchant information, reviews, recommendations, galleries, stats, scoring and other aggregated info we have on the site. Instead of making them all native event-kinds, we can build them as our own high-performance features and make sharing to Nostr simple by embedding each into Kind 1 events that are easily broadcast to the entire Nostr network.

Then….

As features gain traction, as Nostr-event kinds become more robust, as more apps spring up that also want to use a certain event-kind, as we mature as a company and have the resources to invest, we can make each of these features more Nostr-native.

The approach doesn’t have to binary. It doesn’t have to be all or nothing. It can be scalar. We can move in the direction of being Nostr-native. There’s no reason to be purists, especially if it hurts the UX.

Ultimately, what’s important is that Satlantis survives and thrives.

That’s the key philosophical & strategic shift we’re making. Satlantis comes first. That’s the product. Nostr is just a tool. If it helps, great. If it hinders, it’s not going to be used.

Final Notes

To the purists who think I’m now a “traitor”, I have two responses:

1. If you’re so adamant that Nostr is everything you say it is, then we can safely assume it will be here 3, 5, 10 years from now. This means when we’re ready as a business - ASSUMING we’ve achieved some level of product market fit - then we can afford to take on the technical debt associated to integrating more fully with Nostr.
2. If you still think I’m wrong then by all means go build it yourself, put your money, time, energy and reputation on the line. It’s a free market and Nostr is available to you too. Maybe I’m too stupid to see what you see, or know what you know.

This year, and the next couple of months will tell us whether this was a good idea or not. I will keep updating this blog as we come across learnings.

Until next time.

Aleksandar Svetski

Thanks for reading Social 2.0! Subscribe for free to receive new posts and support my work.

The mobile app is a couple months out, but you can try out the early web release of Satlantis here.

If you're already on Nostr, you're already on Satlantis. Just use an extension to securely log in with your nsec.