We're heading towards Interoperable Communities.
Where every community is a relay, blossom server, ...
NIP-29 is the game changer here.
Outbox becomes a lot less important and complicated in this scenario, though still needed.
Discussion
Yes, we're trying the same thing.
I think normal social media has to end in a monopoly. Only something use-case/community-centered has a chance.
Although the big clients can eventually co-opt that, as well. Or simply take over the operating system with all their stuff preinstalled, like Windows did.
Theoretically, a .doc or .xls file is also an open protocol. Anyone can write or read them, anyone can send them around. But almost everyone writes or reads them with Microsoft products.
That's the beauty of Relays as Communities:
1. You're more likely to be invited/onboarded to a community directly. Avoiding all the biased recommendations Big Clients inevitable make in their onboarding.
2. Big Clients can hardcode Relays all they want, the Community is king and sets the rules. You cannot interact with the Community "on the Big Client's relay" lol 😜. (You can only share/quote/embed stuff from that community to other Relays, which funnels people back to the Community, with their own rules, prices, hosting, ...)
The big clients are fighting the idea of community relays. They prefer you stay on their preferred relays and just use the clients' encryption and interface to separate off.
They and their users start screeching about how that is censorship, completely oblivious to the censorship possibilities of a SuperApp.
It's actually much easier for normal users to assert independence on the business-logic side, than on the client-logic side. By customizing the data set, you could have extremely simple generic clients that anyone could use to make their own customized app. Just need to have a different skin and pull a different query.
We're doing something like this with Alexandria.
Making it very simple, and then branching off a variant to make Biblestr, by changing the stylesheet, domain name, and editing the underlying query to pull only a tagged subset (Bibles).
Someone could do the same with lots of different types of apps, like community apps. Have a wizard that edits a generic app.
That would undermine the SuperApp direction most effectively, I think, by strengthening the creative hand of power users.
I see power users, not devs, as the primary counterweight to SuperApps.
If there even is a "fight" there -- one that I don't really see -- that doesn't matter.
Posting in multiple communities is the most efficient way to solve dozens of problems at the root.
The Apps that embrace that can monetize from day one (with their own community + services of actual scarce stuff).
A Community centered App can only become a SuperApp by:
- integrating the Nostr free market of micro-apps, bots, algo's, ...
- having html-based frames (#hypernotes) in which micro-apps can be displayed + that happen to be supeusful for doing Instagram-like Stories
- being really fucking good at meeting the general needs of a community (awesome chat, great posts-feed, interactive UI for reading/watching/listening to content, ...)
- by letting other apps handle the less community-centric use cases
- playing by the rules of the communities
So in that sense I don't see a real danger in the "SuperApp".
The trend is towards an OS anyway and I don't see people switching OS all the time. Or hardware for that matter 😂 .
We've been in a battle for AUTH, completely customizable relay management, and the establishment of Layer 2 relays, for some time, now.
It runs counter to their business model. As far as I know, only Nostrudel allows for all 3.
Once we get that all through, the battle moves to app and relay wizards and a truly open Nostr OS.
1. What's Layer 2 Relays?
2. What' does AUTH mean on the App-side? (what does Nostrudel allow f.e. ?)
3. I don't see many business models on the App level yet 😹
1) Smart relays, like filter.wine, that work as business-logic "controllers" (in the model-view-controller architecture), wrapped around a model (the custom data set they manage). Nostr is originally designed to only have models (databases, in the form of dumb relays that store anything from anyone) and viewers (clients that contain both business logic and application logic).
Moving the BL to a Layer2 relay takes some of the control of the data from the client and puts it in the hands of the person running that relay, such as a community admin. It also makes the choice of client less important, so long as everyone in the community uses the same Layer2 relay, they could access it from anywhere those events are handled.
2) The client is the one managing the signing of events, so it has to sign the authorization request from relays. That signing function has to be built, and it's difficult.
3) Every product has a business model. If you don't see it, look a level higher. Someone's interests are being served. Who is that person or persons and what are their interests? In what direction is the development trending? Everyone has a strategy to serve some business model.