I feel that so far in #Bitcoin, #Nostr, and the #Pears stack we’ve had a strong focus on two things:

• User facing wallets, app, and features

• And fundamental network design and implementation

However, there are drawbacks to what we’ve focused on: The fundamental network development is critical, but isn’t understood and doesn’t interact well with the end user. While the end user wallets and services often have huge trade offs and rely on third parties or custodians.

We have basically let the market for centralized companies work to bridge between these two areas of development and demographics of the community.

But as has been shown with recent arrests and the fear rippling through public service providers, I think it’s critically important that we start focusing on building tools to BE a service provider, that are as simple and easy to operate as the end user wallets have been designed.

The barrier is still too large between the end UX and the core tools of these environments.

For example, we need to think about how we can design an interface that lets anyone with a couple of BTC be a private LSP, automatically, with channel splicing, and try at lets users connect to and use them in popular wallets with nothing but a QR. This would radically change the landscape if “running a server” is as easy as we can possibly make it. This would be the key to genuine decentralization of the market and the ability to quietly make a huge variety of reliable and simple services and onboarding tools that aren’t bug, public, and easily targeted businesses.

It would open up an entirely new layer of the market that is never actually targeted and with tradition infrastructure, isn’t really possible. But the new protocols we have today change this. We need to change how we think about the architecture of the market when we have new tools that, rather than simply building the same things with new tools, allow us to completely rethink how things are built in the first place.

Recently piece from nostr:npub1dtgg8yk3h23ldlm6jsy79tz723p4sun9mz62tqwxqe7c363szkzqm8up6m is a great example. IMO, It’s time we think about UX for sovereign providers the way we’ve always thought about UX for the average user.

Reply to this note

Please Login to reply.

Discussion

Exactly 🎯

If we make running a server for decentralized services as easy as running a bitcoin node, this will be unstoppable.

I’m not very technical but found running a node on a raspberry pi pretty easy. I want to upgrade to something like a srtart9 to be able to run properly more decentralized services, like a nostr relay, but I fear my lack of knowledge/experience on that front will get in the way.

Make it easy and with easy to set up default configurations, and more people will join.

I might be wrong but I think this is the primary mission of nostr:npub1mu7nv2jkaq4xausnn098xc8tp3gzgf2w5r2cj68x8dnns0rktmysnsj5cl SDK. They are trying to create a one stop shop for "be your own LSP"

Bolt 12 not requiring liquidity will bring down the financial barrier as long we lower the technical barrier to channel opening/closing/management in a nice UX.

Maybe that's what Phoenix was trying to do also by releasing phoenixd?

Good words, Guy 👍 Thank you 🙏 Where can we learn more about Pears?

I think the thing that makes running a Bitcoin node easy but a Bitcoin Lightning node difficult is that the L2 has a central model, whereas L1 is fundamentally decentral. The keys and signing happen in one place for the LN node, exactly like individual wallets on L1. The thing I've been pondering since I've discovered the scaling problem is if there's a way to decentralize the LN node itself, like cluster computing.

My first thought is a really big multi-sig, which would require a coordination amongst multiple virtual nodes. This would effectively be a side-chain, but more Bitcoin-native. The compound node would coordinate/automate thousands, maybe tens of thousands, of virtual nodes running a decentralized node program, for balance tracking, L1 tx composition and publishing, L2 channel management, etc.

The one hiccup is node churn and multi-ID. A quorum of peers would always be needed to be active and responsive, and key rotation would be needed, but some mechanism would be needed to ensure that someone who starts 100 nodes on virtual machines can't take over the system, like PoW.

What is Pete?

What is Pears rather than