Login to reply
Replies (65)
Why? What’s special about it?
I think a self-custodial lightning wallet that runs inside a Nostr client without NWC it's interesting.
However, it seems that in the future this wallet will still be connectable to NWC in other clients.
Try it.
It runs a lightning node?
It's nodeless.
Read here 👇


Breez | Join the Breez SDK Beta Program
Be the first to try the new Nodeless implementation of the Breez SDK.
Doesn’t explain anything. How is it nodeless 🤨
Are you trolling me? 😓
No. I see a beta signup on that page. But it doesn’t explain how its nodeless
I'm sorry, I'm not a developer, I'm not paid by Breez or Spark.
It just seems like an interesting solution to try out in Nostr clients.
If you want to learn more, I think you'll be able to understand how to use it better than I can.
Have a nice day. 🫂🎨
Never mind I looked it up. It’s a swap from liquid to sats and from sats to liquid. So really you have a liquid wallet not a lightning wallet. :)
Nope. It's Spark, are Bitcoin, are lightning, no swap, not Liquid.
I think Banco Libre works the same way 🤔
It says so here


That's Misty Breez with Liquid. There's another SDK with Spark.
Oh. I’ll have to find it later. Unless you get a link. I’m tired 🥱
I have the same question. From a technical perspective, I can’t quite understand how Spark describes itself as nodeless and self-custodial. I hope someone can clarify this for me.

GitHub
Add Breez Spark Lightning Wallet Integration by dmnyc · Pull Request #638 · CodyTseng/jumble
Add Breez Spark Lightning Wallet Integration
🎉 Overview
This PR adds a trust-minimized Lightning wallet to Jumble using the Breez Spark SDK, ena...
This doesn’t sound self custodial to me. You don’t even control the keys.


“Spark operators” help facilitate transfer (by signing the transaction) so that means the user is one of the keys. What happens if the spark operators decide not to sign the transaction?
Who maintains the spark ledger? Isn’t that a trust system? If it’s not in a blockchain?


If my understanding of Spark is correct, then it’s quite risky that many people trust Spark’s claims of security and self-custody. I can accept sacrificing some security for faster transactions and lower fees, but we shouldn’t let users believe it’s completely safe and become complacent.
It sounds to me like someone else holds the keys and you’re one of the required multisig keys. But so many questions about the spark ledger and who maintains that.
Who generates these keys? Could the generator keep a copy for themselves? Where are the keys that belong to the user stored? It seems the user only has 12 mnemonic words, which aren’t the actual keys used for the multisig.
Exactly. What happens if they refuse to sign?
Too many questions. I’m not against it yet but I can’t rush into it without having all the answers.
Do these questions also apply to Arc?
This sounds like a contradiction. No ledger, but keeps a record. Is that not a ledger then? 🤨


Here’s my rough understanding, please correct me if I’m wrong:
Bob deposits funds into a Bitcoin address that’s controlled via multisig, with ownership held by Bob and Spark. When Bob wants to send funds to Alice through Spark, Spark generates new key shares and discards the old ones, and gives the new shares to Alice. Since Bob can no longer use the old shares on their own, ownership is logically transferred to Alice and Spark.
So, in theory, Spark doesn’t need to maintain a ledger. Whether it actually keeps any record, I’m not sure.
Thanks for the guidance, I have a rough understanding of how statechains work. But this seems different from what I’ve seen in the Breez Spark API. I haven’t seen anything about storing or using key shares, all I see are the 12 mnemonic words.
And Spark is a proprietary protocol with the company that runs it having exclusive control of who can be a service provider.
All while they can monitor all your transactions.
Phoenix? I will follow the developments with interest.
Kkk, proprietary protocolo? It's all opensource, anyone can create their own Spark entity with members you decides.
And yes, privacy is a problem that they want to improve.
It's so easy to go to docs and click on search button and make any question on
The search works like an IA. I'm sure all doubts can be easily answered there.

