A decidedly non-Linux distro walkthrough: Haiku R1/beta2 - <AUTHOR> https://arstechnica.com/gadgets/2020/06/a-decidedly-non-linux-distro-walkthrough-haiku-r1-beta2/ <comment><USER2> (Haiku developer here.)

This review misses or misstates some pretty key details about Haiku:

* The statement that "Haiku's design diverges radically enough from modern standards to make application porting very difficult" is just plain false. Haiku is extremely POSIX compliant and we have ports of Qt (as you may have noticed from Otter), etc.

The reason there is no Firefox or Chromium is not due to any technical limitation of the OS itself, but purely because none of us devs know a lot about those codebases (which are larger than Haiku itself!) and want to put the time in. We would be happy to help others port them.

* The "OS crash" on YouTube is not really an OS crash but rather a window manager / display server crash, which is much more recoverable than an actual kernel panic. Yeah, we probably should have caught that one before the release, but somehow we did not...

* It's also not the case that we do not support "any USB network interfaces whatsoever"; as the screenshot you have shows, we don't support _USB WiFi_ adapters. We do support USB ECM ethernet dongles, USB Pegasus, and at least some USB ASIX ones.

<comment><USER3> Yeah, harping on the browser situation seems a bit unfair. Chromium is phenomenally complex, almost an operating system unto itself. It's not like porting a text editor.

[https://www.chromium.org/developers/design- documents/display...](https://www.chromium.org/developers/design- documents/displaying-a-web-page-in-chrome)

<comment><USER4> Yes, and then there's Emacs…

<comment><USER5> Actually, Emacs would probably be easier to port, given that a large chunk of it is implemented in Emacs Lisp.

<comment><USER6> GNU Emacs contains over a quarter million lines of C.

<comment><USER5> Right, compared to the 4.8 million lines of C++ in Chromium...

</comment></comment></comment></comment></comment></comment><comment><USER7> Jims review on Ars was a bit unfair, considering the enormous difference in man power involved with the Haiku community and the commercial support most other OS's have - there is a factor of at least x1000. Yet Haiku is brave enough to tackle an integrated system of its own. For instance, Web+ is a beta browser purposely built to target only Haiku, whose primary goal is to use native features. It would have been easier to port Firefox, there even was a port 15 years ago when it was still called Mozilla. But it was sluggish then, and a more native solution was suggested.

Although Web+ is young, thorny and buggy (now), with every iteration it gets better, more stable, and faster. And the core OS functionality benefits with improvements other apps can utilise. For instance, lots of blending modes were added to AppServer to support web standards, so every native app gets these features as well. The net classes improved, media streaming improved. The article mentions a crash with YouTube by a refactored memory paging off-by-one error, which has been fixed 3 weeks ago, and this bug fix benefits all apps. All software has bugs, they get fixed eventually.

There are benefits to Haiku which most casual observers don't register in their brief sessions. It requires a bit more "miles" before the benefits are discovered. It's a young system with potential. It's a beta of R1. There will be more revisions in the future, more iterations, more quality.

Unlike the __nix distros which are an amalgamation of various independant components with duplicate integration channels, Haiku is building a tailored unified system. The end benefit will be noticeable in component integration and efficiency, which the heterogeneous __nix systems will struggle to match. Haiku is targetting the front end user, not the invisible back end.

<comment><USER8> > Jims review on Ars was a bit unfair, considering the enormous difference in > man power involved with the Haiku community and the commercial support most > other OS's have

I get that context matters, but if you're going to write a review about a desktop operating system, you should be comparing it to the other desktop OSes that are available so that readers have a point of reference.

> It's a young system with potential. It's a beta of R1.

To be fair, it's taken almost twenty years to get to the R1 beta. I've been following its development on and off since the demise of BeOS. I remember reading about all of the in-fighting from the early days of OpenBeOS, so I'm glad that they've made all the progress they have.

What they've produced is indeed admirable, but you can't ignore the fact that the technology world is in a very different place since they started this project.

When I look at Haiku today, it is like opening up a time capsule of a late 90's era operating systems.

Even when I had BeOS, I still had to dual boot with Windows due to the lack of broad application support. So as a somewhat interested observer/follower of the OS's development since the project began -- once I get past that feeling of nostalgia -- it's even hard for me to see the potential that you talking about.

<comment><USER9> Well, a more interesting review would address not only what doesn't work well and what you can't really use it for; but also what you can use it for.

In other words, yes, it's fair to say "don't use this for surfing the web or if you have an EVOO laptap". But ideally you would then suggest what you _could_ use it for and how it works in those areas. I would have expected at least to understand the state of desktop productivity software, music playing, networking, hacking, playing games, printing, etc.

And given that a lot of readers (unlike yourself) will never have used BeOS or be that familiar with it, what's it like? If you read an email and someone sends you a PDF, do you save it and open it in a PDF reader? Does something else happen? Is any of it interesting in some way?

<comment><USER8> "Web surfing" might seem easy to dismiss, but look at the original iPhone. Sure, it had a nice form factor, etc., but the thing that made the iPhone a game changer was mobile Safari, a modern web browser. Remember when Apple's response to "hey there are no apps" was to use "web apps"?

Well, I tend to consider the bare minimum for any desktop OS to be viable is the ability to run a modern web browser (which would let you do your email, desktop productivity, music playing, games and PDF viewing).

Hell, I'd even go so far as to say that Haiku's next major milestone should be to get Firefox or Chromium to run on it. With a working modern browser, all of a sudden it's at least as functional as a Chromebook. Which means you might actually be able to use the OS as a daily driver in spite of its other shortcomings.

<comment><USER10> > With a working modern browser, all of a sudden it's at least as functional > as a Chromebook. Which means you might actually be able to use the OS as a > daily driver in spite of its other shortcomings.

I find it sad that the sentiment is that a computer without a modern web browser is not useful for daily work. And also that those browsers are massively complex and can only be practically developed by entrenched corporations with stable revenue streams.

What's frightening is that soon this might actually become true, if it wasn't before.

And at the same time I see Web+ and wonder when it will ever be standards compliant, much less stable, given the size of the team behind it.

</comment></comment></comment></comment></comment><comment><USER11> I remember first reading about BeOS and the BeBox in some 1994-or-thereabouts edition of WIRED (which featured an interview with Jean-Louis Gassee).

I was utterly amazed by the screenshots of the GUI and the thought of a computer with "parallel processors". The slogan "one processor per person is not enough" absolutely smote me and I was hooked. BeOS looked like everything nineties non-dismal utopianistic science fiction looked like and the BeBox with its dual RISC CPUs and "blinkenlights" on the front to display workload and a "GeekPort" on the back for attaching random hardware were at the very least very exotic machines with a lot of presence and that made quite a statement.

At the time I also had my first interactions with NeXTStep, and I'm pleased how things went (overall) but back at the time, it seemed like "not choosing Plan Be" was going to have disastrous consequences. How wrong I was...

<comment><USER8> > it seemed like "not choosing Plan Be" was going to have disastrous > consequences

Can you even imagine what that alternate reality would be like?

Given how Be did not come with Steve Jobs, the entire tech landscape could have been very different, and Apple may not be the powerhouse that it is today.

</comment></comment><comment><USER12> The mistake here is probably to consider HaikuOS from a linux perspective. This OS is especially interesting because it's designed only for desktop computers (not servers, not phones, not toasters) with fully integrated components to develop native applications (Application Kit, Game Kit, Media Kit, ...).

</comment><comment><USER13> Is it really a distro? Surely a distro is a collection of tools, applications, and a kernel that form an operating system.

Haiku is a single project operating system, so when they make a release it's not a distribution as such, is it?

We wouldn't call Windows 10 a Windows distro.

<comment><USER14> Oh how I wish there were Windows distros

<comment><USER15> ReactOS[1]?

[1] [https://reactos.org/](https://reactos.org/)

</comment></comment></comment><comment><USER16> I like the BeOS interface in that it has a nice feel of polish and integration similar to MacOS.

Also it doesn't pretend your computer is a tablet. Even MacOS succumbed to that trend with version 11. In 10 years someone in Silicon Valley is going to rediscover classic mouse UI and sell it as something new and advances.

</comment><comment><USER17> "Why doesn't the tilde key work properly?

The tilde ~ key is a dead key, used to type characters like ñ."

</comment><comment><USER18> Haiku is beautiful. I wish it gained more traction (so I could run it on bare metal and use it for all my daily tasks once) without changing its look-and- feel.

Can I download the Qt theme by the way? I want to style my KDE system like Haiku.

<comment><USER2> Nope, you can't, because the Qt theme actually uses Haiku's native control- drawing APIs under the hood, just like the Qt Windows theme uses.

</comment></comment><comment><USER19> > Much like TempleOS, it's not very directly useful

I thought this part of the review was a bit over the top. The author seems to conflate "useful to me" with "useful to anyone" throughout. And in service of such a position, some very black and white conclusions are reached.

Where utility is concerned, we live in a world where bullet journaling on paper is still very popular and also a relatively recent development. It's not exactly the same experience as your brand new tablet may offer, but it's not expected to be. Similarly, in my experience, Haiku was very directly useful, but I didn't go into the experience expecting to surf the Ars website or watch videos on YouTube. I used Haiku on a netbook, and it was a terrific, appropriate, and even tranquil, environment for writing, organizing, planning, and reading.

In short, I found that Haiku was useful and desirable for getting away--and this includes getting away from the exact conditions the author of this review was trying to equate with a minimum bar for a personal standard of utility.

</comment><comment><USER20> > The next browser we tried, Otter, did a better job with Ars—but Otter failed > to render video in either YouTube or Vimeo.

That's a smidge surprising, since Otter on Haiku x86-64 (on my laptop) does indeed render at least YouTube videos fine (I'm playing "Pamela" by Toto on it right now), albeit not as performantly as I'd have hoped (long time to load, and some stuttering at the start of every video).

</comment><comment><USER21> The comparison with TempleOS was a real low blow and it makes me wonder if the reviewer is being entirely serious or just sees all operating systems not immediately useful to him to be a total waste of time.

</comment><comment><USER22> I used Beos way back in 2001 as my main OS. Compared to linux it was more stable and used less resources. Great to se it still exists.</comment>


What's Better Than 40 GPU-Based Computers? A Computer with 40 GPUs - <AUTHOR> https://spectrum.ieee.org/tech-talk/semiconductors/processors/whats-better-than-40-gpubased-servers-a-server-with-40-gpus <comment><USER2> I think our current trend to more heterogeneous compute units is really going to highlight the value of benchmarks. How many people are really doing TFlops of matrix multiply?

I've always been wary of the idea of building extra ordinarily complicated hardware and rely on the software people to figure it out. It doesn't seem to work. It's too many degrees of freedom. Compilers are great at taking complex problems and fitting them to fixed solutions. Anything more is like handing off an NP-hard problem.

<comment><USER3> Strong disagree. How is reality even remotely close to what your comment predicts? Only 40 years ago we thought one processor will be enough for all compute tasks, then we learned how to make software for bunch of CPUs, then we realized there are things that benefit from bunch of weaker cores and wrote software for that, then we realized you don't even need a single computer and you can parallelize your program to N computers with M processors.

Your argument fails because it assumes everything is automate-able. It's not. Programming is not automate-able, at least not now. If you wait your C compiler to generate code that will run in L computers with N to M threading model you're gonna wait too long. This is what we software engineers are paid for. And it _does_ seem to work, as explained above.

<comment><USER4> > Only 40 years ago we thought one processor will be enough for all compute > tasks, then we learned how to make software for bunch of CPUs, then we > realized there are things that benefit from bunch of weaker cores and wrote > software for that, then we realized you don't even need a single computer > and you can parallelize your program to N computers with M processors.

No, the history of parallel computing is a lot more chaotic than that!

Parallel, distributed or vector computing graphics have been around since the early days and there are many fancy parallel processors architectures that never did well _exactly_ because no ones knew how to program them. The Tera architecture (128 threads) comes to mind[1]. The Cell that was used in the playstation 3. It has 1 general purpose core and 8 accelerators that were vastly underexploited by game developers. The greatly anticipated Intel Larrabee (32 cores) never made it to the market. And even today the fate of the Xeon Phi (about 60 cores) remains very uncertain.

In 2019 parallel computing is reserved to the same restricted set of easy to parallelize applications than 40 years ago (numerical simulations, 3D rendering, database servers and maybe few others) + deep learning. But most software is sequential, and most people would not notice if they had 1 or 2 cores instead of 8 or 16. That's because writing parallel programs is inherently and debugging is hell.

[1] [https://en.wikipedia.org/wiki/Cray_MTA](https://en.wikipedia.org/wiki/Cray_MTA)

</comment></comment></comment><comment><USER5> not really. better to spread those devices over mulitple domains, unless you have a crossbar switchbus that can handle terabytes/sec

</comment><comment><USER6> Isn't one of the limiting factors with putting everything on a single silicon wafer is the massive increase in defects the more surface area you use? Otherwise you could build an entire supercomputer on those enormous foot-wide wafers

Edit: Nevermind, fixing that is the point of the article; I should stop skimming these things

<comment><USER7> It seems like that's the problem they solved. In effect, the wafer is just an interconnect. The GPUs are manufactured normally, but this technology is basically "just" a wafer-scale interconnect. (Kinda like how Vega chips from AMD have a silicon interposer to connect the HBM2 dies with the GPU. Except this interconnect is a whole freaking wafer.)

The problem they now have is the heat that is emitted from such a beastly contraption.

> Edit: Nevermind, fixing that is the point of the article; I should stop > skimming these things

The only reason why I'm in a better boat than you is because I had followed a discussion over at Reddit on this very story already. Mistakes when reading articles are pretty common, and don't worry about it. Anyone who gives you much trouble over that is just asking for Karma to smite them. Most of us are here to help each other understand the story.

<comment><USER8> > The GPUs are manufactured normally, but this technology is basically "just" > a wafer-scale interconnect.

I wonder if this is something like Intel's Foveros 3D chip stacking, where the wafer is treated more like a "PCB" (with the traces and such for signals/power) to the CPU chips bonded on top?

Basically, a "PCB" made from silicon, where the components mounted on it are also bare CPU dies?</comment></comment></comment>


Mike Stonebraker: Bringing Good Ideas From Lab To Real World - <AUTHOR> http://blogs.wsj.com/venturecapital/2011/02/24/mike-stonebraker-bringing-good-ideas-from-lab-to-real-world/ <comment><AUTHOR> Interesting guy, who has been hacking on interesting things since before I was born - and I'm not all that young.</comment>


You Can't Talk About Robots Without Talking About Basic Income - <AUTHOR> http://motherboard.vice.com/read/you-cant-talk-about-robots-without-talking-about-basic-income <comment><USER2> This has already happened many times throughout history with industrialization and new technologies.

<comment><USER3> Those historical examples are about the automation of _physical_ effort. The ability to automate tasks that require _mental_ effort is fundamentally new to humanity.

For a better overview, see CGP Grey's explanation: [https://www.youtube.com/watch?v=7Pq-S557XQU](https://www.youtube.com/watch?v=7Pq-S557XQU)

<comment><USER2> There have been plenty of historical examples of automated mental effort from Wall Street trading, to telephone switching, to legal research, to librarians, record keeping, accounting, logistics management, forestry overwatch, security, safety regulation, meter reader, parking enforcement, communication, art, banking, many examples throughout history.

<comment><USER4> Sure; but the things you describe are levers, not automata.

We are approaching the point where there are humans who are not needed physically, and not smart enough to do something that can't be automated. It's a slowly rising tide.

</comment></comment></comment></comment><comment><USER5> I'm optimistic. Only 40% of humans will die. 20% will suffer the rest will live a happy problemles live.</comment>


Apple Open Source Development Resources - <AUTHOR> https://developer.apple.com/opensource/ <comment><USER2> "Apple, the first major computer company to make Open Source development a key part of its software strategy, continues to use and release significant quantities of open source software."

Uh ... please tell me they are kidding ?

<comment><USER3> Heh, probably never heard of some small companies like Google, Sun, Oracle, IBM and others.</comment></comment>


Teller – API for your bank account - <AUTHOR> https://blog.teller.io/2017/06/12/the-api-for-your-bank-account-is-here.html <comment><USER2> UK banks don't accept any liability if you give your online banking credentials to a third party.

If some fraud was to come about as a result of someone using Teller then they would be out of pocket or has Teller got agreements with the compatible banks to overcome this situation (either by Teller reimbursing the customer or the bank)?

<comment><USER3> Hi,

Firstly, we don't always need a credential. Some banks provide other auth mechanisms, e.g. EMV CAP. We use this for Barclays and Nationwide. Using Teller might not violate your bank's terms of service, which is why we advise you to read them in conjunction with ours. Furthermore, it is the view of some senior bank people that I speak to that PSD2 will make such clauses in banking terms illegal. It is also worth mentioning there has never been a single case of fraud or loss attributed to "screen-scraping"

Secondly, we have ongoing dialogue open with every major UK bank at very senior levels, from C-level down. We want to help banks deliver these APIs. Formal agreements with banks are a key strategic objective for Teller, but they only started returning my calls once I'd broken their apps and took their APIs. The market can't wait for the banks, developers and users want new choices, apps and service now.

<comment><USER4> > It is also worth mentioning there has never been a single case of fraud or > loss attributed to "screen-scraping"

This response makes me angry. Every service worth attacking will have security problems at some point. You're running a store of bank credentials, which you have to have access to (as opposed to password managers for example which can store user encrypted data). Given enough time, one of these services will get hacked and "this has never happened before" is not going to be a good answer. Someone will be the first one.

I'm happy your service will push more banks to provide APIs. But I'm already doing bank screen scraping for myself because I don't trust services which require my credentials. I hope people consider that risk seriously.

<comment><USER5> This is what always worried me about services like Mint.

<comment><USER6> Mint is probably the one you don't have to worry about. The service that stores credentials and scrapes bank sites is the same one that powers TurboTax and QuickBooks. Intuit spends a lot of money keeping that service secure and they're well aware of how catastrophic a breech would be.

In short, that service is run out of private datacenters, not publicly available. You'd have to compromise not just Mint/TurboTax/QuickBooks but then the FICDS service, which only has methods that take a token representing the credentials and passes back transactions, not the actual credentials.

It's the competitors to Mint who can't afford their own datacenters and don't have the many millions of dollars to put into securing their service the way Intuit does that should be much more worrisome.

Disclaimer: I used to work at Intuit, though not on any of the products I mentioned. But I have had many conversations with the people that run Mint and FICDS and I know the overall architecture used. I give my bank credentials to Mint without any worry. It would probably require a state-level entity to get in, and they'd likely need to get someone hired into that group to facilitate it. The service is very secure.

<comment><USER7> I don't know, if the general level of bug-ridden-ness of their products is any indication, I wouldn't put much stock in their security. There are glaring bugs in Quickbooks for example that persist year after year, having been reported repeatedly, even as they continue to release a new version every single year with various visual tweaks and seemingly not much else.

<comment><USER6> QuickBooks, even the online version, are decades old and have major issues that prevent the teams from getting much done. They took a year to do clean-up and basically didn't introduce any new features. Not much got done just due to the complexity of changing anything without causing problems.

FICDS, on the other hand, was spun up more recently and is in much better shape. I wouldn't look at an application like QBO and see much that would inform a behind the scenes service like FICDS.

The more interesting product, to me, is TurboTax. The seasonality of it allows Intuit to basically rebuild it from the ground up every year. It's really a different mindset on the San Diego campus (where TT is developed) and in Mountain View (where QBO is developed). San Diego is much more willing to take (non-security) risks with the product because small changes can add up to big wins. I remember a talk by one of the guys in charge of A/B testing on TT who said that a tenth of a percentage point increase in conversion rate was good for tens of millions in added profit.

Contrast that with QuickBooks, where the difficulty to use is actually a feature. Accountants spend years learning the app and learning the work arounds for those bugs you mentioned. That knowledge and experience becomes a barrier to entry into the field and a job skill that they're compensated for. The result is that QB/QBO is aimed at accountants with years of experience in the product. Their livelihood depends on it and they don't like change. So the teams there do as little as possible that can cause problems and know that they'll still get good reviews if the get almost nothing done so long as they don't cause problems.

It's deeply disfunctional and yet explains why you can put a lot of trust in FICDS. They too have had bugs for years. For example, they don't save cookies between scraping sessions and so are always an untrusted browser to the banks. I have at least two accounts that constantly send me 2FA tokens whenever Mint tries (and fails) to sync. But no one gets fired for not fixing bugs. You get fired for compromising the security or stability of the service, and the easiest way to not do that is to push as little possibly vulnerable code to prod. It's the anti-Zuckerberg environment...move slow and don't break things.

<comment><USER7> I suppose you could have a point about the fact that (good) accountants know the work-arounds. And many of the bugs are annoyances and UI things rather than critical stuff. There are some that will really bite you (meaning, result in incorrect accounting) if you're not familiar with them. For example, the home currency adjustment in the multi-currency mode skips accounts with a current balance of 0 in foreign currency, even if the balance in home currency is non-zero, and so an adjustment is needed. If you know that, you can go in and do those ones manually (although it's a PITA), but if you don't, your taxes will be off. That seems like something that should not be allowed to persist in accounting software. It's the most glaring example I can think of, but there are others.

Ha, actually, one more - the only way to change the date format in invoices (from mm/dd/yy to YYYY-mm-dd for instance) is to change the overall Windows OS setting. That's crazy enough, but what's worse is, when you do that, it screws up the dates of many pre-existing, closed transactions in your company files. Fortunately in my case (iirc) it reset those dates way in the future, so I was able to find and fix them manually. But I mean, seriously...

<comment><USER6> Heh...you're talking QBD. That's the true dysfunction of Intuit. It's the product Intuit doesn't want you to use. They want customers to transition to QBO and only "maintain" Desktop because many customers refuse to "upgrade" to Online. I never met a single employee who was currently working on QBD. A product that accounts for more that 1/4 of their revenue and they had literally no engineers participating in company events, or at least disclosing what product they worked on. Hell, I met the entire Quicken for Mac team at one point.

My favorite WTF for QBD: The data upload was literally just using the replication feature of the embedded Sybase database. One of the Distinguished Engineers that I worked with, "I worked on that feature and I probably know more about how it works than anyone and I can't get it to work reliably.

<comment><USER7> Yeah, I don't love the idea of trying to run accounting software in a browser; doesn't seem like it could possibly have the performance of a desktop app. Also, last I checked, QBD includes features I use that QBO doesn't. I can't recall what they were though, so that may no longer be the case.

So, does this mean QBD is basically the living dead, and inevitably I'll have to find an alternative? It looks like everyone's doing online these days.. :/

Edit: Yeah, looks like it doesn't have inventory tracking. Conflicting reports on multi-currency support too.

Looks like Xero might be a viable option though.

<comment><USER6> > So, does this mean QBD is basically the living dead

That was the impression I got when I was there. They're putting a ton of effort into getting people to migrate. But there's still a ton of die-hards that won't and they were continually having to push back their sunsetting plans. I've been gone more than a year now, so I can't say what the current situation is.

It sounds like you're a lot more familiar with the long-tail features of QuickBooks, so I may be recommending something that's missing a lot of what you need, but my favorite competitor product was Wave. They seemed to be the only one that was actually trying to make an intuitive product that wasn't unpleasant to use. It's online though and I don't really know much about the desktop alternatives, so if you're set on running on-prem software, it won't work for you. The accounting stuff is free, though, if you want to play with it.

But Xero is also online only, right? I was pretty negative on them, considering they basically started from scratch in an era where the result should have been much better than Quickbooks considering it didn't have all the baggage that Quickbooks has to deal with. And yet they came up with something that's arguably just as frustrating to use.

<comment><USER7> Yeah, Xero is online too. It was just the only one that appeared to check all the boxes I need. (Most were missing one of payroll, inventory management, or multi-currency support.)

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Somebody told me that 2018 is the deadline for EU banks to provide API access. If that's the case then going through any server side layer managed by somebody is unnecessary and people in general should think twice about every single bank transaction being stored somewhere "there". It gives out a lot of information from your internet provider to your child's creche, holidays habits, income (duh), loan repayments and whether you like on mondays this new sandwich at pret a manger with a coffee for take-away or eat-in - can be inferred as well.

So be careful and if you want to have more insight into your finance maybe it's better to digest those apis yourself, libraries should pop out soon if they are not yet available for your bank (in europe anyway).

<comment><USER9> Are they required to adhere to a standardized API?

If not, then I think there's still some utility in a service that can normalize that stuff and provide you with a single, consistent interface.

<comment><USER10> My understanding is that the EU PSD2 regulation indeed is supposed to make banks adhere to a standardised API. That being said, I wouldn't expect a super easy to use REST api with documentation powered by readme.io.

<comment><USER11> If you read the legislation (?) you will see that they are actually very vague in how the banks will provide access. I think it is already a great success that they (fingers crossed) will manage to force the banks to provide access to the data in any form and gave them little wiggle room for justifications to get out of it.

There are however some inititives for open API standards that might be accepted by a majority of the banks.

</comment></comment></comment></comment><comment><USER12> As a German it is hard to believe that such things do not exist yet in other countries. We have a standardized protocol called FinTS which is implemented by most banks. This results in a huge amount of desktop and mobile applications for banking.

<comment><USER13> FinTS (formerly known as HBCI) is horrible and serves as a great example of how not to design a API.

The non-machine-readable german-language-only API specification consist of >800 pages spread across various PDFs[1] full of gibberish. There are no official client libraries, no minimal examples, different banks only support certain versions etc. etc. etc.

[1]

[https://www.hbci- zka.de/dokumente/spezifikation_deutsch/fint...](https://www.hbci- zka.de/dokumente/spezifikation_deutsch/fintsv4/FinTS_4.1_Formals_2014-01-20_FV.pdf)

[https://www.hbci- zka.de/dokumente/spezifikation_deutsch/fint...](https://www.hbci- zka.de/dokumente/spezifikation_deutsch/fintsv4/FinTS_4.1_XML- Syntax_2014-01-20_FV.pdf)

[https://www.hbci- zka.de/dokumente/spezifikation_deutsch/FinT...](https://www.hbci- zka.de/dokumente/spezifikation_deutsch/FinTS_Rueckmeldungscodes_2017-05-11_final_version.pdf)

[https://www.hbci- zka.de/dokumente/spezifikation_deutsch/fint...](https://www.hbci- zka.de/dokumente/spezifikation_deutsch/fintsv4/FinTS_4.1_Data- Dictionary_2014-01-20-FV.pdf)

<comment><USER14> > german-language-only

Ah the horror. Last week it was bleating that German laws are written in German, this week it's bleating that German bank documentation is written in German.

<comment><USER15> English is the working language of software development, so it does make a degree of sense to bemoan the fact that the API documentation is only available in German.

<comment><USER16> A significant amount of software development in Germany is done in German only, especially if you solve Germany-specific problems with your software (such as accessing banks). English far from being a general working language for software development here.

The software I use at work is developed by a German-speaking team based on German documentation. I think the code is mostly English although they often use German identifiers when there is no straightforward translation[0]. It's highly specific to the German legal environment and of absolutely no use abroad anyway. Translating everything twice just introduces more errors.

</comment></comment></comment></comment></comment><comment><USER17> Not seeing terms of service or a privacy policy. Who's responsible when there's an error, or a transaction is processed twice or zero times? Is this really a scheme to obtain user data and sell it to advertisers?

<comment><USER3> Founder here. First of all, I'm honored the legendary John Nagle now knows about my startup! :)

Privacy policy and terms are linked to from [https://teller.io/developer/beta](https://teller.io/developer/beta)

Privacy policy: [https://teller.io/developer/privacy](https://teller.io/developer/privacy)

Terms: [https://teller.io/developer/terms](https://teller.io/developer/terms)

Payments APIs will be signed by the developer's private key (See more about that our auth scheme here [https://blog.teller.io/2016/04/26/tauth.html](https://blog.teller.io/2016/04/26/tauth.html)) and transactional APIs will use idempotency tokens to prevent double processing.

This is not a scheme to sell anything to advertisers, it's a scheme to improve the quality of financial services for the highest number of people by providing developers with API access to bank accounts that banks should have provided themselves long ago!

<comment><USER17> Your terms:

 _" We are not liable for any loss or damage that may result from your use of our services. This includes any direct, indirect, or consequential losses; any loss or damage caused by tort, including negligence, breach of contract or otherwise."_

You don't get taken seriously in the financial space with terms like that. You need to accept responsibility for errors and carry errors and omissions insurance.

Compare Bank of America Bill Pay service terms:

 _When you make a bill payment using Online or Mobile Banking you can be confident that it will be processed correctly. In the unlikely event that we fail to process your payment in accordance to the payee, amount and date you specified, Bank of America will reimburse you for any late-payment-related charges incurred._

 _We are committed to keeping your financial information safe and making sure you can bank with us securely, which is why you are not liable for fraudulent transfers or bill pay transactions made via online or mobile when they are reported promptly._ [1]

[1] [https://www.bankofamerica.com/onlinebanking/online- banking-s...](https://www.bankofamerica.com/onlinebanking/online-banking- security-guarantee.go)

<comment><USER3> Thanks for your feedback. We developed TAuth to provide attribution and non- repudiation for exactly this kind of situation. I personally take security very seriously such that launching our product has taken longer because designing and implementing a system worthy of performing financial transactions on behalf of others is a serious undertaking.

Our terms are comparable to the incumbent "screen-scrapers" in the market, e.g. Yodlee and Plaid. FWIW it is not currently possible for users to move money with Teller. I'm open to revisiting the terms when it is, and I'm always open and listening to feedback such as this.

Thanks for taking the time.

<comment><USER18> Is there much desire for moving money via API though? Seems like it would expose you to massive risk for little reward.

<comment><USER19> Oh my, I have thought about this a lot, and I firmly believe that there is. Sorry for the ensuing wall of text!

Right now I pay for several online services, a gym membership, insurance, a student loan, a mortgage, and an auto loan. Every one of these companies has authorization to pull money from my account each month. They all pay their payment processor a significant sum of money in exchange for the processor running the payments and shouldering the risk of the bank not honoring them.

With an API, I could stop relying on this "pull" model and start using a "push" model instead. Companies get my money only when I explicitly send it to them. I could schedule a payment to go out every month for services I want instead of allowing arbitrary vendors to charge my card (banks do have a partial stab at this in the form of bill-pay, but it tends to be pretty bad).

Presumably since the risk of fraud is lower since I authorized the payment with my RSA key, merchants could pay lower fees to their payment processors.

Now, I'm a little atypical, because I know how to program so I could use the API without help. But I know many people who would certainly take advantages of services built on top of an API like this.

Think of all the people in your life who have accidentally continued paying for something they no longer wanted due to the vendor "mistakenly" continuing to charge their card. Or scummy negative-option marketing companies which loudly tout a free product or service and then continue to charge your card thanks to some tiny section in their terms of service.

The possibilities get better too. You could have budgeting apps that don't let you spend more than $X per month for video games, but still allow you to buy groceries. You could give your children an authorized card with a per-month maximum but still allow them to pay for an Uber home if it's after 9 pm.

I really think this sort of thing would be a massive boon to people and society, and it's unfortunate that banks (in America) are fighting so hard to prevent it.

</comment></comment></comment></comment></comment></comment><comment><USER20> Early on at Token, we looked Teller as a possible solution to getting to market quickly. We found two things: 1) the lawyers told us to stay clear (huge greyzone) and 2) the banks themselves didn't want to engage with us using teller even if it sped up development time. We even brought stevie in talk to our lawyers to make his case. He failed to convince them. Finally, we inquired about the price. Stevie was elusive on pricing. I finally asked, "Look, if we paid you $1M, how many banks could we get?" He said one. So at that point, we were so far apart on all issues, so we pulled out. Token will be doing something similar to teller in terms of "one API for all banks" (aggregating banks' PSD2 interface with Token acting as a PISP/AISP). But we are also providing the PSD2 interface for other banks. We have raised plenty of money to do it right ($18.5M Series A to start with), but our pricing to developers will be ridiculously inexpensive. Also, we need to hire developers very quickly, so if you are interested in helping us do it right (no shared secrets, all end-to-end secure protocols, secure central PII storage (where the decryption keys are only available at endpoints), please let us know. We don't have a lot of time left to do this right. We are located in London and San Francisco.

<comment><USER3> Steve,

I'm really surprised.

> the lawyers told us to stay clear (huge greyzone)

I remember going in to speak with your lawyers, convincing them, you emailing me the same day telling me as much and still wanting to do a deal.

> Stevie was elusive on pricing. I finally asked, "Look, if we paid you $1M, > how many banks could we get?" He said one.

If you then thought I was going to give you, a competitor, my core IP for 1 million dollars a year, while you used it with your series A money to capture the market, well then you must be out of your damn mind.

> the banks themselves didn't want to engage with us using teller even if it > sped up development time

Banks don't want to engage with you period. Nobody has heard of Token, you have zero technology and zero bank integrations.

Best of luck with it all, Steve.

<comment><USER21> It seems you boys can settle your dispute the old fashioned way: by providing support for your claims.

 _I remember going in to speak with your lawyers, convincing them, you emailing me the same day telling me as much and still wanting to do a deal._ At least one of you should have these emails.

 _If you then thought I was going to give you, a competitor, my core IP for 1 million dollars a year, while you used it with your series A money to capture the market, well then you must be out of your damn mind._ You would have been paid $1m/year to provide a _service_. You wouldn't have given up ownership of your company, or taken a risk on stock valuations. $1m cash. Each year. Actual cash. For a startup of 1. If you don't think that's good money right out of the gate, you have serious judgment issues (and this is also reflected in your top-floating comment re security).

 _Nobody has heard of Token, you have zero technology and zero bank integrations._ This was the first time I've heard of Teller...If Token claims they have bank customers that they're providing integration for, it's an easy matter for them to prove it; they only need to publicize one bank client to refute your claims. On the other hand, you come across as very petulant when you say nobody has heard of Token and that they have zero technology or bank integrations since that's an easily disprovable claim.

FinTech and financial services place a lot of value in judgment, since their industry is defined by risk. Right now, you're not showing much good judgment, and if you keep up like this, you have no chance in this space because you're demonstrating in many ways that you're a bad risk for them to take.

</comment></comment></comment><comment><USER22> There already exists a company called Teller in Europe which is dealing with payment solutions.

> Nets is split up in two divisions: Nets, which manages the Danish market, > and Teller, which handles all international markets. This means that Nets > processes all Dankort transactions, while Teller processes all transactions > by international cards.

[http://www.epay.eu/acquirer-internet/nets- teller.asp](http://www.epay.eu/acquirer-internet/nets-teller.asp)

[https://www.nets.eu/en/payments/](https://www.nets.eu/en/payments/)

[http://netseu.23video.com/secret/12342399/64f0568391b3ebaa58...](http://netseu.23video.com/secret/12342399/64f0568391b3ebaa58b291826ee05aa4)

[https://my.teller.com/login](https://my.teller.com/login)

</comment><comment><USER23> Hey all - co-founder of Plaid[0]. Congrats to Steve - great to see some innovation across the pond!

There were a bunch of questions about Plaid and the difference. The obvious one is that Teller is UK only and supports the top couple banks, Plaid is US only and supports thousands of financial institutions. If you need both UK and US coverage - since we both have pretty developer friendly APIs - it seems like a nice combo! Steve/Teller have also taken a bit of an antagonistic approach and has not worked with the banks - time will see if this proves successful, but we've taken the approach to work directly with the banks (as investors, clients, data-partners etc.).

Hope that helps and if you have any other questions/comments feel free to shoot me an email at william [at] plaid.com

[0] [https://plaid.com](https://plaid.com)

<comment><USER24> > Teller... supports the top couple banks.

> Plaid... supports thousands of financial institutions.

While this is technically correct, I feel this is a little disingenuous. In the UK we have a far concentrated banking industry, at least in retail banking, in that the vast majority (I'd guess >99%) of current accounts or similar are held with maybe 6-7 well known high-street banks. We also do not yet have a shared banking API format.

In the US, there are a very large number of smaller credit unions, and many banks/credit unions support the same API format (that I believe Mint.com etc use), and have done for a long time.

So I feel this is disingenuous because a) there are fewer banks to integrate with in the UK, and b) the game of integrations here is much tougher.

</comment></comment><comment><USER25> Am i the only one that would never trust a completely unknown third party with my bank account?

I like the idea, but i would never use this as a service on the internet.

<comment><USER26> There will be early adopters who take on this new tech and show the rest of us the possibilities. Just because someone reads HN doesn't mean they need to jump on the band wagon

</comment></comment><comment><USER27> How is this different than something like [https://plaid.com/](https://plaid.com/) ?

<comment><USER28> Or any different from Quovo ([https://www.quovo.com/](https://www.quovo.com/)) if you were pulling both bank data and brokerage data?

<comment><USER29> First I've heard about Plaid and Quovo. These services seem to be targeted at a developer interested in developing products for others.

I really wish someone would come out with an API service targeted towards someone who would like to manage and query their portfolio of accounts with code. I have tried time and time again to use things like Mint or Quicken to have a consolidated view of my accounts, but invariably I find things that really suck about the service. I'd rather hack together a set of scripts and do it that way, but where to go for the actual access (aside from manually downloading .obx files).

<comment><USER27> I use Plaid for my own bank account access, which I used to replace my own OFX code because my banks kept randomly breaking their OFX interfaces.

Plaid was fine with creating a developer account for just a few bank accounts, they didn't have any minimum or anything.

<comment><USER29> Thanks. I'll give it a shot. Any useful scripts you'd care to share?

One thing I ran into quickly when parsing my own bank's OFX was the truncation of the payee field, which made it extremely difficult to identify certain transactions. For example, I might get coffee at a Starbucks, but it would show up in the bank export as "STORE93423 CA LA STAR". I never determined if this was a limitation of the bank's software or simply that OFX didn't allow for enough characters. It'll be interesting to see if Plaid solves this.

</comment></comment></comment></comment></comment><comment><USER30> _How many times have you thought to yourself "Damn, I really wish my bank account had an API"?_

Now that's an intro!

<comment><USER31> You think? For me as a Dutch guy my only though was "literally never".

We have ideal for payments ([https://www.ideal.nl/en/payment-service- providers/](https://www.ideal.nl/en/payment-service-providers/)) and every bank has its mobile app that is integrating via ideal. So all payments on my phone the app just pops up, I do a finger scan and done. All apps are very decent for all normal banking business. I can't think of any use case I would need to trust a third party with my credentials.

<comment><USER32> Another dutch person here. I can think of plenty of use cases. I'd like to keep track of where my money goes, and have played with programs like GnuCash and Ledger before. The big problem is getting data into them. I have a decent system where I download the CSVs, feed them to a script, and everything gets imported. However this requires me to think about downloading that CSV every month. And my administration lags behind by a month. It's also inconvenient if my system can't automatically identify the receiver, since then I'll have to help it out. Hard to do that when I have to recall where I spent $15 a month ago.

If there was an API I could use to get these details, it would be so much more convenient. Could even build a product around it.

</comment></comment></comment><comment><USER33> "We realise that our revenue will most likely be a very long tail with a small number of customers bringing in most of the cash."

Either they or I don't understand what long tail means.

<comment><USER34> Long tail doesn't necessarily mean that the tail makes up most of the distribution. A long tail can make up a majority, or minority, of the total distribution.

E.g. 80% of revenue coming from 1,000 customers. 20% of revenue coming from 100,000 customers

or

20% of revenue coming from 1,000 customers. 80% revenue coming from 100,000 customers.

The latter is more fat-tailed.

</comment></comment><comment><USER35> Dutch mobile-only bank Bunq also published their API pretty recently: [https://www.bunq.com/en/api](https://www.bunq.com/en/api)

Things are starting to not-entirely-suck in retail banking land. (in Europe, at least - not sure about elsewhere)

<comment><USER36> Monzo, the UK mobile-only bank, also has an API: [https://developers.monzo.com/](https://developers.monzo.com/)

Teller is not a bank itself though. I believe it started as a wrapper around banks' private APIs, not sure whether that's still the case.

<comment><USER37> To be fair, Monzo isn't either. They don't have any of their own infrastructure yet, it's just a third party rebranded prepaid card.

<comment><USER38> That's not true. They recently received a banking license ([https://monzo.com/blog/2017/04/05/banking- licence/](https://monzo.com/blog/2017/04/05/banking-licence/)) and they have built their own platform ([https://monzo.com/blog/2016/09/19/building-a- modern-bank-bac...](https://monzo.com/blog/2016/09/19/building-a-modern-bank- backend/)).

<comment><USER39> But monzo card is still just prepaid debit card. You don't get a current account.

That might change later this year when they roll out current accounts but for now it's just simple prepaid/travel debit card with mobile app.

Also not sure they have switched from WireCard yet? Last time I heard they have not switched all of their existing users to their own platform but perhaps they managed the transition already?

</comment></comment></comment></comment></comment><comment><USER40> I built a little script to export my accounts to CSV/QIF. Super easy to use API! [https://github.com/scottrobertson/teller- export](https://github.com/scottrobertson/teller-export)

</comment><comment><USER41> Can someone explain to me this dichotomy I see with the almost thermo-nuclear war when it comes to copyright protection of total drivel, but when it comes to fin-tech there is literally a flourishing industry of screen scraping typing companies and well-publicized plays like Mint and it's just like a big shrug? How are these companies able to mitigate through the banking companies TOU and such?

<comment><USER42> There are two main differences between screen-scraping content and screen- scraping transactions.

First is that copyright applies to written content (even short content such as tweets) and does not apply to factual data.

Second is that whatever rights may apply to the data, in the fintech scenario the users are scraping _their own_ data.

So all kinds of copyright-specific laws, of which there are many, don't really apply in this case - and those are the laws that can easily get used against the service provider, unlike the possible ToS violation where the bank would have to against their own customers to enforce it.

</comment></comment><comment><USER43> How does it work if not by screen scraping?

<comment><USER3> It works by using the same private APIs that the bank's own mobile app. We reverse engineer their app, work out the API contract, implement our client, and normalize the data.

Reverse engineering mobile APIs is a superior strategy to screen-scraping because:

\- they already return structured data

\- the security model for that channel is different, e.g. no need for 2FA all the time so truly unattended use cases are possible

\- it's much more difficult for banks to make breaking changes. When banks do make a breaking change the old version is supported for a decent amount of time to allow their own banking app users to upgrade, we can take advantage of this window to provide a consistent level of service.

Finally, we often don't need user credentials. If there is an option to authenticate with another mechanism during registration, e.g. EMV CAP (A.K.A Barclays PINSentry etc) we use that.

<comment><USER44> Not only does this sound potentially illegal but how can you be confident that you will recognize the breaking changes in time to fix them? What if you begin supporting a large number of banks and you can't keep up?

Also, will your reverse-engineered use of the mobile API's have any detrimental effect on the user? I imagine the user will be the one authenticated with the API, what if the bank starts to see an influx of odd API traffic and decides to investigate it or there is some type of rate limit?

Your decision to reverse-engineer mobile API's opens the door for many important questions in my opinion.

<comment><USER3> The EU Computer Programs Directive 2009 provides an exemption for reverse- engineering for the purposes of creating inter-operable systems. This directive has been harmonized into UK law (where Teller is domiciled and operates) and Teller satisfies the requirements to be protected by the exemption. We have also developed many novel techniques that do not meet the UK legal definition of reverse-engineering so we have that angle too. This issue has also been looked at by expensive lawyers.

In terms of stability. It actually takes 6-12 months for a bank to get something into production. We are not talking about fast moving organisations here. We have not had a breakage with a supported integration in two years of beta testing.

We take many steps to ensure our traffic does not stand out to banks eager to actively interfere with Teller. Our clients perfectly emulate (100% API compatibility with their own) and make the same API calls in the same order etc. We also only make API calls as a result of user action, i.e. Teller does not poll or cause atypical traffic patterns. Finally have 100s of IP addresses and assign an IP address to a user for a period of time. All of this compounds to make Teller traffic look indistinguishable from their own mobile app traffic. The objective is to make it more likely they will block their own app traffic than block Teller as a string incentive to not interfere their customers' choice to use Teller enabled services.

<comment><USER45> Seems pretty sensible.

I hope banks will realise that open APIs are a good thing, and if they don't start getting their shit together, they'll be left behind. Our whole financial infrastructure is so needlessly complicated. Why can't it all be JSON APIs?

</comment></comment></comment></comment></comment><comment><USER46> I emailed a bit with sjtgraham on this a while back.

It was my understanding back then that even when Teller does more advanced authentication with the bank, eg EMV CAP, that that does still grant them the rights to move money, even though Teller doesn't yet support it.

To me that paints a big target on Teller's back - all those juicy downstream credentials.

sjtgraham's point was that setting up new payees typically (always?) requires additional authentication. But I can think of a number of scenarios where a hacker might send all my money to all my existing payees just to mess with me/Teller/my bank... causing fees and stress.

Obviously it's going down the route that Teller won't need your full credentials, you will grant them access via something like EMV CAP, which I applaud.

But I would call on Teller to publicly commit to not integrate more 'advanced' auth methods if they don't include the ability to grant read-only access, if the user wishes!

<comment><USER46> Incidentally, if Teller start to get an appreciable proportion of the UK population (remember, users will be using Teller without realising, through other apps and platforms), they should expect a call from the regulators, who will want to be sure that they can't cause any systemic instability (eg by getting hacked.)

</comment></comment><comment><USER47> Yeah no thanks. I want a banking API but I want a _first party_ API. No way I'm trusting some random guy on the internet with my banking password.

</comment><comment><USER48> This is interesting and has great potential to grow when PSD2 goes live in EU (early 2018). I wonder what authors plans are regarding this.

<comment><USER3> My hypothesis is that PSD2 will not be the golden opportunity everyone hopes. Banks are an oligopoly and unfettered open access to their customers via open APIs is potentially a disaster for them. They have little to gain and everything to lose. When you consider this and then expect incumbent banks to act in their self-interest it follows that they will act to subvert the impact of PSD2, e.g. by fragmentation, lobbying for onerous requirements in order to consume them, etc. All of this is already happening, which is why I think there is an opportunity for Teller by truly aligning with developers and users.

<comment><USER49> Removing roaming fees for all European telecom operators was also a something that they had little to gain and everything to lose. But, here we are. From my understanding SEPA is getting implemented. I could see PSD2 following the same path. Some banks will drag their feet, but it is a pandora box situation, as the banks that will implement PSD2 first might get all the apps attention and love, potentially driving new customers. Let's see next year how PSD2 adoption pans out...

PSD2 explained: [https://transferwise.com/gb/blog/what-is- psd2](https://transferwise.com/gb/blog/what-is-psd2)

<comment><USER50> Current roaming regulations in the EU are designed with the biggest, transnational players in mind. By subsidizing operations in a less lucrative market using proceeds from other countries, they can bleed smaller national telecoms. They will then proceed to buy them for pennies on the dollar. This will result in less competition down the road, and higher prices for the end user.

<comment><USER51> Can you break that down? How do the roaming regulations enable those bigger players to do that?

<comment><USER50> [http://ec.europa.eu/transparency/regdoc/rep/10102/2016/EN/SW...](http://ec.europa.eu/transparency/regdoc/rep/10102/2016/EN/SWD-2016-202-F1-EN- MAIN-PART-1.PDF) \- see page 32 (ARRPU). Operators in different countries have different profits per user (obvious). If you have someone like T-Mobile or Orange, they'll use the proceeds from say... France, to finance their operations in say... Poland. This will put pressure on other national operators to further lower prices. Lower prices mean lower profit margins, mean lower dividends, lower company valuation, being less attractive to investors, etc. After a while their value will decline by so much, they'll be willing to sell themselves at the current going price of their infrastructure. Orange buys them, and kills off competition.

<comment><USER52> That would be referred to the competition commission and could be blocked.

<comment><USER50> This has already happened and no one batted an eyelash. Why?Because, Orange is French and T-Mobile is German.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER53> I wonder how many of the use cases for a retail banking API would be simply satisfied by just allowing customers to request a weekly email with a CSV transaction file attached in a sensible format?

<comment><USER54> Banks should most definitely do this. Or maybe provide a link to a CSV file behind a login-wall (so the details passed over email can't be poached as easily)

</comment></comment><comment><USER55> Is there a test / mock instance, allowing you to call services connecting to dummy bank accounts? i.e. Some people may be concerned about trying out the API on their own accounts during the early stages, or if any update services are added in future. Also it enables those not banking with a supported bank to develop against the service.

<comment><USER3> A sandbox is planned.

</comment></comment><comment><USER56> People: Only do it with an extra bankaccount. Without any credit functionality and without your primary money.

Everything else would be very naiv.

</comment><comment><USER57> Once you have access to someones banking account you can typically make small transfers (up to ~£200) without second-factor authentication. So if your service get's breached attackers will have potentially the means to extract real cash through mules or wreck havoc.

Asking for credentials is no go whatever the bank is. There are ways to get some feeds even now but that requires signing some papers. Besides, I don't want to shoot down the service because this is genuinely a useful service (if it wasn't for the scrapping) but the best way to solve this problem is for banks to implement their own APIs with proper access controls that make sense in the context of the bank and the account.

</comment><comment><USER58> Teller is already an established brand name in the payment industry in Norway (Scandinavia?). [https://www.nets.eu/en/payments/](https://www.nets.eu/en/payments/)

</comment><comment><USER59> This is annoying, I got all excited and then realising this is for a handful of UK banks. Would be great if it were tagged as a UK thing more prominently.

<comment><USER60> I was really not excited, expecting it to be US-exclusive, until I clicked the link and saw it was UK banks. Whoop ;)

<comment><USER61> I had he exact opposite reaction: expecting it to be US-exclusive and got to the last paragraph where it said they don't support any US banks. Big ole' :-( face.

</comment></comment></comment><comment><USER53> Does anyone have any insight into a PSD2-style effort in Australia?

I notice that National Australia Bank is experimenting with APIs, they have a developer portal [1], with FX rates and branch location APIs currently available. Authentication, customer details and accounts APIs are 'coming soon'.

[1] [https://developer.nab.com.au/ourapis](https://developer.nab.com.au/ourapis)

<comment><USER62> There's also a long running discussion on the commbank forums (since 2013).

[https://community.commbank.com.au/t5/NetBank/API- access/td-p...](https://community.commbank.com.au/t5/NetBank/API- access/td-p/5071)

However, the response is not really understood by those answering the question.

There was talk of them being required by ligislation to have an api by July 2018, but not sure what the progress of that is.

[https://www.itnews.com.au/news/australian-banks-told-to- buil...](https://www.itnews.com.au/news/australian-banks-told-to-build-apis- to-share-data-by-2018-442562)

</comment></comment><comment><USER63> Bunq already has a native api [0], only if you pay sadly, many other functions are free. I like Bunq but their app devellopment is slow, I still can't share iDeal (is iDeal only Dutch? I wonder...) requests through anything other than email and sms. Everybody is waiting for general sharing on Android/iOS.

[0] [https://doc.bunq.com/](https://doc.bunq.com/)

</comment><comment><USER64> > Transfer money between accounts, make external payments using Faster > Payments, and manage your payees, standing orders, and Direct Debits all > through the Teller API.

What will the fees be on sending/receiving money?

Scraping data from your own bank account seems rather uninteresting to me. I assume sending/transferring is limited to domestic banks. Is this the case?

<comment><AUTHOR> Teller allows developers to build applications on top of their users' bank accounts, not just your own. Read more about TAuth and how it works here: [https://blog.teller.io/2016/04/26/tauth.html](https://blog.teller.io/2016/04/26/tauth.html)

</comment></comment><comment><USER65> Cool project,

You should make it open source (to grow your bank catalog by the community) with some premium Plan (to earn money of it)

That's the only way to get it worldwide, otherwise, you will have to do MITM attack every single Bank App in order to get their APIs, with is painful and most of the times impossible without valid credentials.

Opensource + Premium is the way to go!

<comment><USER66> Teller is amazing (kudos to Stevie), but if you're looking for an open source solution you can take a look to:

[https://github.com/bankscrap/bankscrap](https://github.com/bankscrap/bankscrap)

We already support major banks in Spain and we're looking forward for people who can contribute with adapters to support even more banks worldwide.

</comment></comment><comment><USER67> Engineer at MX here! We have a similar product for US and Canadian banks called Atrium.

More info here: [https://atrium.mx.com/home](https://atrium.mx.com/home)

NOTE: I saw a few people mentioning Plaid and Quovo so I thought it would be appropriate to mention our product.

<comment><USER68> Didn't Morningstar just sell you to a bank though?

Is your product still going to be on the open market in 6 months time?

<comment><USER67> MX is not owned by any bank. It's still privately owned startup. We are long term in that we have many 5-7 year contracts with big name banks and add more each quarter. We offer mobile banking solutions, data categorization and budgeting tools to banks, so we Atrium is a product to sell access to the services we built to power our other products. So yes, our product will definitely be on the market for years to come.

We do add as many data sources as possible. We can use Morningstar for example to find cusip of holdings data. We're always trying to improve too :).

<comment><USER68> Sorry, don't know why I always get MoneyDesktop and HelloWallet confused. :(

Cool… keep on trucking! :)

BTW, I don't suppose you have Australian/NZ support?

</comment></comment></comment></comment><comment><USER69> Knowing the founder personally and his level of competency writing code gets me very warm down below. If I still lived in the UK, I would build something around Teller trying to give users a feeling close to what Monzo-bank is/does. Some kind of a hybrid zombie child, but beautiful!

</comment><comment><USER70> A bank account is usually only part of the financial equation. What would really be useful is an API for a service like Mint. I'd even be willing to pay a low fee for someone to make available all the aggregate data from all the financial institutions via API for me.

<comment><USER71> IIRC, Mint works by screen-scraping, which is what Teller.io is trying to avoid

</comment></comment><comment><USER72> Maybe every Bank should provide its own, well documented API. Third Party is not an option imho. Also this reminds me of that root Bank i saw here in HN some time ago... [https://root.co.za/](https://root.co.za/)

</comment><comment><USER73> This looks really cool, but I'm nervous about trying it. Can they provide any guarantees?

<comment><USER74> _While we make every effort to ensure our services are available, secure, accurate, complete, and free from defects we provide no guarantees, conditions, or warranties of this, express or implied.

We are not liable for any loss or damage that may result from your use of our services. This includes any direct, indirect, or consequential losses; any loss or damage caused by tort, including negligence, breach of contract or otherwise.

This applies if the loss or damage was foreseeable, arose in the normal course of things or you advised us that it might happen.

This includes but is not limited to loss of your income or revenue; salary, benefits, or other payments; business; profits or contracts; opportunity; anticipated savings; data; goodwill or reputation; intangible and tangible property; wasted management or office time._

No, none.

<comment><USER73> That's a shame.

Will have to pass on it for now. Good to see a lot of growth in the FinTech industry though, with banks like Monzo popping up and all these smart investment sites like Nutmeg.

</comment></comment></comment><comment><USER75> I have a UK bank account but no UK phone number, can't sign up.

</comment><comment><USER76> Sorry for the newb question but a quick google didn't yield the results I was looking for. What is the attack vector here that "screen scraping" would exploit?

</comment><comment><USER77> Which countries are supported? Not seeing that info anywhere. I only saw in a comment here that Teller has relationships with "every major UK bank".

<comment><USER77> Found it: [https://teller.io/developer/beta](https://teller.io/developer/beta)

It is UK only.

</comment></comment><comment><USER78> Seems similar to [https://root.co.za/](https://root.co.za/) \- which is focused on South Africa.

</comment><comment><USER79> Paybook ([https://www.paybook.com/](https://www.paybook.com/)) is doing the same in Mexico

</comment><comment><USER80> Just wanted to say well done. Lots of people here throwing up problems, complaints, reasons why this won't work etc. I think this is great.

</comment><comment><USER81> I think I noticed a similar venture in Indonesia: [https://brank.as/](https://brank.as/)

</comment><comment><USER82> Is this only for UK? which banks are supported?

<comment><USER83> It's stated in the post:

"Teller is available today for Santander UK, Barclays, Natwest, Nationwide, RBS, Isle of Man Bank, and Ulster Bank."

</comment></comment><comment><USER84> Superb. Any chance of supporting Lloyds?

<comment><USER3> Yes, Lloyds HBOS brands are a high priority.

</comment></comment><comment><USER85> I'd much prefer that this were just open source so I don't have to share my bank credentials.

</comment><comment><USER86> When will this be available in the US?

<comment><USER87> Never?

You need legally available reverse engineering without dmca-hammer to be applied plus PSD2 directive coming soon forcing banks to open.

Those are EU things.

<comment><USER88> yodlee, mint, quicken, come on. I've had bank transaction information for last 20 years

<comment><USER87> Mint is readonly. PSD2 and reverse engineered api is not. Also Mint exposes you to the very threat mentioned in top comment, while PSD2 protects you here.

So how about No?

</comment></comment></comment></comment><comment><USER89> OMG finally! So does this mean we can skip all the credit card and ACH fees?

</comment><comment><USER90> Would love HSBC support :)

</comment><comment><USER91> Any plans on support for more American Banks, such as Wells Fargo?

</comment><comment><USER92> There are many many problems besides the technological hurtles.

</comment><comment><USER93> Is there any plan to support south korea?

</comment><comment><USER94> Is the fact you don't talk at all about security in this blog post or on your home page deliberate?

</comment><comment><USER95> Why is it gated behind SMS?

</comment><comment><USER96> I cant wait for PSD2.

</comment><comment><USER97> cool - what makes your service different from Yodlee?

</comment><comment><USER98> Yet another man-in-the-middle collecting a fee from each transaction?

</comment><comment><USER99> I'm sorry but your solution is not my problem.

</comment><comment><USER100> How is this differently than Yodlee?</comment>


Why is Israel so big in high tech? - <AUTHOR> http://www.quora.com/Why-is-Israel-so-big-in-high-tech?share=1

<comment><USER2> A plug for "Start-up Nation" is mandatory, would be useful for anyone who wants a little deeper exploration of the topic: [http://www.amazon.com/Start- up-Nation-Israels-Economic-Mirac...](http://www.amazon.com/Start-up-Nation- Israels-Economic-Miracle/dp/0446541478)

</comment><comment><USER3> Interesting point on number one. There is a big movement against the free movement of labor in the tech world, but that free movement of people is the life blood of high tech companies.</comment>


Twitter's Tips for Making Software Engineers More Efficient - <AUTHOR> http://spectrum.ieee.org/view-from-the-valley/computing/software/twitters-tips-for-making-software-engineers-more-efficient <comment><USER2> "(...)every one percent improvement, in a large organization, adds up. Reducing compile time just five minutes a day, for example gives engineers 1 percent more real working time. Reducing the number of times tools break—even if each incident just causes an interruption of a minute or two—can bring about huge productivity improvements. "

I wonder if this can be interpreted as a first signal of industrialization which will take some art/craft/individuality out of the profession? Just like it happened when artisans and craftsmen were replaced by standardized assembly lines and monitored, constantly optimized processes. I got a feeling that it is as inevitable as unimaginable today.</comment>


Show HN: Gnomecast – A Linux Chromecast GUI with transcoding and subtitles - <AUTHOR> https://github.com/keredson/gnomecast <comment><USER2> What I would really like (but was never able to find) would be the _opposite_ direction, i.e cast things from me phone (or laptop) to a program running on my PC (or my android device) - i.e a software "chromecast".

Is anybody aware of such an application (that actually works)?

<comment><USER3> Oddly enough there's a Chrome extension that supports this, but it's restricted to Google Apps for Education users. [https://support.google.com/edu/castforedu/?hl=en](https://support.google.com/edu/castforedu/?hl=en)

<comment><USER4> Has anyone tried installing the extension from [https://chrome.google.com/webstore/detail/google-cast-for- ed...](https://chrome.google.com/webstore/detail/google-cast-for- education/bnmgbcehmiinmmlmepibeeflglhbhlea) without an education account? How is its use blocked?

<comment><USER5> I'm on a "regular" Google Apps account (ie, grandfathered into the old free one aka gmail on a custom domain).

I can use this fine, with some gotchas:

It'll only allow different users on the same gsuite account to connect. I can't, for example, invite a personal gmail account or an account on a different gsuite domain.

We use Google Meet at work for meetings, which also supports "Casting to a meeting", but that requires gsuite as well.

</comment></comment></comment></comment><comment><USER6> This works great, thank you. Maybe I can stop dropping video files on a Chrome browser tab. Why does this work so easily but the new VLC still doesn't find my chromecast?

<comment><AUTHOR> thanks! i'm with you on disappointment w/ VLC's latest release. normally they do great work and i love VLC overall, but i waited so long for the casting and it's buggy as heck, and still didn't do subtitles! (my wife's EAASL so it's important for us :) of course all i did was just wrap a GUI around an existing python lib that already worked great, so i really just did all the easy stuff.

<comment><USER7> Sadly I agree. I had a lot of issues casting from VLC on mac OS.

</comment></comment></comment><comment><USER8> > This is a _native_ Linux GUI for casting local files to ChromeCast devices.

Love it, good work.

<comment><AUTHOR> thanks!

</comment></comment><comment><USER9> I am looking forward to trying it when I get home, does it support casting audio (eg. an mp3, flac, etc.) to a Chromecast Audio?

<comment><AUTHOR> casting a video's audio track to an audio device works. adding support for the audio container should be trivial. can you open an issue on GH for it so i can ping you when done?

<comment><USER9> There was already an issue in GH, but I added a little more detail to it. Thanks for a very cool project!

</comment></comment></comment><comment><USER10> I recently read about VLC supporting casting to cast devices. How would this compare?

<comment><USER11> haven't checked the latest version but 1 month ago there was no chromecast support in the stable release channel

<comment><USER12> VLC 3.0 was released last week and has Chromecast support. It's been in the beta channel for a long time, but apparently took a lot of work to get edge cases sorted etc.

</comment></comment></comment><comment><USER13> This is great!

I personally have been using [https://getvideostream.com/](https://getvideostream.com/) which I like, but awesome to see an open source alternative.

</comment><comment><USER14> I find it sad that this took several years to make, only because I had hoped when Google released the chromecast, it would be the "no-brainer" way to stream media to your TV. Sadly, it didn't work out that way.

</comment><comment><USER15> There's also this python based cli caster [https://github.com/skorokithakis/catt](https://github.com/skorokithakis/catt)

<comment><AUTHOR> nice! starred.

</comment></comment><comment><USER16> Can you cast a portion of your screen with this? What I'd love to do is cast a website which I can use as a "dashboard" with custom content

<comment><USER17> Why not just use the Chrome extension?

<comment><USER18> Not the GP: Maybe because you need to install Chrome to use that.

I have a Chromecast, but don't use/have/want Chrome.

</comment></comment></comment><comment><USER19> Anyone know of something similar for Windows?

<comment><USER20> VLC since 3.0 is supposed to support Chromecast

<comment><AUTHOR> yeah, but they don't support subtitles as far as i can tell. my frustration w/ VLC's casting is what drove me to write this.

<comment><USER21> Is there something amiss with VLC's Chromecast abilities? I haven't had a chance to test it out yet, but was really happy to see it in the changelog

<comment><USER6> The new VLC never finds my chromecast, and this does right away. Apparently a lot of people are having nonspecific trouble with the new VLC feature.</comment></comment></comment></comment></comment>


Reimagining of Schrödinger's cat breaks quantum mechanics, and stumps physicists - <AUTHOR> https://www.nature.com/articles/d41586-018-06749-8 <comment><AUTHOR> The end of Copenhagen Interpretation?

> _The most common way of understanding this was formulated in the 1920s by > quantum-theory pioneers Niels Bohr and Werner Heisenberg, and is called the > Copenhagen interpretation, after the city where Bohr lived. It says that the > act of observing a quantum system makes the wavefunction 'collapse' from a > spread-out curve to a single data point_

> _Now, Frauchiger and Renner are shaking physicists out of this comforting > position. Their theoretical reasoning says that the basic Copenhagen picture > — as well as other interpretations that share some of its basic assumptions > — is not internally consistent._</comment>


Detailing the CMU Tor Hidden Services Attack and Tor's Response - <AUTHOR> http://fusion.net/story/238742/tor-carnegie-mellon-attack/ <comment><AUTHOR> Support Tor's first donation campaign.

Become a crowdfunder.

[https://blog.torproject.org/blog/our-first-real-donations- ca...](https://blog.torproject.org/blog/our-first-real-donations-campaign)

<comment><USER2> I can't believe they're using PayPal of all things...

<comment><USER3> You can play via bitcoins if that is your thing:

[https://www.torproject.org/donate/donate- options.html.en](https://www.torproject.org/donate/donate-options.html.en)

</comment></comment></comment><comment><USER4> So who is going to get the billing record for all those hosts they spun up? Hard proof should not be that hard to come by, so I'm just waiting to see that. I am more likely to believe Tor than CMU because of the way the research was pulled, and it would be nice to pin them to it.

</comment><comment><USER5> Useless web site. Can anybody please post the text of the article so that it is readable??

<comment><USER6> [http://pastebin.com/6938UxS0](http://pastebin.com/6938UxS0)

TL;DR (2014):

Feb: Understaffed Tor minimized security warning. _" Activity in the past has looked suspicious at the time, but ultimately did stuff that helped advance our art."_

May: CMU researchers announce breaking Tor, ignoring potential ethical violations. Blackhat talk cancelled; CMU & FBI begin 'not the droids you're looking for' responses.

Jul: Emergency fix to Tor to block CMU vulnerability. CMU researchers stop corresponding with Tor project.

Nov: FBI crackdown

</comment></comment><comment><USER7> TLDR: CIA funded people angry at FBI funded people for breaking their toys. CIA funded people react only after being deanonymized __personally__.

<comment><USER8> Do you have a source on Tor being funded by the CIA?

It's disingenuous to say that Tor reacted only after being deanonymized personally:

1\. It was well known that Nick Mathewson worked for Tor long before this attack.

2\. Tor added code that allowed them to detect the attack before they knew their IPs were deanonymized: that's the only way they found out their IPs were deanonymized.</comment></comment>


MySpeech.js – small library for web speech API - <AUTHOR> https://github.com/hermawan22/mySpeech <comment><USER2> If it meets the guidelines, this might make a good 'Show HN'. Show HN guidelines: [https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)

<comment><AUTHOR> Ah, thanks for your info. :)</comment></comment>


Elon Musk seeks "specific amendments" to recommend to Trump on immigration order - <AUTHOR> https://techcrunch.com/2017/01/29/elon-musk-seeks-specific-amendments-to-recommend-to-trump-on-immigration-order/ <comment><USER2> The problem with this reasonable seeming approach is that it accepts the frame.

Trump/Bannon present the following frame: we can combat terrorism by banning refugees from Muslim countries. This claim is factually incorrect, and moreover it is an attempt to set up an "other" group (Muslims) as an enemy. Keep in mind Trumps unapologetic claim on the campaign trail:

        Donal J Trump is calling for a
        total and complete shutdown
        of Muslims entering the United States
        -- Donald J Trump, Dec 2015

By proposing "specific ammendments", Musk says the framework as correct, but the details are wrong. In fact, the opposite is the case: the framework is wrong, as well as the details. The entire order should be rescinded, without qualification.

Musk and other SV commentators should know better than this, and not lend their credibility to un-American actions by the administration.

<comment><USER3> I'd like to correct the quote:

      Donald J. Trump is calling for a
      total and complete shutdown
      of Muslims entering the United States
      until our country's representatives
      can figure out what is going on. [1]

That's why the current order has set duration of 90 days, and it's announced that subsequent immigration from the affected seven countries will be allowed, subject to tougher vetting.

[1] [http://www.cbsnews.com/news/donald-trump-calls-for-total- and...](http://www.cbsnews.com/news/donald-trump-calls-for-total-and-complete- shutdown-of-muslims-entering-u-s/) \- first hit in Google search.

<comment><USER4> What is going on is that muslims such as the Iraqi government and Iraqi army are fighting IS tooth and claw right now. An Iraqi that had family members murdered for helping the US has been prevented from getting on a plane to the US. This ban is affecting thousands of people who support the US and some who are risking their lives to help the US fight terrorism.

Trump had no idea what he was doing when he made that quote, has no idea now. What better idea in 90 days? Cancel this order? Meanwhile his actions are increasing the risks to the US. This is all about posturing and victimising a minority that's easy to demonize and nothing to do with security.

<comment><USER5> The same kind of better ideas like the GOP's perfect replacement for "Obamcare" of course. It's going to be great. Trust me.

</comment></comment></comment></comment><comment><USER6> By "specific amendment" he should be saying "throw it out". This policy is misguided and evil from the ground up. If this program had been in place twenty years the number of terrorist attacks it would have prevented is zero.

<comment><USER7> Saying "throw it out" isn't productive. Trump won't back down because that means admitting a loss. You get to, in the short term, choose between a substantial win (finding a better middle ground) and a feel-good victory (saying "screw you" and living with this policy).

<comment><USER8> The only winning move is not to play. Interacting with Trump's government, unless necessary for legal reasons, is stupid and makes it harder for everyone else to publicly denounce the current government.

<comment><USER9> Musk is a CEO of multi-billion dollar companies, disengagement for 4 years is not a thing, not with the US government.

An activist can tune-out and entrepreneur has to adapt.

<comment><USER10> It's also a skill to engage with people you disagree with on certain issues, or even if you dislike them personally.

These are basic life skills people.

Edit: s/work/engage

</comment></comment></comment></comment></comment><comment><USER11> I think that Musk is trying to be diplomatic. I think he's fully against this measure because:

1) As I know Tesla does hire foreign engineers

2) He, himself is an immigrant to the US, and he was - if not an actual illegal alien, at least in a gray area immigration wise - at some point while building x.com

<comment><AUTHOR> Yeah I agree I think he's against it but realizes the best we can hope for, at least going through the administration which he has access to, is offering amendments to soften the executive order.

I get the feeling Musk is trying to do what he can, the best he can, but since he's not directly saying it needs to go away he's going to catch hell for it. I think he's in a very difficult spot either way he goes.

<comment><USER12> > _but since he 's not directly saying it needs to go away he's going to catch > hell for it_

That's, unfortunately, the Copenhagen Interpretation of Ethics[0] at play.

"The Copenhagen Interpretation of Ethics says that when you observe or interact with a problem in any way, you can be blamed for it. At the very least, you are to blame for not doing more. Even if you don't make the problem worse, even if you make it slightly better, the ethical burden of the problem falls on you as soon as you observe it. In particular, if you interact with a problem and benefit from it, you are a complete monster. I don't subscribe to this school of thought, but it seems pretty popular."

[0] - [https://blog.jaibot.com/the-copenhagen-interpretation-of- eth...](https://blog.jaibot.com/the-copenhagen-interpretation-of-ethics/)

</comment></comment></comment><comment><USER7> Part of the problem is "a 1952 immigration law [giving] the chief executive the power to bar 'any class' of immigrants from the country if allowing them is deemed 'detrimental to the interests of the United States'" [1].

[1] [http://www.politico.com/story/2017/01/early-wins-against- tru...](http://www.politico.com/story/2017/01/early-wins-against-trump-anti- terror-immigration-order-may-not-last-234348)

</comment><comment><USER13> I think this can be viewing as harm reduction, analogous to giving needles to drug users. Sure it's easy to just say "They shouldn't be banning immigrants", but if they will anyway, we might as well make sure they do it less harmfully.

</comment><comment><USER14> If that's his angle, rather than helping an ignoble command become more implementable (and directly playing into a door-in-the-face strategy), I'd love to see some suggested amendments that make it more vulnerable to legal attack.

</comment><comment><USER15> Suggestions on the vetting process will have a potentially greater effect. The obvious goal is the person(s) should on average be a net benefit to the United States. What that means is what needs to be hammered out and it's unknowable if that's the standard. More basic tests like freedom of speech are what I want to be used.

</comment><comment><USER16> Because the self proclaimed "born negotiator" hasn't done his job and negotiated before making decisions, a better one has to step in.

</comment><comment><USER17> The muslim ban is probably as effective as the internment of the Japanese during WWII ordered by Roosevelt.

Which under Carter have been proven totally illegitimate and useless.

Well, segregation in the USA based on religion (Feynman barred from a PhD in Princeton for being jew) or colour of skin (until 1969), or birth (slavery- native americans) is part of the dark side of its history. Nothing new under the sun.

Question, is this a new cause of secession between rural and urban america growing up? I mean, if history repeats itself ...</comment>


Man Killed by Industrial Robot, Hardly a Terminator Uprising - <AUTHOR> http://www.forbes.com/sites/theopriestley/2015/07/02/is-this-a-killer-robot-uprising-hardly/

<comment> anti-shill that robot decided his fate in a microsecond: extermination... and so it begins...</comment>


Show HN: Kind of reinventing Emacs and Elisp – looking for feedback - <AUTHOR> https://github.com/zeo1/u <comment><USER2> uh...

my first piece of feedback is that you need to actually have a better strategy than "emacs w/ JS" if you want any real feedback

At the moment, there's literally nothing to give feedback on

Congrats for starting it, I guess?

Why do you think this will work where other attempts at replacing emacs has failed? Why JS over other options? What benefits over emacs? What architecture? Why that architecture over emacs current one? What are you plans on integrating with other editor plugins, if any, to steal your way into having an ecosystem before people fully invest in this? etc

I mean hell, the most basic question: Why do you even want to replace/reinvent emacs?

<comment><AUTHOR> Thanks, v0.2 will be at least usable.

Actually, I don't just want to replace emacs, we'll see.

<comment><USER2> I meant you need to actually state what you're planning to do and why; not that it actually needs to be useable before it can criticized.

Afaict, you've expressed almost nothing about what this program intends to be, other than "emacs"

</comment></comment></comment><comment><USER3> It's a modal editor. Philosophically and practically antithetical to emacs and its mission</comment>


"Nico-Nico-niii" Is Not Allowed on PayPal (2014) - <AUTHOR> http://zakitakubu.com/2014/12/09/nico-nico-niii-is-not-allowed-on-paypal/ <comment> chao- Possibly related to a bunch of stock phrases/tokens that aren't allowed? As referenced in recent "ISIS Beer Fund" articles?

[https://www.inverse.com/article/13700-i-wrote-isis-beer- fund...](https://www.inverse.com/article/13700-i-wrote-isis-beer-funds-in-a- venmo-memo-and-the-government-detained-my-42)

</comment><comment><USER2> にこ にこ に〜</comment>