Nostr Web Client

nostr:nevent1qvzqqqqqqypzp9c36x46sp4r52zl7058696eqtp0y5r5rpsdn3jeq0ytt6rra0vpqyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcprpmhxue69uhkvun2daekstnwdaehgu339e3k7mf0qqsw4dkm79e3l78n0q79swveq8rj4pdkdueh6r2udxqvxdld0fsttagz9cnfz

Notice zaps require public mode till we'll have client side receipts: https://github.com/breez/spark-sdk/pull/389

Replying to

QnA

When nostr:nprofile1qyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcpr3mhxue69uhkummnw3ez6ur4vgh8xetdd9ek7mpwv3jhvtcqyryngphdstprzqvu78vkwqygfl0d78matge05d5tzzexpnrfrr62zjtkjyr writes, you should read.

🙏❤️

Replying to

Roy

I second that! Do your research. Do your due diligence.

Btw, by your definition, all the companies you listed above have "proprietary API", some of them don't even open source their code, but claim to be open source... So allow to lolz

Replying to

I would also encourage anyone following this thread to ask around at respected companies in Lightning like Lightning Labs, Blockstream, Phoenix, or others, and ask them about their opinion of using proprietary APIs like Breez and Spark, compared to using the Lightning Network as it was designed. You might find they say some interesting things in private, that they're too polite to say publicly.

I second that! Do your research. Do your due diligence.

Replying to

"we help Spark be more private"

A good actor would immediately recognize that LightSpark is building a closed, permissioned system, which allows them full surveillance, and would refuse to work with LightSpark until they showed a commitment to decentralization, privacy, and respect for the founding principles of Lightning and Bitcoin.

That's your blind spot, not mine. I think they are committed to an open network. They already executed on their commitment. They open sourced the SE/SO. They communicated a public roadmap wrt to privacy. I think you're completely misjudging because? You're not doing that with Arkade, you're not doing that with Phoenix, for some reason you're targeting David Marcus. I judge them based on their actions.

Replying to

Could be true to some extent, but the LSP system is OPEN. Anyone can run an LSP. Only Breez can run the Breez API and only LightSpark can run the Spark API. To compare LSPs to closed, proprietary APIs like Breez and Spark, and suggest that there are only some "tradeoffs" -- that's not cool. As long as people keep doing that, I'll keep pointing out how bad this is.

Not anyone can run an LSP. You need a lot of liquidity to run an LSP. I don't know what you mean by "proprietary API", the Spark SSP interface is public. The Spark SO is open source. You can run a Spark, an Ark or a Liquid federation. Yes, it's not easy to do, but the public interface isn't the showstopper here. It's the server management. Let's be honest, since we're operating an LSP, and interfaced with other large LSPs - running a LSP is super challenging as well. Perhaps the barrier of entry is lower now, because WE pushed for a spec and WE open sourced our LSP code - but it's still super challenging. They same dynamics apply to Spark, Ark etc.

Replying to

Sure, those of us who are incentivized to do marketing for centralized, fully-surveilled, non-public solutions can continue to do that marketing.

Those of us who believe in freedom technology can also continue to make a fuss, especially when an app like Blitz, which was at one point associated with freedom technology, suddenly switches to sharing all of their user's transaction data with LightSpark.

Believe me, a lot of other Lightning participants are horrified, but a lot of them need to keep quiet because inevitably they will be looking for VC funding from the same funds which (unfortunately) are giving Breez money to market David Marcus' API.

I've been a Bitcoiner since 2012, don't need VC funding, so it's my role to explain to the community the danger of what you are marketing.

Roy 1mo ago 💬 2

I just think you're on the wrong track. I know we're a good actor and we help Spark be more private. We already do so. We're also pushing other sub-networks and the native Lightning tech itself.

Replying to

There may be surveillance attempts on Lightning, but I doubt they are having much success. And again, how can you possibly compare that "possibility" -- to the fact that, for example, the government of Israel can send David Marcus a list of IP addresses and say "give us all the Spark transactions associated with these IP addresses"??

They can send it to you as well and to any Lightning node as a matter of fact. There's a reason Phoenix and WoS pulled out of the US. Now they are back - but nothing has changed from a tech standpoint.

Replying to

There are some trade-offs, but comparing the tradeoffs you list above -- graph sync & trampoline payments issues-- to the tradeoffs of allowing LightSpark to track the IP address, balances, and transaction details of all of your users -- I don'r think you can honestly put those in the same "ballpark" (as we say in the USA.)

But that's exactly what it is. An LSP can track balances, IPs, transaction details as well. We should be honest about it.

Replying to

Again, an extreme edge case where one LSP has a private channel with both the sender and receiver, something which is very, very rare in practice.

Not extreme at all. LSPs are inherently centralizing. The more liquidity you have, the more users you will attract.

Replying to

i.e., "there are certain theoretical ways to break privacy on Lightning".

I agree. And I strongly doubt any of these would be easy to pull off, and I really doubt anyone is attempting to pull them off.

But it's not fair to compare this situation with a user being married to one HTTP endpoint, which they have to use to do ANYTHING, and that HTTP endpoint being controlled by just one company -- and a company, at that, with a speciality in "compliance"?

Roy 1mo ago 💬 2

1. It's not theoretical. Lightning is already being surveilled, don't be naive.

2. It's our job to allow users to switch LSPs and sub-networks at their will.

I don't subscribe to the FUD around Spark. I think it's a cool tech that will only get better and more private. And if not, the market will reject it and use something better.

Replying to

You are likely right about Phoenix, it's true I haven't looked into that implementation.

"If the LSP knows the destination node, it knows the destination." Yes, but in the case of all the standards compliant LSPs, we DON'T know the destination. We only know the hop before the LSP and the hop after the LSP. Only the sender knows the actually destination.

"the LSP effectively controls the path because the graph information is fed by the LSP". This is an extreme edge case of a malicious LSP, and to pull this off at scale would be extremely complicated.... and also, the LSP could easily get caught by a savvy Lightning engineer who was troubleshooting payment problems.

So we agree. Effectively the biggest LSP, Phoenix, does know the destination and dies trampoline payments and implementations like LDK use an external graph sync mechanism because regular graph sync doesn't work with mobile clients. There are always trade-offs.

Replying to

Roy

And if you are referring to in-Spark transactions, the same issue exists in an in-LSP transaction... I.e. the sender and receiver are connected to the same LSP.

I recommended you a few times in the past not to overhype the privacy state of Lightning. I suggest you align your documentation with this: https://lightningprivacy.com/en/introduction

Replying to

Roy

Get your facts straight. You can blame me all you want, but this is a complete misunderstanding of how Lightning works.

If the LSP knows the destination node, it knows the destination. period. And you don't understand how Phoenix works - they don't do source routing. They use they LSP as a trampoline nodes. They construct the path and they know the destination.

Moreover, even in cases of source routing - if the user is connected to a single LSP - the LSP effectively controls the path because the graph information is fed by the LSP...

And if you are referring to in-Spark transactions, the same issue exists in an in-LSP transaction... I.e. the sender and receiver are connected to the same LSP.

Replying to