I'm Nick Slaney CEO and Co-Founder of moneydevkit, AMA \ stacker news ~AMA

pull down to refresh

I'm Nick Slaney CEO and Co-Founder of moneydevkit, AMA

22k sats \ 31 comments \ @nps 24 Nov AMA

hi stackers,

Last week my company, moneydevkit launched it's public beta. moneydevkit is a developer tool that lets anyone globally take payments using Bitcoin and lightning.

With so many more people being able to create value online recently, the boundaries of traditional payments are becoming more and more apparent. We're using self-custody lightning to give payments access to the 80% of the population that cannot use stripe. With this sort of use case in mind, our goal is to make moneydevkit as easy to use and integrate as possible.

Previously, I was at Block leading the c= team. The node my team built, now known simply as block is one of the largest volume nodes on the lightning network, and somewhat famously gave Block a 10% return on the Bitcoin we put into it :)

view all related items

10 sats \ 1 reply \ @k00b 24 Nov

MDK is focused on the receiving use case, but do you imagine a future where you'll support sending use cases?

100 sats \ 0 replies \ @nps OP 24 Nov

We spent a lot of time thinking through "Payouts" from mdk as having an easy way for us to let someone get money out of mdk using our dashboard while staying self-custodial was a bit of a puzzle :)

Exposing a send API for a more advanced users to use in their app actually shouldn't be too hard. It just wasn't our focus at first.

10 sats \ 2 replies \ @grayruby 24 Nov

This is interesting. Full disclosure I am not a developer but I vibe coded a fantasy sports app to host sports contest for stackers here on SN and so far we are just testing some contests in it and essentially using it as an administrator to track picks, results etc. Eventually I want to enable lightning payments within the app. Do you think your project would be an easy way to do that?

309 sats \ 1 reply \ @nps OP 24 Nov

Exactly the sort of thing we've set up mdk for. If you're on something like vercel / netlify, you'd be able to do it today, just ask your agent to add payments using moneydevkit. If you used Replit, we have something coming for you soon :)

Feel free to jump into our discord and ask questions if you need help working through it!

78 sats \ 0 replies \ @grayruby 24 Nov

Yes, I used replit.

10 sats \ 1 reply \ @0xbitcoiner 24 Nov

I get that you need to make money for your work and that some fee has to be charged. The question is: how did you decide that 2% per transaction was the fair amount?

22 sats \ 0 replies \ @nps OP 24 Nov

Our main customers are not served well by traditional payments, and moreover are not super Bitcoiners into running their own nodes. Compared to the options these people realistically have access to, 2% is 50 - 70% off their next best option.

10 sats \ 1 reply \ @Scoresby 24 Nov

Is this something you see primarily being used by apps and webstores, or do expect to see people using moneydevkit as the backend for things like point of sale systems?

102 sats \ 0 replies \ @nps OP 24 Nov

Our first use case is easy to add payments for AI assisted devs / vibe coders.

But the way we've packaged LDK, we can fit it into a lot of use cases. POS could be cool :)

10 sats \ 1 reply \ @Scoresby 24 Nov

Hi Nick! I'm curious if moneydevkit could work with a woocommerce or shopify plugin. I've had a little webstore for a few years and lightning is always a struggle. A super simple plugin that doesn't make me struggle with a lightning node would be awesome!

102 sats \ 0 replies \ @nps OP 24 Nov

Definitely something we want to look into 👀

10 sats \ 1 reply \ @0xbitcoiner 24 Nov

Good job, congrats!

Could you explain better what the term ‘serverless’ actually means in practice?

135 sats \ 0 replies \ @nps OP 24 Nov

It's funny because we've had a few devs in the Bitcoin community scoff at the term "serverless" :)

Serverless does not mean there are no servers! Mainly, it means that the developer doesn't have to think about the servers. The service provider handles it all for them, and typically they're also actively spinning up and down the functions a developer deploys on an on demand basis, which is very cheap for them.

Vercel and Netlify are the platforms we're thinking about when we're talking about serverless. They let you link your code via github and deploy for free very quickly, no setup or monthly fees. In the background they're spinning up and down your functions on demand.

With mdk, we've shoehorned LDK into a package that can deploy natively on these platforms. This means you get all the benefits of running a self-custodial lightning node without the cost / complexity of hosting one yourself. It's free to start and scales easily with your application.

0 sats \ 1 reply \ @k00b 24 Nov

What were you doing before joining Block? What made you want to start a company?

100 sats \ 0 replies \ @nps OP 8h

I'm a mechanical engineer by trade and did consumer product design for the first 10 years of my life. That's what brought me to Block, I helped with the Square Terminal, and did early prototyping for what became the handheld.

But I'm a class of 2013 Bitcoiner and alongside my product design career I was always running nodes, miners, and on Bitcoin twitter.

At Block, I managed to get on the early Bitkey team, and at the time was also going deep on lightning. While we were designing and building Bitkey prototypes I was pitching for c= within Block, and the rest is history.

I would call my time at Block my first founding story, because we started c= from scratch, albeit with a bit more funding and support than most startups.

My father was an entrepreneur, so let's say the suggestion to start a company was always there :)

10 sats \ 2 replies \ @fanis 3h

Hey @nps! Congrats on the launch, I've been playing a bit with MDK in Vercel today and it's going great so far.

