If I had $30,000 a month to spend to hire people for talent, I would. And I'd spend it SOLELY on getting these foundational things going. We need:
- simpler ways to get money without relying on huge systems
- simple portability of one's identity
- flexible means of representing information that's friendly to a lot of tools for social interactions
@jalcine an express app that serves up a stripe One time payment page that runs on glitch should be an afternoon of prototyping.
The hard part is multiuser and subscription support
@zee my thing is making those subscriptions exist _without_ the app (people keep suggesting blockchain and I knee jerk hard against it lol)
but to your point yeah; that's very quick to scaffold and get going
@jalcine I’ll bet we could get a glitch remixable subscription supporting one page app up without too much trouble
@jalcine to be honest tho... you can make subscriptions work without a real app but you’ll need to be on top of it when it comes to canceling transactions and such because it’d be tough exposing the subscription management self service bits without something running on a web accessible device
@zee yeah at MOST I was hoping for it to be a "broker" service that could 'validate' if a merchant and a broker had a transaction and if the history between the two is valid (without touching blockchain BS)
@jalcine I think that’s possible with complimentary protocols. The greet protocol I outlined recently could be expanded to include a validation step whereby the identity host messages the identities contact channels with a unique ID which the user then provides to the broker for validation of identity
@jalcine it gets a bit tougher with a merchant tho. Why shouldn’t the person who wants to get paid be the one who hosts the payment portal? A broker in between a consumer and a merchant feels like a step backwards? Or is it for providing consumer protections of some kind?
@zee hm so I was thinking of it as a way for consumers to pay in a format that they're familiar with and for merchants to collect funds from a normalized place (tbh the more I think about it, the more I see what PayPal does but without holding a bank)
@jalcine the issue there is you have someone holding funds and as soon as you’re holding taking money from someone for someone else you’re taking responsibility for both parties trust.
And that is not a problem that’s solved with code (thought can be made harder or easier with code)
@jalcine it almost feels like what you want is a credit union?
@zee I guess? I think the 'simplest' form of this for me would be some sort of portable but verifiable receipt system for a merchant to verify and for customers to generate
@jalcine ah interesting. Use case is:
User purchases item from service A and is given receipt.
Broker is informed that the transaction happened
User provides receipt to service B
Service B verified that the receipt is valid with the broker and authorizes The user to use the item purchased from Service A on service B?
@zee that's the flow, yup! like if service a and b are related in someway or need to confirm this access to show it to you (like buying a movie from a retailer and wanting to download it at your home client)
@jalcine Dope, I get it now! Took me a while because I was assuming the problem-to-solve was "Person X wants to get money from people without having to use Patreon"
@zee tbh it _is_ but this would be part of the alternative
@jalcine cross-service validation of purchases seems like a pretty difficult to resolve constraint for the happy path of "I want to take money from people from my website" but I can see how it would be super valuable to support in 2~4 years.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!