Follow

Who's working on transactions in the fediverse? I keep seeing ACTUAL signs of people preparing to leave platforms like Patreon and the company getting ready to shake off lots of people.

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

Portable identities will let us to dangerously amazing things. Using one identity we can pick to sign into multiple places with. A lot of faith in the people signing in, not going to lie.

I know this will ruffle feathers but I do think Fortress's mobile client will collect identifiable information (with PERMISSION) for sign ins. I'll use that to make spoofing a lot harder. It'll make sense when I release the mobile client's code.

I know these are hard problems. I don't expect them to be solved overnight. I do want to discuss VIABLE solutions (re: something working in 3 - 6 months) and accessible to people with just a laptop and/or phone.

@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"

@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.

@zee @jalcine Could this be solved with some variation of public/private key exchange? Basically handing certificates to the recipient?

@jalcine Ultimately I don’t think the technology is the problem. I think social expectations around how “easy” means “I don’t have to interact at all” and how “software engineering” means some gatekeepy bullshit

@zee This is a big part of it. I'm still wondering how it can be simple to want to own some part of one's identity on their actual person (like if their phone or home computers had the things needed to prove that they can use X)

bad answer, but currently the truth 

re: bad answer, but currently the truth 

re: bad answer, but currently the truth 

re: bad answer, but currently the truth 

re: bad answer, but currently the truth 

bad answer, but currently the truth 

@jalcine GNU Taler is almost this. It's not part of the fediverse and is still fairly early in development, but it would act as an exceptional base for a fediverse-based payment system once it's functional.

And also considering Taler could have huge benefits beyond the fediverse, I think if you're going to contribute to any transaction project it should be Taler.

@OTheB Yup yup! It's the closest thing (or tbh, what I modeled my ideology around).

@zee def check out GNU Taler (it's still early) docs.taler.net/

Sign in to participate in the conversation
Social @ PV

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!