yes but I don't think coops in the middle solve this either. they become more useful as they get bigger but that gives them more power and they can always eventually abuse that power. or maybe even just do something that only a quarter of the musicians hate. it can't sustain.
instead imo we need less work on competing systems, more work on protocols/APIs, apps and servers. and then a fuckton of advocacy for decentralized fiat.
I have been thinking about payments on the Fediverse (for a while).
3/
That obviously is not an exhaustive list of archetypes with their wants and pains.
But, I do think we need an extensive list — that we can check any proposed Fediverse payment system against.
.
I have been thinking about payments on the Fediverse (for a while).
2/
For example —
A parent (archetype) may want to send money to their spouse, or give allowance to their child, etc.
Someone working abroad (archetype) may want to send money back home to their family (i.e., remittance).
An SMB (archetype) may want to accept payment for the sale of a product.
A freelancer (archetype) may want to get paid for their irregular income.
Etc.
...
I have been thinking about payments on the Fediverse (for a while).
1/
To make sure a Fediverse payment system is useful we should think in terms of a set Archetypes and each of their wants and a pains.
(Product people often call "Archetypes": Personas. Marketers often call "Archetypes": Segments.)
...
"Nowadays, if I want a book or song, there’s a good chance I can buy it online from the person who makes it, with no third party except the payment processor."
We've technically decentralized media production/consumption and the attention machine. Of course we still need to make these systems easier and greatly increase adoption.
But the money people still have us by the balls. That's really why creators aren't here yet.
The 20th century was owned and operated by middle men. Industry began as the creation of something for which would be traded other goods, services, or cash. As production centralized, distribution (as always) rose to close the distance between the product and the consumer. Facilitating consumption became a business unto itself: printing, shipping, packaging, and all the rest. A respectable, powerful, and necessary business. More recently, when certain products became capable of being distributed without this mighty infrastructure, that business ceased to become necessary, and correspondingly their power and respectability are now in decline. Words and media being the most portable data, the huge industries that have long facilitated their consumption are dying, slowly and poorly. How long before the present titans of technology find themselves in a similar position? It's hard to imagine exactly how it will happen, but the trends are easy enough to extrapolate.
The hash-tag to talk about Fediverse Payments is:
(It also includes transferring things that are non-money, too. Thus the generic name.)
I have been thinking about payments on the Fediverse (for a while).
Another factor to consider is — does a asset flow destination such as:
＠joeblow＠example·com
Eventually resolve to one concrete low-level asset flow address, or multiple?
For example, when I go to a store, they accept loyalty points, cash, credit card, etc.
There are pros and cons for both.
2/
As, software may want to resolve:
flow:joeblow＠example·com/a/b/c?d=e
To:
https;//host·example/some/prefix/a/b/c?d=e
As an intermediary step.
(For example, the low-level asset flow destination address or route could be in an HTTP header, or in the HTML <head> as a <meta /> or <link /> or <script>, etc.)
1/
I have been thinking about payments on the Fediverse (for a while).
If we wanted to come up with a new URI scheme — basically something like acct URI with paths. I think we should also support URL queries, too.
I think it will make (downstream) resolution steps easier.
We'd have to pick a scheme now. For now, I'll just use "flow" for now.
So this:
＠joeblow＠example·com/a/b/c?d=e
Would turn to:
flow:joeblow＠example·com/a/b/c?d=e
As…
4/
So, that suggests we may need to create a new URI scheme for this.
(Of course, I think we would still want a way to make it work with acct URIs, too, as a back-up. But the new URI scheme would be attempted first when trying to do a resolution.)
william ⁂ maggos
@reiver ⊼ (Charles) 