I've been going deep into the "app store" rabbit hole lately. Here are my current thoughts on how nostr could improve the experience for both users and developers.
Sharing it here to gauge... are these problems worth fixing? What am I missing?
There are four angles from which I want to discuss this topic: discoverability, security, reputation and monetization.
The app store model, a curated catalog of applications, addresses these in various ways and is by far the most common distribution method.
Google Play Store and Apple App Store lead the pack with around 95% market share outside of China. Along with other Android stores (Amazon Store, Samsung Galaxy Store) and the Microsoft Store, they are the major proprietary, closed-source stores. They control every link in the distribution chain.
Open source stores work a bit differently. The store UI can manage apps from multiple repositories. For the most part, though, they are used with the default one: F-Droid (Android) with their official repo, Snap (Ubuntu Linux) with Snapcraft, Flatpak (Linux) with Flathub.
App stores are the only realistic method to distribute applications to humans at scale, but current implementations have important shortfalls. They are all, in varying degrees, trusted third parties offering convenience at the expense of sovereignty in different ways.

Discoverability

High-quality search, trending lists, and recommendations are important factors for app discovery.
The main stores are tightly integrated with their respective operating systems so they are the users default go-to. This creates a strong incentive for developers to publish there, and this results in a rich app ecosystem.
But centralization has its problems. The algorithms of these stores may prioritize promoting content, displaying ads or making it difficult to discover niche apps. They regularly censor due to state regulations and corporate agendas. (Or just for some random reason).
The iOS App Store is the most problematic of all. There are no alternative ways of installing apps other than going through tedious hoops. The recent third-party app store changes in the EU is a complete larp: "marketplaces" must still get permission from Apple and only a single version of an app across different stores is allowed.
Open stores do not censor and anyone can add their own repository, but this extra step also hurts discoverability.
One can of course find apps outside the realm of an app store, for instance from links shared in social media. (I'll further discuss the direct download approach in the Security section.)
Furthermore, major stores are split in countries/regions due to legal or regulatory requirements, so apps available in one area may be invisible in another. Enabling localized content may improve discoverability because of the increased cultural relevance.
An app store on nostr, on the other hand, could leverage (borderless) social connections which is way more relevant than a geographic silo. Discovering new apps could become more like getting personalized recommendations from your friends as opposed to browsing a generic list created by minions at a faceless corporation.
Other handy features such as NIP-51 could bring curated app lists to one-click bulk install (à la Ninite), both as personal backup or as recommendations.

Security

Here I'd like to talk about a few key aspects separately.
  • Transmission security: Checking file integrity via digital signatures to prevent tampering
  • Application security: Scanning packages for malware and enforcing OS-level runtime security
  • Privacy: Preventing private information or metadata leakage

Transmission security

Apple and Google prevent in-transit attacks through public key infrastructure (PKI). They provide developers with signing certificates, in addition to controlling app store front-ends, domains and file servers.
On Android, signing keys are pinned upon first installation and are enforced on all subsequent updates, along with a mechanism for key rotation. This is the SSH model, also known as TOFU (Trust On First Use).
While it's possible to add custom repositories, F-Droid builds from source tarballs, hosts and self-signs all but a few packages in their official repo. This has an important downside: you now need to trust them not only on the initial install but on every single update. F-Droid does not build non-free software and has a host of other issues.
IzzyOnDroid is probably the most popular F-Droid alternative repository, focused on providing a curated list of APKs excluded from F-Droid official. The main difference between these repos is that Izzy hosts APKs signed by developers.
Obtainium is closer to the Izzy approach. It offers no curation but removes one trust layer as packages can be fetched directly from developers' source repositories. Signature verification is not yet implemented so for now you need to fully trust the host (mostly Github run on Microsoft infrastructure). AppVerifier is the proposed integration: a step in the good direction but yet another centralized solution relying on certificate hashes rather than developer signatures.
It is common, especially among open-source developers, to use PGP to ensure artifact integrity, preventing attacks such as phishing, domain hijacking or malicious repositories.
PGP relies on a web of trust to verify the authenticity of signatures. It's a good idea but far from perfect in practice, as it's very challenging to determine trust levels transitively. There is no purely technical solution to the problem of trust, but some choices in the design and implementation of PGP make it even harder.
I'm a developer and regularly get software in this way. I still find it challenging. Obviously obtaining a hash or fingerprint sitting next to the binary makes no sense, so I usually pull keys from one or two (supposedly) reputable keyservers that match some known developer's fingerprint. Fingerprints are not the full PGP key. While it's probably okay, keyservers must be trusted and there have been reports of malicious actors duplicating short key IDs in the wild.
The optimization of security at the expense of user experience leads most users to choose insecure tools over secure ones, so PGP unfortunately did not reach any significant level of adoption.
Keybase was a very interesting attempt to improve this situation by mapping users' social identities to PGP encryption keys. Their focus was scattered (messaging, file sharing, etc) and then the team was aqui-hired by Zoom in 2020. Development seems to have virtually stalled ever since.
Could nostr's web of trust be the missing ingredient in the secure transmission of packages?
Nobody uses PGP encrypted email anymore, everybody moved to Signal or SimpleX. And no sane person will undertake the massive effort to build a web of trust from the ground up just to verify a few downloads a year.
But if a socially active network of cryptographic keypairs happens to exist, all of a sudden utility massively increases and the effort of building a network of trusted developers goes down. Since trust is a problem of social nature, there is no better way than deriving it from a naturally social context. Keybase got the idea right, but Nostr is uniquely positioned to solve this problem. Even your mom can now cryptographically verify a downloaded app.
Let's imagine that Craig Raw's nsec was compromised. Once aware, he could use NIP-41 to perform a key rotation and make the fact public to his nostr social graph. This action would occur relatively fast, circumventing the need for updating key servers and waiting for global synchronization (which might never happen). In PGP, a single breach can affect entire branches of the web of trust tree, potentially causing widespread damage with very delayed detection.
Indexing packages for discoverability vastly improves UX and can be performed by any network participant since these are merely suggestions and packages are always signed and verified.

Application security

Both the Apple App Store and Google Play Store have their own procedures for reviewing apps before they become available to users. They involve human and automated processes and aim to ensure app quality, security, and compliance with their policies.
This approach is not foolproof though, some malicious apps can still slip through the cracks and when it does, it's pretty bad.
Worse yet, they give the illusion of security.
These Big Tech-backed proprietary walled gardens pose additional security risks due to their opaque nature. Corporations are the low-hanging regulatory targets in a world of ever-increasing state surveillance. Never forget, trusted third parties are security holes.
Open stores appear to be more transparent but still require users to place significant trust in them. F-Droid official repo builds from source tarballs so you need to trust the developer, F-Droid and the transmission of data between them.
Something similar happens with Flathub, which in addition hosts binaries packaged by third parties, yet another layer of trust, as these community-run projects lack resources. (Guess what fixes this?)
And just like with direct downloads, you also need to trust binaries like an APK to correspond to the source files, unless they use reproducible builds like Signal does.
In terms of malware and privacy protection, Android's PlayProtect checks APKs when installed from non-Google Play sources. Open stores provide scanning via tools like VirusTotal, Exodus Privacy and Blacklight but the user can't really pick and choose.
On Nostr, a market of DVMs specialized in app security auditing could arise, as a reputation mechanism for developers, as tools for end users, or both.
Once apps are installed, privacy and security become an operating system level concern. Sandboxed execution and varying degrees of permission controls to filesystem, peripherals, network, and so on are used to mitigate further security issues. An app that does not use the Internet should not be granted access to it.
Firewalls like Little Snitch or OpenSnitch for Linux are examples of third-party software that is crucial for maintaining security and privacy.
Craig Raw is a developer that I trust, but after configuring Sparrow to work completely offline (node in my LAN, disabled mempool fee estimation, etc) I was surprised to find an HTTP request to sparrowwallet.com with OpenSnitch - which I immediately denied. Is Craig rugging my hot wallet? I went straight to the source code. Turns out it was a simple version upgrade check. So yes, these tools aid us immensely in our strive to verify not trust.

Privacy

All app stores know the exact set of programs you use. Apple and Google in particular have a double incentive to harvest this data: on the one hand to produce accurate recommendations, and on the other to sell it to data brokers.
Privacy would be significantly improved by making direct downloads easier to verify by anyone, incentivizing the use of privacy-respecting FOSS and switching to trusted DVMs for recommendations and security audits.

Reputation

Even if an app is perfectly safe, is it worth your time or money?
App stores allow users to review the apps they use. This has its limitations as ratings/reviews can be easily gamed in these centralized systems.
Having a decentralized review system can actually... make it worse. Spam and Sybil attacks are relatively cheap, unless the view of the network can be trusted. And that is exactly where nostr comes in.
NIP-32 reviews constrained to a pubkey's web of trust would be the perfect fit.
This type of information is not only useful for other users, it also serves as a feedback mechanism for developers. Many of them derive value exclusively from reputation.
But there is a better way.

Monetization

Options for charging money are available on the main stores, but the bullies want their cut. Apple and Google take hefty 15 to 30% commissions on sales and charge developers additional fixed fees.
Virtually all users and developers need to be KYC'd as they are only allowed to pay by digital fiat means and are forced to use archaic SMS verification. Apart from the privacy concerns, this excludes billions of unbanked users from buying paid apps and unbanked developers from even publishing them in these stores.
Interestingly, it also marginalizes autonomous AI systems that were tasked to publish an app.
A vast majority of the applications published on big stores are free (as in free beer) with a huge percentage of them relying on advertising, exacerbating the attention problem.
Open stores offer no monetization options, other than a donate button at best. FOSS developers usually resort to frictional and unreliable donation solutions.
A lot has been written about the issues with open source funding. I can't reach other conclusion than: Bitcoin and Nostr fix this.
Removing the middleman and letting users pay developers directly via zaps, Nostr Wallet Connect or other similar primitives will fundamentally change the way apps are funded and distributed.
It doesn't have to be like this.

Support

This is an innovative feature given no app store has introduced post-sales support, likely due to misaligned incentives. It's the real, genuine KYC!
Embracing the removal of middlemen between users and developers can open up new possibilities like paid support, bounties, feature request prioritization, and even new business opportunities.

Moving forward

In the longer term, AI could drive a cambrian explosion of software creation.
Massive improvements to efficiency tend to also cause qualitative changes. The dynamics of app distribution might look totally different than today, we might be remixing our own apps like we do with music on stemstr, and sending back value to all contributors.
App discovery mechanisms will require more fine tuning, and review systems to be more trustworthy than they are today.
Scams and malware will multiply, dangerous software will slip through the cracks of centralized stores due to the sheer volume of submissions and the complexity of detecting all potential threats.
Finally, with so much supply and demand from so many different parts of the globe, an open, borderless, neutral medium of exchange is the logical answer to monetization.
Apps are fundamental tools in our quest for self-sovereignity. Draconian regulations and privacy invasive practices will accelerate. Properly establishing trust, sourcing and verifying apps will become more important than ever.
Most nostr usage at the moment is for social commenting (certainly not as network of package maintainers) but there will be an increasing overlap between the two.
Can trust scores emerge from webs of trust and other primitives?
Can NIP-94 replace manifest files?
How do we minimize trust while maximizing UX?
What else would be necessary to disrupt the ~95% big tech market share?
As an app developer myself, I had only superficially been exposed to these issues. App distribution is a fascinating rabbit hole I recently fell into and I started prototyping the solution I want to see in the world.
A lot of questions remain. I don't have all the answers, or even the right questions, but I feel there are enough gaps and shortcomings in the current way things are. And significant room for improvement.
534 sats \ 1 reply \ @0fje0 29 Jan
One of the most informative posts I've seen on SN. Full of rabbit holes.
And I appreciate that OP doesn't claim to have all the answers:
A lot of questions remain. I don't have all the answers, or even the right questions, but I feel there are enough gaps and shortcomings in the current way things are. And significant room for improvement.
Highly recommended reading!
reply
Thank you!
reply
We think of the bitcoin protocol as a transfer of value layer that goes on top of the Internet. As something added to the internet. What if we look at this the other way around: Bitcoin is the foundational layer, and the Internet gets (re)built on top of Bitcoin. Imagine for example the SMTP protocol getting rebuilt in such a way that email requires a sat or two to send each one. No issue for the vast majority of us who send/receive a few hundred emails or less a day. But this stops spammers cold.
HTTPS on bitcoin, visiting a website costs a sat or two. Again, for the vast majority, not an issue. But for spiders and bots scooping up content, there will be a cost.
In a similar way, App Stores can be designed from the ground up with Bitcoin baked in. A great outcome would be to take back our attention from advertisers stealing our time but instead zap the developers micropayments for using their software.
reply
Love this way of looking at it.
My goal is to maximize the signal between users and developers. Lots of noise with the current models.
reply
"Bitcoin is not money for the Internet, it's the Internet of money." —Aantonop
reply
100 percent. "Money is just the first app." --Aantonop
reply
312 sats \ 2 replies \ @kr 29 Jan
great post.
one thing i am curious about is how much you think app stores should earn for their services.
many people claim a 15-30% cut is too much, but basically everyone stops there instead of offering a better payment structure.
to get out of this loop, a new payment structure needs to not only work for the app creators, but also the app stores (ideally without blocking competition).
reply
Appreciate your comment Kevin, I'm actively exploring this topic.
Answers are not immediately evident when building open source software on an open protocol. I don't think the model of the future app store is taking a cut on sales, but providing ancillary services to users and developers. I found quite a few so far.
reply
177 sats \ 0 replies \ @kr 29 Jan
awesome, excited to hear what you learn!
reply
227 sats \ 1 reply \ @freetx 29 Jan
Great write-up!
On Nostr, a market of DVMs specialized in app security auditing could arise, as a reputation mechanism for developers, as tools for end users, or both.
Yes. I think the 'killer feature' for curation is security analysis / protection.
I would probably rate Apples efforts as B+ and Google Play Store as C- . However, they both fail because of their censorship bent.
For me, I'd be willing to pay a small fee for a curated appstore (free from political censorship), where as you suggest, the app store provider gave some sort of certification regarding the privacy implications of the apps.
Ideally the curator should run the apps in a simulator and provide a report: "is this app trying to make network connections....is source code avail....are the builds reproducible.. is it scanning the local network....does the binary have signatures that match known tracking software" etc.
Something like this could fit well within the nostr ecosystem as users could have direct feedback and direct discussion regarding these results. Competing App Curators could chime in and describe why Curator A's approach was flawed, etc....all in all this would improve security immensely as app developers saw their apps were going to be so scrutinized. As it stands now, most app developers do the bare minimum and often receive very little direct pushback of the security flaws in their model.
reply
The idea is to leverage the web of trust for security and curation, so there's no "one size fits all" authoritative approach like all the current app store models - it's all weighted by who you follow/trust. Having curators is not a requirement.
That said you are right in that curation could remain important piece of the puzzle. Many people don't have the time or expertise to judge a developer or a result of a malware analysis DVM. So what I mentioned about NIP-51 lists could be even bigger than I thought.
reply
Great idea. The Nostr is the open negotiation layer of the internet and this is a great example usage.
reply
Well said, and thanks!
reply
The Google App store in Android is horrible these days. It's full of ads, everywhere.
Literally they show a different app right next to the one you're planning to install, and a lot more around it. It's all ads these days.
f-droid on the other hand offers you a nice list of apps.
The bad thing about f-droid is discovery. It's hard to find an app if you don't exactly the name of the app that you're looking for.
There are no reviews on f-droid, which I think is a good thing. It could be implemented in a different app or website.
reply
Agreed. I detest Google App Store and the slick positioning of "sponsored" apps, often with a deceptively similar name and logo, sitting above the one you specifically searched. It's bait and switch and people will download and install the wrong app which will lead to far ranging negative consequences.
Tried to quickly find a relevant example, this one is less egregious than some I have seen that are pure deception, but the point holds:
reply
🎯 exactly what I'm trying to fix!
reply
142 sats \ 1 reply \ @siggy47 29 Jan
Great analysis. There's a lot here to absorb.
reply
Thank you!
reply
This topic cannot be discussed without mentioning file sizes. The infrastructure probably isn't robust enough for this. But I could see it being built with references to torrents magnet links or Usenet.
Hopefully someone who's smarter than me in coding will build this one day.
reply
The beauty of this approach is that it doesn't require additional hosting infrastructure. Files can live anywhere, including torrents; relays store small events with signed metadata (NIP-94).
reply
231 sats \ 1 reply \ @anon 29 Jan
Let's kill the idea of a centralized catalog made by anyone. Just publish your app to Nostr, like with https://nostrapp.link/, and that's it.
With no catalog, there is no way to "review" apps (which gives control and liabilities to the reviewer), request, or enforce the removal of apps the powerful simply don't like.
reply
I'm not suggesting a centralized catalog of any kind, in case that was not clear. Also, this is not a collection of nostr apps, it's any app.
It is possible to review apps in a decentralized manner. A NIP-32 review on a NIP-94 metadata included in a NIP-51 list is the nostr approach to review an app in a curated list.
reply
Excellent post!
Have you tried Spring yet? Does this seem on the right track?
reply
Thank you!
Spring is great, but it's a catalog of nostr apps only (and a signer).
I have some cool ideas around PWAs that I'll be sharing soon
reply
121 sats \ 1 reply \ @Nuttall 30 Jan
I'm glad that you've mentioned Keybase. Keynes's really was good except for the Stella creep which actually got me into Bitcoin for keeps.
Once Zoom bought it, it was over acc is sad. To be honest, I think Lightning would have saved it but it is what it is.
Just today I happened to see how a Nosta.me profile tool recommended apps once you put in your private key via Alby. It showed recommendations via https://nostrapp.!ink which made me realize that nostr was much more powerful than I realized.
reply
I messed up the link so the above is correct.
reply
What's the TL;DR of this post?
reply
94 sats \ 0 replies \ @nout 29 Jan
You can copy paste it into chatgpt to get tldr.
reply
there was a bot for that
reply