This is an option that all Nostr clients should have, not just this fork of Jumble.
š
https://jumble-spark.vercel.app/
ccnostr:npub1r0rs5q2gk0e3dk3nlc7gnu378ec6cnlenqp8a3cjhyzu6f8k5sgs4sq9ac nostr:npub1m4ny6hjqzepn4rxknuq94c2gpqzr29ufkkw7ttcxyak7v43n6vvsajc2jl nostr:npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl nostr:npub147whqsr5vsj86x0ays70r0hgreklre3ey97uvcmxhum65skst56s30selt nostr:npub12vkcxr0luzwp8e673v29eqjhrr7p9vqq8asav85swaepclllj09sylpugg
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?
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.
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 think Banco Libre works the same way š¤
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.
https://github.com/CodyTseng/jumble/pull/638#issuecomment-3477436664
This doesnāt sound self custodial to me. You donāt even control the keys.
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.
ā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?
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.
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.
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.
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.
It's so easy to go to docs and click on search button and make any question on https://docs.spark.money/start/overview
The search works like an IA. I'm sure all doubts can be easily answered there.
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 nostr:npub1cesrkrcuelkxyhvupzm48e8hwn4005w0ya5jyvf9kh75mfegqx0q4kt37c, 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.
https://nosotros.app. If you try, let me know what you think.
Maybe I'm just not adapted yet with the way the feed is showed. But I'm now liking it.
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 nostr:npub1cesrkrcuelkxyhvupzm48e8hwn4005w0ya5jyvf9kh75mfegqx0q4kt37c? Deveria.
Responder nested replies agora vai abrir um dialog no mobile.
Boa, pode mandar bala, jĆ” estou arrumando varias coisas aqui
