pull down to refresh

Very very nice work. Congrats, and thank you so much for doing what you're doing. I wish you much success with this business.
Your post prompts two brainfarts...

1️⃣

You know what would be an even smoother UX for this escrow?
If the e-mail address and the lightning address were the same. This has come up in other threads but this flow shows it off quite well. Imagine rigging up payments and receipts of digital services, SaaS, etc, to an e-mail address that worked on LN and vice-versa. I hope somebody is working on this. I'm not smart enough, but I'd donate to such a cause/project. Think about how much overhead could be eliminated with a protocol/convention/tool ontop of LN+e-mail, for those using a local e-mail client with configurable rules and a wallet tied to it.

2️⃣

@k00b - I find myself upvoting on SN for two reasons. 1 - donating to the project or dev (if the OP claims to be the dev in their bio, I just trust it) and 2 - upvoting the content itself. Something to mull. I wonder if the web-o-trust thing you have cooking, could let us build a trustworthy index of projects that could get tagged on posts. Eg. this project could get tagged #LightningEscrow.io. Maybe a little ⏩ link beside each post could optionally route some sats to the project's wallet rather than the curator. If it worked, maintainers would get paid for communicating releases/news/demos. Plus, you could then filter the content based on project. You could see a history of posts related to that project. Just my 2 sats.
reply
#2 is a cool idea, i had brought up to @koob early that i felt weird posting other peoples content and reaping the sats.
reply
I was thinking about this again the other day. One way we could do this is that domain owners (e.g. owner of lightningescrow.io) creates a DNS TXT record that says which SN user they are and then any content shared from their domain would give them sats to their wallet.
This wouldn't work for medium or substack posts and things like that. It also would be tricky if the user wasn't technical.
Perhaps the simplest solution would be letting the user tell us who the sats for the post should go to.
reply
Thank you! I am glad you find this useful!
The login with LN is a tricky question; eventually you will be able use it to log in. However with the current model, you would still need to provide an email address so we can send notifications about transaction updates and actions that need to be taken for the transaction.
reply
Hey everyone, for the past 5 months we have been working on LightningEscrow - A fast, secure, and affordable escrow service using the lightning network; we are non-custodial and open source.
The version we show in this demo is still in beta, however we plan on having a consumer friendly version by Q3 of this year.
Join the waitlist at LightningEscrow.io and be sure to tell your friends!
reply
Q3? That is a long time to wait!
reply
We are launching in Q3 so we have enough time to smooth things out and improve the process to allow anyone to use it with ease.
In the meantime, if you want to try it out yourself, you can visit app.lightningescrow.io Note that it is still in Beta
reply
Thank you, I will give it a try
reply
I saw your post on the r/lightningnetwork subreddit as well. Interesting project. Hope we will see more cool user friendly features in the future. Cheers.
reply
Thanks! We will definitely are making the UX / UI a lot more friendly and adding a lot more support for different transaction types.
If you have any suggestions or ideas, let us know :)
reply
This is good! Great work guys. Keep it up, ignore all the bullshit out there, is just a distraction.
reply
Thanks! : D
reply
Pretty slick but UX still confusing AF
reply
Yes, the ux is terrible. I'm only a backend engineer, I don't know how to build a beautiful GUI. But you know what's cool about building it the way I did? Reliability. If the buyer has a path to the seller, the contract is guaranteed to work. If he doesn't, the contract never happens. I decided to build something ugly and reliable and hire someone to fix the ui later if/when we get funding rather than build something pretty that only works sometimes. It's a trade-off but I'm confident that I made the right choice, because it's easier to make ugly software pretty than it is to make broken software work.
reply
Yes trust me I know exactly what you mean. I deal with a software that is in this very state! But what you built is amazing. Imagine using eBay and selecting ln as a payment!
reply
Thanks! Yes, the process is not very consumer friendly right now - what is important though is that it works. Once we launch, the UX and UI will be a lot more user friendly and allow the average person to use this with ease. We are still in beta and wanted to validate the idea before we further develop this.
reply
So help me understand here, is this 100% non-custodial? I've seen one example of a p2p trading tool using hodl invoices p2plnbot, but as far as I understand there's a very short period of time in which the server is acting as a custodial of funds in there.
How is this setup different?
reply
The server never takes custody of funds, not even for a second (unlike p2plnbot), but I hesitate to use the phrase "100% non-custodial" on what is essentially a 2-of-3 multisig.
From the buyer's perspective, the moment you hit "send" on your wallet you no longer have control over that money. It is now contractually locked in an htlc where the seller can take the money if the escrow gives him the preimage, or -- if the escrow does not give the seller the preimage -- the payment will time out within 2 weeks and the buyer will get his money back.
I'm not sure what to call that. It's not "100% non custodial" because you, the buyer, no longer control what happens to the money. It's also not "100% controlled by the seller" because he can't take the money without help from the escrow. It's also not custodied by the escrow at all, not even for a second, because all the server is doing is giving a preimage to the seller or withholding it.
The term Unchained Capital uses for their similar setup is "collaborative custody." That is the term that I think fits best.
reply
Cool.
Now the terms "custodial" or "non-custodial" are always put from the perspective of the service provider. You're custodial if you can, at any point in time run away with the money. You're non-custodial if that possibility simply does't exist.
As I understand here, you're non-custodial because you act as just any hop in the payment path.
reply
If this is made into an SDK, you could be inserted into the checkout flow of so many small/medium businesses. You can become the better business bureau of the bitcoin world. Basically the Venmo feature they added where you can pay a fee to have Venmo act as an escrow.
The 10x concept for this is very solid. Excited to see where it goes guys. @supertestnet 👍👍
reply
I absolutely agree! It has a rest api which is already fully functional btw >:D Any third party who wants to build on top of this can call the api commands and programmatically execute trades and/or refunds on behalf of their users, and we'll just take a 1% cut each time. (Well, right now we aren't taking any cut at all, but eventually we will.) I haven't documented the api but it's what the frontend uses so anyone can check the html to see how it works. For example, the code for creating a new escrow transaction looks like this:
function makeTx() { var buyer_email = document.getElementsByName( "buyer-email" )[ 0 ].value; var goods_or_services = document.getElementsByName( "goods-or-services" )[ 0 ].value; var transaction_title = document.getElementsByName( "transaction-title" )[ 0 ].value; var transaction_details = document.getElementsByName( "transaction-details" )[ 0 ].value; var fee_payer = document.getElementsByName( "fee_payer" )[ 0 ].value; var amount = document.getElementsByName( "amount" )[ 0 ].value; var params = "buyer_email=" + buyer_email + "&session_id=" + localStorage.session_id + "&goods_or_services=" + goods_or_services + "&title=" + transaction_title + "&description=" + transaction_details + "&fee_payer=" + fee_payer + "&amount=" + amount; var xhttp = new XMLHttpRequest(); xhttp.onreadystatechange = function() { if ( this.readyState == 4 && this.status == 200 ) { var json = JSON.parse( this.responseText ); if ( json.status == "success" ) { window.location.href = "/seller-payment.html?tx=" + json.id; } } } xhttp.open( "POST", "/settx/", true ); xhttp.setRequestHeader( "Content-type", "application/x-www-form-urlencoded" ); xhttp.send( params ); }
reply
and we'll just take a 1% cut each time
Don’t you have to kinda be officially partnered with businesses though? Because you seemingly need some information about the kind of transactions so you know how to fairly arbitrate them.
Like if you’re an escrow for particular products, you need to understand what is and is not expected. Or what the customer did or did not agree to.
reply
Don’t you have to kinda be officially partnered with businesses though?
No, it's an open api so other companies can integrate it without telling us.
you seemingly need some information about the kind of transactions so you know how to fairly arbitrate them. Like if you’re an escrow for particular products, you need to understand what is and is not expected. Or what the customer did or did not agree to.
Companies or individuals who integrate our api get nice easy api endpoints to settle or cancel payments themselves. They can create accounts on behalf of their users, display the qr codes, and do all the interactive bits for them, hitting the right endpoint when it's time to decide who gets the money. And yeah we just take a 1% cut every time (once we're out of beta) without needing to know what exactly is happening or what the contract is for.
I still need to document the api though and probably do a hello world tutorial and an explanation of some of the things developers can build on top of this.
reply
Ah! So any company that uses your contract also becomes the arbitrators.
I would imagine that you will want to also offer an arbitrage-as-service. To me, that is the 10x opportunity. especially since consumers want a third party that won’t be biased
reply
If this your thing supertest?
reply
Yeah it's my protocol, Tristan's website
reply
Yes, He is working with me on this project
reply
I'm very excited, this is what I've been waiting for from the lightning network! I suggest you add two things:
  1. LNAuth and browser notifications to retain anonymonity of both parties
  2. A hefty service fee for resolving disputes
reply
Great demo!