pull down to refresh

No we sure don’t but the pod is growing year over year at this point. I imagine it will be very “successful” in its third year, usually when podcasts “break out.”

We use transistor to track accurate metric podcasting data, (anchor and spotify inflate numbers about 1000%) and so we average between 150-200 downloads every episode. With our YouTube views we have about 250-300 views/downloads every episode last year around this time we were at about 65 views/downloads total.

I actually would love to support fountain with sats in some capacity in the future. Right now we really just do it for the Stackers and SN community, both myself and keyan have day jobs so this is more a labor of love. We also think it’s very important to see what people voting with their sats think is the most important bitcoin news of the week.

Lack of high availability makes it difficult to run either of the major distributions like a real enterprise system, with zero downtime. I suspect even the largest nodes on the network today are not much more sophisticated than what’s available out of the box with LND.

Improvements to LND on the db side have reduced downtime required between restarts (by enabling online compaction), and also setting up the architecture for multiple nodes to share a backend data store. Leader election can provide a primitive form of HA (failover but not load balancing). An external project, LNmux by Bottlepay, will allow load balancing HTLCs through multiple public gateways, which is the holy grail for enterprise LND.

For someone with some LN experience, who wants to learn more the above, I recommend setting up a regtest environment using containers or VMs, and configuring the following:

  • Create a basic postgres instance
  • Create an LND instance w/postgres backend
  • Upgrade your postgres to have high availability
  • Create an etcd cluster
  • Create 2 additional LNDs and configure leader election
  • Add centralized monitoring/logging (Grafana LGTM stack is phenomenal but other choices are available)
  • Add lndmon sidecars to lnd for monitoring LN metrics

If you can confidently configure all of that, you should have the basics to work on any major node on the network. Some will be drastically different in implementation but the concepts should be the same.

HTLC load balancing is still experimental as far as I know, but if you have some development experience you can add lnmux to your lab and experiment with it today.

An alternative node distribution that was created with more of an enterprise architecture from the start is ACINQ’s Eclair. They probably the single largest node on the network, however I have not seen Eclair elsewhere in the wild, which is why I recommend starting with LND then branching out when the fundamental concepts are well understood.

For something easy to digest and get you motivated to build an enterprise grade LN node, here’s a video from base58, Enterprise Lightning Engineering at CashApp w/Ryam Loomba:
https://youtu.be/kbhL5RqL8Aw

It’s also important to keep in mind that building and operating enterprise grade infrastructure is completely orthogonal to managing liquidity. Doing both of these well is likely to require at least two talented full-time individuals (more likely a team for each).

reply