pull down to refresh
0 sats \ 0 replies \ @gbks 26 Feb \ parent \ on: UX Research: Thoughts for future LSP pan outs Design
I think we're a bit too focused on onboarding UI now. Nonetheless, if all LSPs end up charging a certain amount for first channel open, wallets may want to let users know about that. No one likes hidden fees, especially not the first time you make a transaction. That would not build a lot of trust, no?
Maybe it is possible to just paper over channel fees altogether, routing fees cover it all, and users have a smooth ride. But maybe not. I just don't want to make that assumption without thinking through different scenarios.
Sure thing. It's great if the default works well to onboard people. And maybe once they have a sense for what their needs are, they can go in and fine tune things.
What I am curious about is whether the actual economics and marketplace dynamics will pan out that way. Those might in the end dictate what options users have. Can we already know at this point in time how things will go? Not sure even the teams that run today's LSPs do, considering the tech is still maturing and adoption and usage patterns will likely change.
I've been running Umbrel on a Raspberry Pi for some years and it runs super stable and requires no overhead. I connect to it with Zeus for payments on the go (that part is a bit shaky sometimes due to Tor). It's a nice setup.
Sorry, didn’t look close enough. I assumed you used the default address provided by Phoenix, and not your own.
New middlemen. In this case, Phoenix owns the domain and manages the DNS records. Users rely on Phoenix to operate this honestly and reliably.
Recommendation is to use these email-like DNS-based addresses only when needed - when being human-readable/understandable/writeable is actually important (e.g. it's not important when someone is scanning a QR code). Otherwise it's better to just use the bitcoin address (BOLT12, silent payment, etc) directly.
I was curious what some other ways are situations like this can be resolved. Here's what AI came up with, which I found quite helpful. YMMV.
Could There Have Been Other Ways to Resolve This?
Yes, there are alternative approaches the company could have considered:
1. Collaboration
- Open dialogue: The company could have reached out to the project maintainers before taking legal action, explaining their concerns and seeking a mutual resolution.
- Coexistence agreement: The company could allow the project to continue under certain conditions, such as disclaimers stating it is not affiliated with "Blockclock."
2. Renaming Support
- Grace period for renaming: Instead of an immediate takedown, the company could offer the project time to rebrand itself (e.g., a non-similar name like “btc-timer”).
- Assistance with rebranding: They could even assist the open-source project with resources or publicity to help transition to a new name.
3. Licensing
- Limited-use license: If the trademark holder isn’t directly harmed by the open-source project, they could grant a license to use a variation of the name under certain conditions (e.g., non-commercial use).
4. Mediation
- The parties could use neutral mediation to reach a compromise without escalating to takedown requests or legal action.
Broader Implications
This scenario highlights challenges in balancing intellectual property rights with the open-source ethos:
- Open-source projects often lack legal resources: Legal action or takedown requests can disproportionately affect smaller projects, even when they don’t pose a significant threat.
- Trademark enforcement vs. community goodwill: Aggressive actions might harm the company’s reputation within the developer and cryptocurrency communities.
Conclusion
While the company's actions may be legally justified, they might not be perceived as fair by the broader community, especially if the open-source project wasn’t causing harm. Alternative resolutions, such as collaboration, renaming support, or licensing, could have maintained goodwill while still protecting the trademark.
I think they subsidize and batch small payments, so the fees are manageable. Their approach has several benefits, but also a few problems. The most fundamental one would be that as fees increase, the wallet becomes less usable from an economic perspective. The constant swapping between layers just adds up. We saw that earlier this year when fees were super high during the ordinals nonsense. If you had your own lightning channels (with enough liquidity), it wouldn't have affected you at all. But Muun's system become problematic during that period. It's not clear to me whether they can simply tweak and optimize this system or need to fundamentally rethink it. There are some smart people working on it, I'm sure they have a few ideas.
Depends. If you build in the space, then the builder-focused ones are great (like Baltic Honeybadger). If you are a business person looking to network, then others might be a better fit. One person's treasure is another person's trash.
Good. A worthy effort to support diversity, when historically certain groups were disadvantaged, demographics are changing, etc.
Obviously a very trick thing to do well and there will be mixed results, but that's the case with a lot of things.
Great project. Unless things have changed, Collin is looking for more contributors. It's a solo effort, and for the project to grow, a few extra brains and hands would be amazing.
He is just complaining how terrible everything is, what's the point of that?
What if this was just incompetence in a specific situation and is not reflective of all of government and all of media and "the elites" and government diversity efforts (god forbid the idea that diversity might even improve things) and the moral state of the country? Not very helpful commentary, IMHO.
Good think it's an open-source/open-design effort and all feedback and criticism can be used to make it better.
Being an editor of this newsletter, I can naturally only say good things about it. It's the best. Thanks for sharing it here.