I recently wrote about my decision to move completely to the web as an app development platform and some of the tradeoffs involved. My iOS apps are currently free and will disappear from the App Store in a few months.
Despite the web’s challenges, there’s much that excites me about its future and and some of these characteristics are intrinsic to the platform:
The concept of instant games promotes highly shareable apps via a simple link that require no install process: show up and start.
Having multiple payment providers, potentially with the addition of cryptocurrencies means if you wanted to also just invent your own value system, maybe some kind of post-money coupon thing, it’s possible to integrate with existing systems…
User-controlled personal data stores are already being used on the web and will eventually make their way to native apps.
Edge apps that work completely in the browser are easy to mirror or fork, and virtually free to distribute: imagine having your site/app available everywhere via IPFS
The culture of perpetual improvement, with less focus on versioning, is normal: people do not need to ‘install updates’ for each app they use on every change.
It’s just more fun and with a lower barrier to entry, which results in more diverse and dynamic communities who form part of a larger public commons: more sparks, more life, more weird.
Very interesting that in-app purchases (IAP) concepts/problems come up again and again.
no universal ‘buy’ button—every project does this their own way,
lack of an integrated payment system
Having multiple payment providers, potentially with the addition of cryptocurrencies
It’s a problem I’ve been working on for the last little while with my open source https://pay2my.app.
Let Web devs add in-app purchases for US dollars, ethers, and bitcoins (what’s available today, sorry, no Euros).
I’ve been meaning to integrate it with Armadietto for a long time. I see my PR from early 2020 is still the last PR other than dependency bumps. (It’s been a struggle, three little boys, moving countries to pick up a job with the biggest open source contributor in the world, and other distractions).
But anyways, I plan to remedy this in 2022 and make some progress. Just need to finish a howto article for the widgets and then I’ll try and incorporate ledger-based authorizations into Armadietto as a proof of concept.
I’m not sure where this will take us. But I think it’ll be good.
The dream? To position https://pay2my.app as a sort of App Store / Play replacement for PWA and other Web product devs.
The ledger-based authorizations wrapped by those widgets has roots in my own BYOD (Bring Your Own Data) platform (overhide) that I gave up on once ethereum tanked in 2019, I lost some support, and consequently discovered remotestorage.io :)… which took a bit of wind out of my sails… but I’ve been an advocate of remotestorage ever since the pivot… Although I gave up on my own BYOD BaaS, I kept working on the payments bits, and want to make something of them with remotestorage.io in 2022.
Thanks for reading @Jakub_Ner – that’s a pretty impressive project, you went much further than I did. My Fund Button is very simplified (personal data store only + Stripe / PayPal), but currently live in all of my apps. I have some people subscribing that way, but I think there is a bottleneck with relying on personal data stores as most people don’t have them yet (so it’s interesting you incorporate social login).
The social-login is just something familiar I felt I needed to put in… I think it’s somewhat akin to rs.js-widget allowing people to connect with OneDrive, not optimal, but a good way to ease people into remotestorage/0data. It’s what people are used to. Unfortunately the social-login service necessarily uses several centralized couplings/datastores: my service (on AKS), AAD, etc.
What I was really after is the concept of ledger-based authorizations. I believe LBA fits the 0data Web native mold to a ‘t’ (although I’d love to hear you guys’ opinions on that).
In gist, authorizing use of features by checking a public ledger for a sum of payments within a period of time (maybe indefinite) from client to provider.
This is a simple blog post introducing the idea: https://overhide.io/2019/05/02/8yearold.html. It’s a concept from cryptos I appropriated for US dollars (I’ve only got Canadian and European passports, but US dollars felt like the “fiat” currency to go with). The same widgets allow payments in bitcoins and ethers, and whatever we choose to back/support.
So right now I am implementing LBA as a proof-of-concept into Armadietto – fitting it into all the tech already there (Web finger, RS oauth claims, etc.) – for both:
let the host of the remotestorage get paid (+docker == encourage hosting ecosystem?)
let the developer of an app using remotestorage get paid (get all the Web devs out there who want the option of making money with their product to focus on their features using 0data instead of payments integration)
That second one is a bit tangential to what RS is about, but I think it’s important to enable all the Web devs out there… give Firebase a run for their money.
I’m really sorry I let this stagnate since 2019. I just got re-familiarized with my changes to the armadietto/example back in April 2019 and I think I’ve got a plan of action in my head.
This is very interesting! I had also been thinking about how to integrate payments on the RS server side, because the server knows which apps the user is using, so it could split any kind of monthly payments and forward them to app developers.
A couple thoughts on the ideas outlined above:
I don’t think storing permissions on a decentralized ledger is scalable in the long term. For small things like this, only level 2 solutions can make sense in my opinion (after having worked with the tech for a long time now), as there will simply never be enough space on any sufficiently decentralized ledger to be able to hold app permissions, or any data points at all, for most humans.
Furthermore, most of the need for a ledger arises from trying to prevent features being loaded on the client side, which is inherently possible to circumvent, if the app itself is truly unhosted. If the payments would be only on a pay-what-you-want basis, you could forgo the ledger entirely, right?
Personally, I think the ideal decentralized solution would be something like adding a lnurl-pay URL to the app’s Web App Manifest, so that any service or code, both on the user side, as well as provider/server side, can easily send money to the app developer.
However, for the credit card option there can never be a really decentralized/unhosted solution, of course, so the developer always needs some kind of back-end and potentially fiscal host. For that, I think a service like the one described could make a lot of sense.
Thanks for the vid on the “Fund Button”. Very cool! So the app talks to your server which is a proxy to normalize Stripe/PayPal into this “common” JSON? But you don’t actually have a data-store. All state is with Stripe/PayPal?
A quick clarification, with ledger-based authorizations permissions aren’t explicitly stored as data or contracts on the ledgers, they’re implied from confirmed transactions. We just look for transactions from payee to payer within a timeframe of sufficient funds… meeting that is essentially an authorizations claim. I run services for ethers and bitcoin to normalize this info… but these are open source and anyone can stand them up. For USD I run the receipts public ledger (just receipts, value transfer is through Stripe) to make the concept work. For USD the API/data are open, but implementation is in a private repo (for now?).
All these ledgers (and any future crypto ledgers) are abstracted by a simple “remuneration API”… more in this blog post. Which are further abstracted by the ledgers.js library and eventually these widgets… many layers to this onion.
Yes, our, approaches are circumventable in the browser, the open user-agent. The only real way around that is to put critical app business flows into a back-end. That’s OK, that’s just reality. Maybe cloud code in RS in the future?
About fiat and centralization, yup, I’m just looking at it as an onramp to people using in-browser wallets and cryptos. Giving Web devs to use the same flow today for dollars and tomorrow for cryptos.
I see two opportunities with RS for the “Fund Button” or pay2my.app widgets:
paying for storage (payee is whomever hosts RS)
in-app purchases (payee is app developer)
Second one is somewhat tangential to RS, but maybe RS can be a wholistic solution.
I second your sentiment (in the vid) to only prevent writes on expiration/non-payments, but let their data be theirs (reads always OK).
Payments for small amounts are included in what I mean cannot ever fit on a sufficiently decentralized ledger. It’s logically impossible for every node in the network to store everyone’s $5 transactions when you want to scale to large amounts of users. Aside from scaling, it’s also not great for privacy, if everyone’s normal payments are visible to anyone.
We already have some layer 2 networks, like e.g. Lightning Network for bitcoin, where transactions are instant and extremely cheap, because they are p2p and off-chain, and not everyone has to store them on their node. It’s also impossible to see someone’s transactions there from the outside. They are only visible to the payer and payee, and even the nodes that route/forward the payments through the onion network cannot know with certainty who the payer and payee were.
(There are also other layer 2 and 3 solutions being worked on, like e.g. federated Chaumian e-cash mints. But what the higher network layers usually have in common is that they improve privacy in a way that it is not publicly visible who paid whom.)
Sorry if this topic is turning into a blockchain theory discussion.
… in any case, I think @rosano also mentioned before that it would be very desirable for app developers to have a direct relationship with the people who pay them, so I guess keeping some kind of payment information with a user-defined name and/or email address in some back-end, be it hosted by the developer or someone else, would definitely make sense. I merely don’t think the ledger part of the idea is a requirement per se.
desirable for app developers to have a direct relationship with the people who pay them
Oh, I see, hmm, LBA on the other hand is about the devs getting out of the business of knowing the users, yet still be able to provide logins and in-app purchases.
I merely don’t think the ledger part of the idea is a requirement
Got you. It may be that LBA won’t reconcile with the desired direction then, but here’s hoping .
To LBA, authentication is just about a signature from some PKI (lower left of image) and authorization is just some service implementing two very simple APIs (upper right of image)…
GET /get-transactions/{from-address}/{to-address}
POST /is-signature-valid
… I’ve implemented those for dollars, ethers, bitcoins, and, as long as the APIs (or some future variant/iteration) of them can be implemented for currency X (be it private side-chain or whatever the industry invents), it’s easy enough to pull that crypto into ledgers.js, the widgets, and, I was hoping… armadietto :).
So devs leveraging RS gain currency flexibility without having to rewrite their code. They also don’t care who the user is, and, as such, focus on their apps feature value adds and stay away from any PII issues.
Payments for small amounts are included in what I mean cannot ever fit on a sufficiently decentralized ledger. It’s logically impossible for every node in the network to store everyone’s $5 transactions when you want to scale to large amounts of users. Aside from scaling, it’s also not great for privacy, if everyone’s normal payments are visible to anyone.
As per previous message in thread, I think that simple LBA API could abstract private side-chains, whatever the industry converges on.
Might need an iteration on that API surface, maybe a signature challenge or an addressing scheme that targets a specific side chain. As long as it’s possible for a service to get a tally of transactions between two parties, that’s good enough.
This might be good to add in Call for feedback/contributions: PaaS as an adoption strategy – even though the original post is about one-click installs, that might still not be accessible for most people and so it would be nice if local technical people or communities can get instances running and receive payments. I’ve seen Mastodon instances use crowdfunding/patronage platforms like Patreon and Liberapay for voluntary contributions, so at least socially there is some kind of pattern for this.
Interesting. I see how this could be easy with a centralized service, but how would this work when it’s self-hosted? I imagine it being hard for each instance to manually route the money around, so there would need to be payout logic built into the server + integration with payment processors + scraping app pages for their manifest pay id thing?
This sounds similar to the monetization meta tag from the Web Monetization specification.
Thanks for watching. Yes, and yes; the metadata stored on the transaction is the project id, hashed identity, and ‘confirmation code’ (not always necessary, but it can help match transactions to storage accounts).
I don’t have much to add about cryptocurrencies. When I was considering it before, I always imagined using the API of some centralized service so that there’s one simple integration to receive any coins and also for recurring payments: I had these links bookmarked for the latter (some might be broken now):
I feel so strongly about this that I’m deliberating scrapping my Funding button approach and replacing with the Ghost Portal, which can be embedded on sites other than the Ghost domain, but I’m not sure yet if it can persist anything in the 3rd party local storage.
I wrote a little about why I’m trying to avoid this in a comparison of software for sustainable community. My approach might not be appropriate for everyone, but I’ve realized recently that I’m straddling between ‘patronage + community’ and ‘just pay for the thing anonymously’—leaning more into the former makes it more important to have at least an email address in a database, and simply having payment technology won’t be sufficient as there needs to be some kind of ‘home’ for your business relationship with them. I’ll try to write more in-depth about this at some point.
It’s pretty scattered, but the main library is OLSKFund with some wrappers for payment processor are in OLSKTrade. The server-side component is currently tied up in my personal website code, which isn’t public. You can look at the repo for any of my apps for examples of integration, which will also be pretty scattered… The simplest one might be Joybox. This “Integrate fund” commit was an attempt to provide a sense of the integration, but it’s likely incomplete—might be useful though.
Thanks @rosano. Read through the PaaS thread and your response, it all resonates .
My thoughts are still scattered but they’re converging. I’ll try to work out some minimally viable PoC. I was really supposed to put some time into it over the holidays but ended up fixing other code :(… now, being back at work, will take a bit longer.
I’m deliberating scrapping my Funding button
Interesting. I quite like your button. I’ll read the “sustainable community” article next.
.
.