Right now the docs correspond to what's on master. We need docs for each daemon release so developers can see what's available in the version they are using.

https://github.com/jimporter/mike may be helpful.

Background

When a node has multiple private channels with the same peer, the hop hints in their payment requests will be populated with multiple channels. The purpose of these hop hints is to specify the next node's key and indicate the fees and cltv delta needed for route construction.

In pathfinding, due to non-strict forwarding, an LND node paying to this destination will only use the

On macOS, it's a fairly standard practice to display a pre-roll if your application needs some form of permissions, before calling the system APIs for the first time that will actually produce the system's requested-permissions window.

For instance, for any given end-user, the following window is likely A) intimidating, and B) possibly encourages insecure habits, such as simply clicking "acce

Now that we have code coverage enabled there are a few places we can easily improve test coverage for.

• Get/Set all parameters for all types of objects
• Trigger the Settings updated code path by setting a registry key
• Test out multiple registration execution modes
• Test Server IP load balancing mode
• Packet drops in validating received initial token
• Trace ru

When stateless retries are enabled, Quinn embeds some state in the retry token and authenticates it with a HMAC. This information is not secret, so the current approach works, but it would be more in the spirit of QUIC to use strong encryption to prevent other parties from coming to rely on that data, creating a stability hazard.

The stateless nature of retry tokens requires some care if we wan

protocol SomeProtocol {
    init<T>(t: T)
}

The code generated by the protocol above will have an initializer like below which cause a compiler error.

     required init(t: T) {
        
    }

It looks like the type placeholder is missing when generating for an initializer.

Filling from mobile so we don't forget. Good first issue if someone wants to fix this via a PR before I get to it next week.

Right now, when IPFS integrations are disabled via a toggle, extension assumes http://.

Most servers redirect http:// → https://, or have HSTS set up, but Companion should default to https://, because if someone did not set up redirect to a secure context,