I like how Signal is available as an SMS app on Android. Even though it doesn't help privacy over SMS it helps adoption, which then pushes more people into the privacy preserving part of the app. This should be done with keychat if there's no compromises on the number one goal of perfect privacy.
I'm more of a fan of cashu than fedi, but listening to a podcast about the "superapp" concept of fedi got me thinking. The "mods" concept and the open source of the superapp by Jan 3, 2025 could be an opportunity. If you convert the superapp to a "protocol" that apps can plug into, it could become indeed super.
Create hardware that only needs to have data, and runs the app. Then for messaging, "mods" plug in your favorite messaging app (keychat?), then if the CEO gets arrested, you switch messaging apps to your next favorite, and competition wins.
You plug in your favorite payment app (self hosted cashu.me wallet), and if a better one comes along, switch.
Phone, maps, all plug in. Everything that plugs in has the ability to receive payments seamlessly from whatever standard-compliant payment app the user has plugged in, so from the company perspective, they don't need to program and pay for a "payment processor," they just plug in to the protocol.
With standards on this "protocol" we can have seamless, privacy-preserving competition for the best UIs with no "ecosystem lock-in".
We feel that Fedi is in an awkward position, caught between Cashu and self-hosted Lightning Network wallets.
An app could be built from various protocols, each handling different functions. For instance, in Keychat, the nostr protocol could handle ID and relay duties, while the Signal protocol takes care of encryption. Cashu would manage the stamping function, creating an app where the user retains control.
nostr login should be the standard. All apps and websites hopefully cave eventually to this reality.
Your example of cashu manages the stamping demonstrates my idea. Your app needs a monetary layer, and it would already be built in. You don't need to "support" cashu, you just need a standard plugin. If the user uses Fedi, your stamp is paid and the message is sent. A sat is a sat.
You would be able to divert dev resources away from all the changes to the cashu protocol, and just maintain the payment protocol standard. It would free the user to select something they like better. There are users who would not use your product *because* you chose cashu.
Down the road, if fedi "wins out" and cashu becomes marginalized, you would have to do some restructuring.
I like standards and modularization. Its freedom increasing.
Fedi sats as message stamps are far inferior to Cashu sats because they are more complex. We speculate that users will prefer to store larger amounts of sats in self-hosted Lightning Network wallets rather than in Fedi. Once users have accumulated enough Cashu sats, they can open a Lightning Network channel.
I agree that cashu is better, and a good choice for your use case.
And maybe cashu would be the "standard" payment processor in my super app, for the reasons you stated.
Self-custodial lightning is ideal for the spending wallet. Cashu solves the uncle jim, the offline, and the not enough sats to justify the fees problems.
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed