saarons

If anyone remembers gToons from Cartoon Orbit there's also this: https://gtoons.app

CTO of Modern Treasury here. We're very happy with the quality of the client libraries being generated by Stainless. It also integrates nicely into our workflow, we've got the releases almost fully automated whenever new API routes are added or changed.

Big fans of Vanta over here. Compared to everything else in the market, they were clearly the furthest ahead for our SOC2 needs.

It was also done in The Animatrix [1]. In order to defeat the robot uprising, the world agrees to block out the sun and starve the robots of solar power. It also backfires on them.

[1] https://en.wikipedia.org/wiki/The_Animatrix#The_Second_Renai...

I'm sure everyone's setup is different but I did this for about 8 years and had to stop recently due to a variety of problems. The first being the lack of support for group messaging. I couldn't send group messages at all but what was even worse was that when I was part of group messages I would receive the messages individually as if the person was texting me directly. My system could mark them as being group messages but I couldn't see the other recipients so there was no way of knowing who else was in a thread until other people started texting and then could piece together the group from context.

Also some services straight up refuse to send SMS to cloud phone providers meaning you can't sign up for certain services that needed a verified phone number (unless they had an option to receive a call with the verification code which worked like 25% of the time).

Dialing was another huge issue, you can somewhat intercept outbound calls on Android but the system is buggy so I had to find other methods. Since I had integrated my SMS/MMS messaging with Slack (one slack channel per phone number) I created a /dial command that would call my phone and then when I answered it would transfer me to the person I wanted to call.

Happy to answer more questions about it but I highly recommend people think about all the consequences before moving their main number over.

Modern Treasury (YC S18) | Software Engineer | San Francisco | Full-time | ONSITE

We're looking for Full-Stack Engineers to join our Engineering team. In this role, you will build innovative payments products that delight both engineering and finance teams. As one of our first engineers, you will help shape the engineering culture of a fast-growing startup.

https://angel.co/company/moderntreasury/jobs/617123-full-sta...

On the consumer banking side I would agree with you, not many individuals have complex enough banking needs where programmatic access would be a value-add. However if you look at businesses, any company doing more than (let's say) 50 bank-to-bank payments a month I think would benefit from being able to automate their bank account interactions in some fashion.

Disclosure: I work on banking APIs

Modern Treasury (YC S18) | Fullstack Engineer | San Francisco |ONSITE | Full-Time | https://www.moderntreasury.com

Modern Treasury is looking for a Fullstack Engineer to help us automate the world of RTP, ACH, Wire, and Check. Currently our platform supports 5 major commercial banks in the United States and we plan to double that in the next 6 months. Fullstack engineers who join the team will be responsible for designing new features and implementing them into our web application and API.

Our stack: Ruby on Rails, React, Postgres, Redis, AWS, GitHub, Buildkite.

Apply here: https://angel.co/company/moderntreasury/jobs/617123-fullstac... or reach out to me sam [at] moderntreasury.com

We've heard (unofficially) the cap will be raised over time.

On the bank side, one of the main providers offering RTP payments to businesses right now is JPMorgan Chase. If you have a commercial account with them, you can originate RTP payments.

Historically Americans have been wary of handing out their bank account information because that's all the information needed for a bad actor to issue an ACH debit and pull money from your account. The NACHA guidelines have very strict rules around this and the payment protections are rather strong but it's still a pain to deal with as a consumer. RTP itself is non-reversible so when someone sends you an RTP payment it clears instantly and can never be pulled back as it can with Check and ACH payments.

"because they can" is probably the best answer. Before RTP, which is still rolling out, wire tranfers were the only way to do same-day, non-reversible, high-value payments. On occasion we also see that wire transfers being sent manually need what's called "repair", as in the sending party didn't put enough information in the wire so the sending bank or receiving bank have to go get a human being to figure out what went wrong. Repairs and rejects add to the operational complexity of wire transfers and probably contribute to the higher end-user cost of sending one.

CTO of Modern Treasury here. Banks are actually starting to setup a new payment system between themselves called Real-Time Payments (RTP) which has a lot of the same benefits as wire transfers. RTP is 24/7, instant, and (from our experience) much cheaper than wire transfers. It's starting to roll-out across more banks and currently ~50% of bank accounts can receive RTP transfers [1]. I just cashed out on Venmo the other day and their instant transfers are going over the RTP system. Other than coverage not being complete, one of the main downsides is the $25,000 cap which means that for higher dollar volumes people will likely choose a wire. If you're sending $1mil, then the $35 wire fee doesn't seem like so much in comparison.

[1] https://www.theclearinghouse.org/payment-systems/rtp/institu...

Totally agree on the interest use case, that's exactly where precision beyond 2 decimal places is needed. For payments specifically it makes sense to keep it at 2 because all the payment systems in the US have that precision. When we do build support for ledgers we've considered a few approaches for how that might be serialized. For example we sometimes deal with MasterCard data that tags every amount with an exponent field so something like 1.2345 might be serialized as

  { "amount": 12345, "exponent": 4 }

  { "amount": "1.2345" }

CTO of Modern Treasury here, like the other replies said it's much safer to use integers so we can bypass all the complexity (and gotchas) of floating point.

The lack of acks is why most companies receiving money through ACH will "season" the transactions for a set amount of time. Most of the returns occur in the first 3 business days so most seasoning periods are just around that long. The reality is you can receive a reject up until (I believe) 60 days after the transaction date. I've seen a lot of companies be a little smarter here and reduce the seasoning times for repeat users using the same source bank account. It is a fascinating system to work with every day. Wire transfers are their own bundles of fun too.

I love these types of videos that dive into the nitty-gritty of how certain games work. I wish the author would have explained more why there is no position that the coin spawner works correctly in. Are they saying that while playing the game there's no way to move it, or that even if the coin spawner were placed correctly (on the ground) it would still not work?

I wish I had something like this sooner. I decided to go with Plivo for a side-project of mine and while my experience has been pleasant I really miss MMS support. I'm going to take some time going through this list evaluating different MMS providers. Anybody have any experience with a particular company on this list with MMS that they enjoy?

So I've actually been doing this in various forms for the past few years. Mind you I actually chose to go with Plivo (a competitor) instead of Twilio, a decision I'm still thinking about to this day (MMS primarily). The way it works for me is I actually use Slack as the interface to my contacts. Each person is their own private slack room. I use it just like any other, I send them slack messages and it sends them a SMS and vice-versa. So far it's been pretty great, I get to take advantage of all of Slack's clients and I just write the code that transits the messages using the Slack API. What's really fun is that I'm starting to allow slash commands so that my friends can use some of them in the rooms with me and we can have sort of a shared chat-bot experience over regular SMS.

If anybody is interested in seeing the code, some parts of it are already open source[1]. The most interesting piece is the dialer, as someone in the thread pointed out, setting the caller ID on the outbound is tricky. On Android there are actually APIs that can intercept outbound calls, manipulate the number, and make the call to my gateway and then input the actual number as DTMF codes followed by a terminator. It doesn't always work but in 95% of cases I've never had a problem.

[1] https://github.com/saarons/ward

I went to high school on Fort Ord land and I think the primary reason for it being a tough sell is the unexploded ordnances. Every year we were given a presentation on how to identify old landmines and avoid them. Even with the recent cleanup efforts it's still somewhat dangerous and only the fringes of Fort Ord (where cleanup happened a while ago) are being actively developed.

I'm always curious how taxes like this are enforced, presumably the City of Chicago can just sue companies like Netflix and Spotify if they think they're not getting their share. If I have my own small-time video streaming business does that mean I have to worry potentially about any municipality coming after me for unpaid taxes? That could get a little nuts if there are thousands of cities that could potentially have ordinances like this. How do I keep up? Am I just not understanding the scope of this?

This would be great in the Android world. There are dozens of SMS/XMPP chat apps that all take a slightly different approach to chat interfaces. Some have implemented material design makeovers, but there still seems to be slight differences amongst the ones that have. Something like this for Android would go a long way to help the apps that still haven't made the transition.

I've taken a few classes with some of the authors of this project and they are all amazingly talented. I remember Alex gave a presentation about a year ago on this and he mentioned how hard it was for them to wedge C++ into the Linux kernel just so they could get I/O Kit to work. It was also awesome to see the iOS Stocks app running on a Nexus 7. From what I saw it worked pretty well and aside from the uncanniness of the whole experience, it was pretty amazing to see a fully-working demo. Keep up the good work guys.

Plivo. I use it to provide voice/text services for my personal line and I couldn't be happier with them. I think the price is slightly cheaper than Twilio and you get a similar set of features. I've run into the occasional quirks here and there, but I've always been able to get great support right away.