An intriguing concept. Thanks for posting @richardhroth1 and welcome to the AP community 
Let me start by mentioning some payment-related protocols and softwares:
- GNU Taler: P rovide a payment system that makes privacy-friendly online transactions fast and easy.
- WebMonetization: JS browser API that allows the creation of a payment stream from the user agent to the website.
- Hyptis: Provides distributed small-world finance systems, appropriate for use in games or for communities such as your neighborhood mutual aid network.
The Web Monetization stuff is currently currently being evaluated in combination with cryptocurrencies / blockchain technology (off-topic: in which I have NO interest for various reasons, until maybe in some years the technology matures). Note that the specification is blockchain-independent, and is being proposed as a W3C standard. (I’ve seen discussion on Hacker News about native browser support). Hyptis by @cwebber is very interesting as it is very close to standard technology being researched and developed that will become available to the Fediverse.
Now about the idea…
Small is Beautiful
I think the combination of Local Community and Public Banking concepts in some form or other is a great and inspiring idea. You mention “It does not replace the existing social media, but it severely disrupts them”. Here I think KISS (‘Keep It Small and Simple’) and not target a disruptive web-wide technology from the start.
“Small is Beautiful” is the title of a book by economist E.F. Schumacher, published in 1973 and sub-titled “A Study of Economics As If People Mattered”. And as it happens - independently of that - Aral Balkan and Laura Kalbag have adopted this slogan for their Small Technology Foundation.
I think a good way to elaborate this idea is to follow a SmallTech (and related: Small Web) approach to the technical implementation and document and/or develop protocols & ‘business domain’ in parallel (which may become this disruptive thing later on).
So what does this mean in light of PonyXPS and PonyUPS?
- No handling of millions / billions of transactions and trying to rival FB.
- Pony services are scoped to a single Community.
- Like Communities, Pony services may federate to other services.
(Note: I mention “federation” here, but a future distributred Fediverse will probably be a hybrid of federation and peer-to-peer)
Community concepts
A Community Land Trust serves a real-world (physical and local) community, and that is great. I love the concept, and I think local community support in all kinds of ways modelled like that is a requirement to fight off hypercapitalism and plutocratic tendencies that continue to erode our social fabric and true connections between people.
Besides physical the community might also be online-only for netizens (e.g. a global audience). In any case software support and a digital representation of the community are needed to manage things. This is where PonyUPS / PonyXPS can build on top of another #fediversity:fediverse-futures topic, namely:
The concept of Sociocracy mentioned there to model the community organization may be very interesting, even if the particular patterns in this library are not a direct fit (maybe too formal with e.g. double linking etc.). They can be extended with custom patterns that match specific needs.
Business domain
What is it in domain-driven design terminology that Pony services provide on top of the Community domain? Is it a Micropayments domain extension? Are there multiple business domains involved? I think the latter is the case here. We just need to define them clearly and can then elaborate them each in their own Bounded Context.
So there are some business domains that need to be developed / implemented to provide Pony to the community.
Because each community has different purposes there will be potentially many other domains that are modelled on top of or interact with the Community domain. And also with the community’s Pony services. There are interesting ways that payment transactions can be modelled in interactions with other domains.
Example: Sustainable FOSS development
Take for instance a FOSS community, where there may be interaction on the basis of Federated development and federated forges (@anon20068248 is working on this). What interactions can lead to payments being made? Well… so many possibilities.
- A Push to a Repository represent time + effort spent by a Contributor and a Like of the push may lead to payment.
- A Ticket representing a RFC may be upvoted with a Like to collect budget as a bounty for the Contributor.
- A CI build, fork, download, dependency inclusion, code review (outcome), etcetera… all candidates for payment.
As part of the Pony domain there may be a concept of Payment Schemes to model all of this, and reuse as templates. There’s many interesting ideas to follow-up on in this idea.
- Federation goes beyond community boundaries: anyone that uses the software is encouraged to pony up.
- Money goes to Contributors, and this need not be one-time payments, but may be continual revenue streams.
- Part of the money is split flowing partially into the budget of the Project itself (e.g. into an OpenCollective)
Key benefits
I think here the aforementioned Small is Beautiful approach already pays off, and you are defining the Key Benefits of the Pony services in the wrong way. Privacy-and-security-first approach to software development is a best-practice and should be a mandatory requirement (especially for this fin-tech use case). @Sebastian mentions how Spritely OcapPub fits in here.
With the Pony services bound to the Community, being a member of the community means you get privacy and security as intrinsic qualities. It raises your trust in the community and makes it more likely you’ll participate actively. Personal privacy with common people is often not motivation enough to adopt a technology, as you rightfully say. But here being part of the community and the value it provides is the motivator.
People join a community for a common cause. They are way more likely to be willing to contribute financially to the community (incentive to pony up) and its members that are similarly aligned. So 1 cent goes to the non-profit that upholds the community, and 1 cent goes to the member-contributor of value within the community (this might be for content they provide, but also for other services e.g. time / effort they spent).
By scoping Pony to the Community you also assure that payments align with community Terms of Services / community theme / moderation policies. Without the community scope you might see money flowing to things you do not agree with, and be less inclined to pony up.
Governance
You mentioned Public Banking, a nice concept, and @how mentioned we should not into common pitfalls as the payment card industry did. I mentioned Community Trust, and also OpenCollective in the distributed forge example.
With Pony service attached to your Community and real money involved, there must be a form of Governance that guarantees Trust is maintained. It should be Privacy-respecting, but also ensure sufficient Transparency about money flows and how budgets are spent.
I really like OpenCollective in that regard, in terms of the underlying ideas implemented in the service. What I like less about them is that they are VC-funded and the rather high rates they charge for payments. Also they are a SaaS (though you can self-host) which is less (or rather not-at-all) fitting to the SmallTech principles.
In the case of Community-bound Pony services, only a single-tenant version of OpenCollective-like financial governance is needed.