Live data from Hacker News

Griffin – A fully-regulated, API-driven bank, with Clojure

juxt.pro

181–190 of 223 posts

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#181
post #154
post #135

Is there EU alternative? I mean bank that has API that looks like it was made in the 21st century? Except Wise and Revolut.

In the Netherlands there is bunq, with a proper API just like Griffin is implementing right now. Been around for years!

that's not for me. something else?

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#182
post #71

> The problem right now is that there’s no way to control the behavior of the underlying Java threading libraries, nio, and writing to disk. Nor will there ever be, just by the nature of those systems. You can't get deterministic execution from a system that uses non-deterministic request ordering, task scheduling, etc. -- which is what you get if you always use multiple OS threads, or spawn multiple discrete process…

It is a tall order, but but it's doable. The most important thing is to reduce the surface area of your application. Our business logic is almost entirely pure. The 'procs' have no side effects, except for things that happen on the other side of a clojure protocol (java interface). That means all side effects can be stubbed out during tests. Our "user" code has no access to threading libraries. Threading happens in "…

AFAICT you're describing exactly what I mean when I say a fully synchronous system.

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#183
post #29

It's pretty cool to see that the two founders wrote a book together: "Learning ClojureScript" https://www.packtpub.com/product/learning-clojurescript/9781...

I see that the third author of the book was Allen Rohner. I worked with him at Compass Labs, an incredibly talented developer! He also founded CircleCI.

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#184

Earlier quoted context omitted.

Yes, let's just give in completely then and give them the ability to freeze any funds they want. That's definitely the logical approach. I gave up with privacy because I can't stay 100% anonymous online against a motivated adversary so now I just install government spyware with root access so they can watch me all the time and control my user accounts!

One can be anti-extrajudicial government powers and anti-cryptocurrency. For one, I believe cryptocurrencies will be the government spyware of the future that allows for total control over our finances, since crypto evangelists push “code is law” and the blockchain is immutable and completely transparent. There will be no privacy in such a system. We could spend our efforts making the current financial system be priv…

As I said in an earlier tweet, private transactions are possible

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#185

Earlier quoted context omitted.

I take part of my income in Bitcoin and spend it, both on-chain and Lightning Network, pretty frequently. I visit a number of local places that accept Bitcoin and use it for online purchases too. There are several Bitcoin ATMs in my city but they mostly have KYC with low limits and/or high fees. For purchases like cars or real estate it seems like you'd have to be pretty lucky to find a seller unless you're not parti…

why not buy Bitcoin, transfer it to destination country and sell it there for cash?

This is really what I was asking too

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#187

Why are these API banks always in the UK? I've been waiting to do my banking using curl for years and no one has made it available in the US.

U.S. banking is surprisingly far behind the curve, and hasn’t led the world from a tech or innovation perspective for many decades. The UK on the other hand has actively encouraged new banks and new tech. It’s had things like instant, free, payments between personal accounts for almost two decades. Contactless transactions for at least a decade, mobile banking for decades, and government mandated banking API for almo…

Not sure if anyone else can comment on prevalent software in banking. But it seems like IBM’s FTM is fairly prevalent. The underlying technology from a glance seems dated (Java 8, bunch of uncontainerized shell scripts running the show) and highly proprietary in the bad ways. E.g the proprietary stack hasn’t seen innovation. Add to that, the same teams deploying this software.

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#188

Earlier quoted context omitted.

Yes, let's just give in completely then and give them the ability to freeze any funds they want. That's definitely the logical approach. I gave up with privacy because I can't stay 100% anonymous online against a motivated adversary so now I just install government spyware with root access so they can watch me all the time and control my user accounts!

One can be anti-extrajudicial government powers and anti-cryptocurrency. For one, I believe cryptocurrencies will be the government spyware of the future that allows for total control over our finances, since crypto evangelists push “code is law” and the blockchain is immutable and completely transparent. There will be no privacy in such a system. We could spend our efforts making the current financial system be priv…

> One can be anti-extrajudicial government powers and anti-cryptocurrency.

The trouble is the current system has failed to provide both of those at once, because of the incentive structure. The government wants the intermediary to try to prevent fraud or crimethink or what have you so they don't punish the intermediary for making mistakes, so the intermediary makes lots of mistakes and tramples over innocent people without enough power to push back.

In other words, it's much harder to have a non-abusive intermediary than to remove the intermediary.

> For one, I believe cryptocurrencies will be the government spyware of the future that allows for total control over our finances, since crypto evangelists push “code is law” and the blockchain is immutable and completely transparent.

This is true of Bitcoin to an extent but there are at least two ways to avoid this.

One, you can have a blockchain that doesn't work like that but still doesn't subject you to the whims of an intermediary, e.g. Monero.

Two, a blockchain like Bitcoin is completely transparent, but it also doesn't tie your name to your wallet or limit you to a single wallet, so in principle you can use a separate wallet for separate activities without any way for someone with only access to the blockchain to correlate them. Apps could make this easier to automate.

You could also just use a third party payment processor which is only using cryptocurrency for settlement between payment processors, so the individual transactions aren't being recorded on the blockchain. But then you don't have to, which is important to give the user leverage over the intermediaries, and make it easy to switch because anyone who accepts Bitcoin accepts Bitcoin regardless of whether or which intermediary is used to send or receive it.

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#189
post #170

Serious question, and I apologize for the strong language: why should I give a shit about the language a service I consume is written in? Why does it matter it’s in Clojure? I am professionally a Clojure dev so it’s cool to see something written in Clojure like this, but why should I care about that? This is one of the things I really dislike about the community. Yes, Clojure is a powerful language, and I really enjo…

This is a blog post by one Clojure company, interviewing another Clojure company, with a tech stack focus. It’s not unusual within any language stack to have these kinds of blog posts - they’re obviously by and for people who find the technology interesting.

I don’t get your point. Is this somehow not appropriate behavior amongst civilized society?

Your remark comes across as not a little bit ignorant. Maybe you should just learn that if you “don’t give a shit”, you also don’t have to engage, and let the author write whatever they want.

Re: Griffin – A fully-regulated, API-driven bank, with Clojure

#190
post #71

> The problem right now is that there’s no way to control the behavior of the underlying Java threading libraries, nio, and writing to disk. Nor will there ever be, just by the nature of those systems. You can't get deterministic execution from a system that uses non-deterministic request ordering, task scheduling, etc. -- which is what you get if you always use multiple OS threads, or spawn multiple discrete process…

never say never, i think maybe can be done with modifications to missionary, a structured concurrency dsl implementing process supervision for clojure/script. we already instrument missionary flows for testing missionary itself (asserting its state transitions)

I guess you're suggesting that you can build an abstraction layer (I guess you're calling it missionary) which (a) can reliably intermediate every interaction between a user program and any potentially non-deterministic API, and (b) can be configured at runtime as synchronous/serial/deterministic or async/concurrent/non-deterministic. Is this accurate? (If so, I'm pretty confident that this is infeasible.)
Post reply on HN