user91626: Lightning loop is a great non-custodial way to do submarine swaps in both directions. However I would like to clarify some questions about how it actually works.
There is a closed source server side of the loop, controlled by lightning labs. Which lightning nodes is the server side running on? Does that mean that I will only ever be able to rebalance the channels that are a part of the path from my node to theirs?
Second question is more about the software architecture. Why do I need a daemon loopd to always be running in the background? Seems like the server side should be of course always online, but why ask the clients to do that?

user96909: 
Lightning Labs manages the lnd node(s) running on the private (closed source) server you are correct. Your node receiving Loop payments on LN will need a route to their node, however part of the service Loop is providing (and charges for) requires them to keep channels balanced to pay your invoices or accept payments on demand.

The closed source functionality could include proprietary channel balancing techniques that give Loop's node(s) an edge in their service over competitors.
In any case to find their node you can take an invoice from Loop and parse out the destination pubkey.

The loopd implementation itself is a daemon that is tightly coupled with lnd and the private server discussed above. It is responsible for facilitating all parts of the submarine swap functionality Loop offers. It is intended for loopd to be running alongside lnd for automated submarine swap workflows (ie. rebalancing).


user91626: I played around with loop and got some of the answers. Posting here as it can also be useful to others.

I did multiple loop out operations, and every time my counterparty was a node 03fb2a0ca79c005f493f1faa83071d3a937cf220d4051dc48b8fe3a087879cf14a. I assume this is the loop server node. It does not necessarily mean that loop only has one server node, but so far it looks like it.
03fb2a... is a private node though, so it also gave my node routing hints, which point out to the last public node on the path to the server. And the last public node is 021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d - a pre-server node.
So most probably it is only possible to balance the channels that have a path with sufficient liquidity to the node 021c97...
It seems like loopd needs to be running in the background purely for user experience reasons. Something needs to be running while a swap is being completed, and the swap takes a long time to complete (two transactions need to be confirmed on-chain, so it can easily take half an hour).
So running loopd in the background makes sense simply not to block the terminal window for a long time. I also checked that when no swap was being executed - loopd was simply idle.


91626: <p>Lightning loop is a great non-custodial way to do submarine swaps in both directions. However I would like to clarify some questions about how it actually works.</p>

<p>There is a closed source server side of the loop, controlled by lightning labs. Which lightning nodes is the server side running on? Does that mean that I will only ever be able to rebalance the channels that are a part of the path from my node to theirs?</p>

<p>Second question is more about the software architecture. Why do I need a daemon <code>loopd</code> to always be running in the background? Seems like the server side should be of course always online, but why ask the clients to do that?</p>
 96909: <ol>
<li>Lightning Labs manages the <code>lnd</code> node(s) running on the private (closed source) server you are correct. Your node receiving Loop payments on LN will need a route to their node, however part of the service Loop is providing (and charges for) requires them to keep channels balanced to pay your invoices or accept payments on demand.</li>
</ol>

<p>The closed source functionality could include proprietary channel balancing techniques that give Loop's node(s) an edge in their service over competitors.</p>

<p>In any case to find their node you can take an invoice from Loop and parse out the destination pubkey.</p>

<ol start="2">
<li>The <code>loopd</code> implementation itself is a daemon that is tightly coupled with <code>lnd</code> and the private server discussed above. It is responsible for facilitating all parts of the submarine swap functionality Loop offers. It is intended for <code>loopd</code> to be running alongside <code>lnd</code> for automated submarine swap workflows (ie. rebalancing).</li>
</ol>
 91626: <p>I played around with <code>loop</code> and got some of the answers. Posting here as it can also be useful to others.</p>

<ol>
<li><p>I did multiple <code>loop out</code> operations, and every time my counterparty was a node <code>03fb2a0ca79c005f493f1faa83071d3a937cf220d4051dc48b8fe3a087879cf14a</code>. I assume this is the <code>loop</code> server node. It does not necessarily mean that loop only has one server node, but so far it looks like it.</p>

<p><code>03fb2a...</code> is a private node though, so it also gave my node routing hints, which point out to the last public node on the path to the server. And the last public node is <code>021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d</code> - a <em>pre-server</em> node.</p>

<p>So most probably it is only possible to balance the channels that have a path with sufficient liquidity to the node <code>021c97...</code></p></li>
<li><p>It seems like <code>loopd</code> needs to be running in the background purely for user experience reasons. Something needs to be running while a swap is being completed, and the swap takes <em>a long time</em> to complete (two transactions need to be confirmed on-chain, so it can easily take half an hour).</p>

<p>So running <code>loopd</code> in the background makes sense simply not to block the terminal window for a long time. I also checked that when no swap was being executed - <code>loopd</code> was simply idle.</p></li>
</ol>
