people ask me for my "lightning address" all the time which is frustrating. framing it as only for businesses is disingenuous.
All I really want to run on my home node is bitcoin core and clightning. I have no plans to run a web server and deal with cert headaches, etc. lnurl is a non-starter for me. Luckily bolt12 works great, even if it is not perfect.
Because it's the phone I use and I'm scratching my own itch. Would be happy to see someone build something similar for android. I have only been able work on this in my spare time in the last 4 or so weekends, I have no additional free time and won't get to an android version in the foreseeable future.
First step would be to get lnsocket working on android if anyone wants to work on that.
Yeah the setup should be much simpler than existing solutions. And you won't need to run other software like spark just to use your node like a wallet.
To access my clightning wallet I have to do a bunch of things which are not ideal:
- run wireguard so that I can access spark from my phone
- run spark so that I can send/receive funds
- no native experience, I have to use the spark web ui which can't scan qrcodes.
- tried zeus many times but spark just throws errors when zeus tries to connect
Some people use tor, but that is a terrible way to access your node. It's slow and insecure if you're just using it as a portal into your network. I have seen people lose funds by unwillingly open their node up to the public with tor.
There are so many failure modes with existing solutions. I figured the fastest, easiest, and most reliable way to do RPC directly to your lightning node that is already exposed to the internet. So the plan is to build a lightning wallet that can talk this protocol.
yesterday I released lnsocket, a C library for sending messages on the lightning network. It can currently connect to lightning nodes and send/receive lightning network messages (TLVs).
This weekend I am planning on getting the build working on iOS so that I can make a proof of concept for controlling a clightning node directly over lightning.
Right now it's a bit difficult to connect to your lightning node's wallet: you have to run other software next to your lightning node that connects to it's RPC to send/receive wallet information, channels, etc. It would be nice if your lightning node could give you this information directly over the lightning network, since your lightning network port is already publically exposed on tor or the internet.
All you would need to do is whitelist client pubkeys and you would be good to go!
Maybe one day we could have a blip that specs out a standard RPC mechanism so this could work for all nodes instead of just via a clightning plugin.
I 100% agree with the justification and have had similar experiences. singlesig bip39 + passphrase is more than enough for most individuals, it provides digital and physical protection when combined with a hardware wallet. multisig is just another layer of complexity that most users are not ready to deal with, especially in a world that does not have good infrastructure around miniscript yet.
For anyone not in the know, nostr is fiatjaf's social network protocol:
The simplest open protocol that is able to create a censorship-resistant global "social" network once and for all.
It doesn't rely on any trusted central server, hence it is resilient; it is based on cryptographic keys and signatures, so it is tamperproof; it does not rely on P2P techniques, therefore it works.
Very short summary of how it works, if you don't plan to read anything else
Everybody runs a client. It can be a native client, a web client, etc. To publish something, you write a post, sign it with your key and send it to multiple relays (servers hosted by someone else, or yourself). To get updates from other people, you ask multiple relays if they know anything about these other people. Anyone can run a relay. A relay is very simple and dumb. It does nothing besides accepting posts from some people and forwarding to others. Relays don't have to be trusted. Signatures are verified on the client side.
This is needed because other solutions are broken
The problem with Twitter
- Twitter has ads;
- Twitter uses bizarre techniques to keep you addicted;
- Twitter doesn't show an actual historical feed from people you follow;
- Twitter bans people;
- Twitter shadowbans people.
- Twitter has a lot of spam.
The problem with Mastodon and similar programs
- User identities are attached to domain names controlled by third-parties;
- Server owners can ban you, just like Twitter;
- Migration between servers is an afterthought and can only be accomplished if servers cooperate. It doesn't work in an adversarial environment (all followers are lost);
- There are no clear incentives to run servers, therefore they tend to be run by enthusiasts and people who want to have their name attached to a cool domain. Then, users are subject to the despotism of a single person, which is often worse than that of a big company like Twitter, and they can't migrate out;
- Since servers tend to be run amateurishly, they are often abandoned after a while — which is effectively the same as banning everybody;
- It doesn't make sense to have a ton of servers if updates from every server will have to be painfully pushed (and saved!) to a ton of other servers. This point is exacerbated by the fact that servers tend to exist in huge numbers, therefore more data has to be passed to more places more often;
- For the specific example of video sharing, ActivityPub enthusiasts realized it would be completely impossible to transmit video from server to server the way text notes are, so they decided to keep the video hosted only from the single instance where it was posted to, which is similar to the Nostr approach.
more on the project page
uhh I didn't realize editing your bio posted it to the main feed lol. awkward...
That's the plan