Welcome to Spark - Spark
yes, the protocol is tightly integrated with their infrastructure, and they basically control every aspect of it
oh also I just remembered they are the shitheads behind the "uma" protocol, which was an attempt to introduce KYC to lightning addresses and zaps
You know that Lightspark works with tradicional finance, banks and so on. Spark is opensource and a "gift" to the community, you can create your own federation if you want. Stop being a conspirator.
If they refuse to sign, you use the unilateral exit.
I’ve already spent quite a bit of time understanding Spark, and I don’t think I’m obligated to continue doing so.
If you’d like to convince me, please correct my misunderstandings from a technical perspective.
I think your are biased when the subject is Spark, so I think there's nothing I can do more to try to convince you. You have easy docs, search mode on docs in IA mode, you have videos that is not promotional videos. You have everything.
You think that the trust model is the same as a custodial solution, something that is very easy to understand that is not.
I understand that you have no interest in integrate it, and it's ok. Maybe someday if you have a really genuine interest to look on Spark with not a biased vision, you can change your opinion.
I believe I have a better understanding of how Spark works than you do. Over the past couple of days, I’ve thoroughly gone through the Spark and Breez API documentation, as well as reviewed the PR for integrating Spark. Only after this did I raise my concerns about Spark and why it is not a good fit for Jumble. If you think there’s an issue with my understanding, please point it out directly rather than making meaningless remarks.
Of course if you try to understand it, you will have better understand than me (you are more intelligent than me and you are a developer). This is the reason why I don't understand you came to the wrong conclusion about Spark.
It's not a question of being smarter or more knowledgeable, but rather that those of us who don't understand the more technical aspects shouldn't assume that others are wrong.
If Cody says he's studied it thoroughly and has doubts about Spark, it's likely that he's right, and he's not the only one who has doubts.
Even though I use Spark every day, I always remain cautious and simply suggest trying it out, then everyone can make their own choice.
I don’t care who’s smarter, nor am I certain that my understanding is correct. Spark’s documentation doesn’t reveal much about the technical details, so I can only arrive at a conclusion that makes sense to me based on the information I’ve read. Perhaps I’m wrong, and I welcome anyone to point out my mistakes.
However, if the assumption is that I’m simply biased or haven’t made the effort to understand, then there’s nothing more for me to say. After all, I’m under no obligation to investigate this, and I’ve already done more than I needed to.
I read documents, I saw many interviews.
My conclusions 1- :
Or Spark is spending a lot of money to create a protocol with the same tradeoffs of a custodial solution, something that doesn't make any sense in my mind. Or they are lying, what doesn't make any sense too.
My conclusions 2. People who are capable to understand don't really want to understand how things works. The reason: I have no idea.
The things people in my opinion are right concerned about Spark: Privacy.
Working on a new one as we speak.
Which one?
You’ll see…
Yes, but I want to know now, haha.
I'm starting to like nostotros client from @Cesar Dias, because cache thing, but I don't like the way the feed is showed.
Maybe you could try a PR for Spark integration on Nosotros client.
Haven’t tried that one yet. Will have a look.
nosotros.app
A decentralized social network based on nostr protocol
Maybe I'm just not adapted yet with the way the feed is showed. But I'm now liking it.
When you’re ready you can fork mine if you want.
Yes, definitely I don't like tree feed, haha.
Tree replies you mean? the threads feed aren't really a tree, should I add a option too render tree replies as flat? I was just doing some improvements / fixes right now.
Eu vou começar a abrir uns issues mas as primeiras coisas que me incomodaram é ter o feed thread mostrando só as respostas das pessoas que eu sigo. Eu gosto de Notes+replies. Outra coisa que não gosto é de ver a nota de alguém que não sigo respondendo uma que sigo, de forma expandida. Enfim, eu estou bastante acostumado com o modo do feed do Jumble. Eu gostaria de algo mais parecido com o modelo do Jumble.
Olha como isso é chato:
O botão de responder escondido.


Hum, essa mensagem acima não mencionou vc @Cesar Dias? Deveria.
A de cima não foi, optei por não marcar todos em cima da thread pra não virar notification hell, mas acho que devo dar uma opção pra isso, pra notificar sem marcar.
Sim, essencial.
Boa, pode mandar bala, já estou arrumando varias coisas aqui
The historical record of every spark transaction published by a centralized entity? Can’t see that going wrong.
Responder nested replies agora vai abrir um dialog no mobile.
Zeus does the same and way better than Phoenix.
Better privacy and better fees
Yes, but I think it doesn't run on my phone. I have other lightning wallets.


