alexmccain6

That’s roughly the direction I’m thinking as well. Bank-to-bank transfers (e-transfers, ACH, SEPA, UPI, etc.) are already legal and widely used for paying businesses directly, without card networks or pooled balances.

The idea isn’t to change that, but to provide a self-hosted, non-custodial orchestration layer around those rails. The software wouldn’t hold funds or act as a counterparty....it would just help merchants initiate and observe transfers using their own bank relationships, with clear settlement and no payout abstraction.

Where things get tricky is cards, which are a very different model. But for bank rails, I agree the legal foundation already exists, and the question is more about how much orchestration you can provide before it’s considered intermediation.

Happy to be corrected if I’m missing something.

That’s a fair point, and I agree with the core issue you’re raising. Anything that takes custody of funds or acts as an intermediary in the US quickly runs into BSA, AML/KYC, and money transmitter requirements, and those exist for good reasons.

The angle I’m exploring isn’t to bypass regulation, but whether a non-custodial, self-hosted orchestration layer can exist that never holds funds and only works on rails that already support direct settlement. The model is closer to paying a shop directly than paying through an intermediary....the software is never a counterparty, never pools funds, and the regulated entities remain the banks or processors on both ends.

In a US scenario, the idea would be that the merchant runs the software themselves, and onboarding doesn’t abstract compliance away but explicitly guides them through what they need in place to legally accept payments, linking out to the appropriate providers and only working once those are set up. My question is whether, in your view, that meaningfully changes the regulatory posture, or if simply being part of the payment initiation path still makes MSB treatment unavoidable.

Appreciate you calling this out....it’s exactly the constraint I’m trying to understand.

RubyUI looks interesting, but I wonder how well it scales in large apps. Moving away from ERB makes sense for maintainability, but does it introduce any trade-offs in terms of memory usage or debugging? Would love to hear from people using it in production.

This looks cool, but does anyone know how they handle uploaded photos? Many AI image tools store or use inputs for training. If privacy isn’t a focus, your face could end up in unexpected places.

One of the most striking aspects of air pollution is how invisible yet pervasive its effects are. Unlike more immediate environmental disasters, air pollution slowly chips away at public health, reducing life expectancy and quality of life, often without dramatic headlines. The comparison to starvation as a "frailty multiplier" is an interesting one; pollution doesn’t always kill directly but makes people more susceptible to fatal conditions.

Regarding the reduction in SO₂ emissions from shipping fuel, I’d love to see more discussion on how international regulatory pressure (e.g., IMO 2020) managed to enforce compliance in an industry notorious for cost-cutting. Was it simply a case of the alternatives being feasible enough, or did global coordination and monitoring play a stronger role than usual?

This is a really cool app! Does it work with images too, like diagrams from a book?

A small suggestion from my end. You could add a search option for users to search the name of the person they want to look up