The only thing a bit confusing at first, at least to me, was the webhook. I wanted to test things locally first, but of course that didn't work because the node was not reachable on a public endpoint. Do you have any plans to simplify this first step, for example with a proxy between localhost and a temporary domain hosted by MDK?

Also am I correct in assuming that it's fine to run two instances at the same time with the same seed (one local, one deployment), since on payment reception the MDK infrastructure will just reach out to the deployed instance? But then how does the local instance knows the payment succeeded? I tried and it does notice the payment arrived.

Thanks!

100 sats \ 1 reply \ @nps OP 2h

Hey thanks for giving it a try!

Local testing is on our list for near term priorities, for a v1 we're thinking we'll add a button to mock the webhook so you can be sure everything else is set up right before you deploy.

We're working through multiple websites / locations as well. Your example with local / deployed should be fine. The state for the node is stored encrypted in remotely in VSS linked to your seed, so where the node spins up does not matter so much.

0 sats \ 0 replies \ @fanis 1h

Thanks for your answer! VSS makes a lot of sense here, truly great stuff 🔥

10 sats \ 1 reply \ @k00b 24 Nov

What was the most surprising thing you learned leading c=?

0 sats \ 0 replies \ @nps OP 24 Nov

The scale of real payments on the lightning network. It took us by surprise (in a good way).

10 sats \ 1 reply \ @k00b 24 Nov

It seems like what most people want in terms of lightning UX is an onchain-like control of funds with varying degrees of trusted infra/channels/etc.

Do you agree with that?

0 sats \ 0 replies \ @nps OP 24 Nov

I think people who know to search for lightning bitcoin payments right now have better concepts of on-chain than lightning.

But I think most people don't even know what on-chain is :)

I agree that most people just want payments to just work for them.

10 sats \ 1 reply \ @k00b 24 Nov

Is MDK competition for greenlight? Or am I thinking about this wrong?

0 sats \ 0 replies \ @nps OP 24 Nov

There's some differences. Technically, with mdk the node and keys are on your infrastructure, not ours.

We spent a lot of time focusing on the developer experience for mdk. When a developer thinks "I want to add payments" the products they pick up are very full featured. They don't just get the credit card network send / receive API, they get a lot handled for them. To me this is the biggest difference, you don't need to know anything about Bitcoin to get a checkout page and get paid.

10 sats \ 1 reply \ @billytheked 24 Nov

How does your current project differ from using a BTCPayserver with the Blink wallet integration, where the server is self hosted but lightning payments are received to an external (custodial) lightning wallet?

0 sats \ 0 replies \ @nps OP 24 Nov

It's a little different!

Instead of needing to run / self-host, you can just include the moneydevkit library into your project and deploy from there. Most of our examples just have us asking the AI that's helping to build the website "hey add payments with moneydevkit"

moneydevkit is self-custodial, and the node / keys live on the same infrastructure your website is deployed to, but you don't need to really think about the node really. You can just treat it like another dependency to add to your web app.

With moneydevkit, you can easily pay out to Blink or any other wallet / exchange that supports LNURL or Bolt12.

0 sats \ 4 replies \ @justin_shocknet 24 Nov

this will get a few people to rush to their charts

serverless lightning node

This is a little red-flaggy / trustodial sounding, needs more explanation

0 sats \ 3 replies \ @nps OP 8h

The node and keys are in your (serverless, typically) infrastructure and control. No trustody, it's all you.

0 sats \ 2 replies \ @justin_shocknet 5h

Keys only do signing, that doesn't mean much if it signs anything without a policy engine or if the invoices being served (a node is inherently a server even if its used like a client) are issued by someone else

That kind of dodge is even more red-flaggy

I assume the fee is collected with wrapping, so its entirely trustodial in that your service is who gets paid first and opaquely

0 sats \ 1 reply \ @nps OP 2h

Hm I get the feeling nothing will be completely satisfying here.

Your node creates the invoice, we do take a fee on the last hop, but we only get paid if you get paid.

We don't use a wrapped invoice, but even those are trustless as the provider is not able to collect any fees if the payment doesn't make it to you.

0 sats \ 0 replies \ @justin_shocknet 42m

Hm I get the feeling nothing will be completely satisfying here.

It's a first-principles thing which is why I'm trying to clarify, false claims seem to be the norm these days in Lightning given all the fake L2 astroturf. Seems no one wants to solve actual problems and just adds obfuscated trust instead... trying to gauge if this "serverless" thing is adjacent.

This piqued my interest because a Lightning node cannot be serverless, it is by nature a server at it must serve responses in the forms of invoices and signatures, so the question becomes where is the demarcation of your server and the server the user is running.

a wrapped invoice, but even those are trustless

That's not true, if you're serving the invoice the payer and the payee have no means of verifying that the invoice you issue is actually wrapped. Wrapped invoices can provide atomicity, but not trustlessness.

They're also pretty fragile and create forced channel closures so it is good you're not using them, using the hop to collect is a better design.

So I guess the question becomes, what is the user key actually signing and who's service is delivering the invoice? If your service is doing the logic, that implies a blind signing which is of no benefit to the user holding the keys. If you're the one delivering the invoices, thats still every bit as trusted as a wrapped invoice.