I think you are correct about the key path, but it can be disabled.

nostr:nprofile1qqstnem9g6aqv3tw6vqaneftcj06frns56lj9q470gdww228vysz8hqpz3mhxue69uhkzmr8duh82arcduhx7mn99uq3vamnwvaz7tm9v3jkutnwdaehgu3wd3skuep0qy88wumn8ghj7mn0wvhxcmmv9usrwrn5 You should have a chat with these guys and the recent guests you have discussed decentralized directories with, to see if there is a better solution...

I love and use both. OpenBSD for targetted systems with more limited functionalities, but where security is critical, and FreeBSD when more features are required and I still need a very stable environment. Neither have ever been very well suited for laptop use though.

Has it ever recovered? I tried it for the first time today and I get an error for both the LLM and when trying to add funds via LN... Thanks!

Would be great to have this accessible in Vanadium!

I just sent a PR to add #bolt12 support to #NostrWalletConnect (#NWC, NIP-47) : https://github.com/nostr-protocol/nips/pull/1952

This would allow to leverage #NWC to create and use #Lightning #bolt12 offers and invoices.

#bolt12 enables reusable (static) payment requests (codes), increases receiver privacy and increased censorship resistance over #bolt11 (https://bolt12.org)

#NWC is a way for Lightning clients (apps, websites) and servers (nodes, wallets) to communicate through a standardized protocol using #Nostr relays. Many apps and wallets support #NWC. Many LN node implementations and apps support #bolt12. I think it would be great to extend #NWC for #bolt12 !

nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezuamfdejj7qgwwaehxw309ahx7uewd3hkctcscpyug nostr:nprofile1qqs04xzt6ldm9qhs0ctw0t58kf4z57umjzmjg6jywu0seadwtqqc75spz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshszxnhwden5te0wpuhyctdd9jzuenfv96x5ctx9e3k7mf0dv4ph5 nostr:nprofile1qqsrf5h4ya83jk8u6t9jgc76h6kalz3plp9vusjpm2ygqgalqhxgp9gpzfmhxue69uhk7enxvd5xz6tw9ec82cspp4mhxue69uhkummn9ekx7mqpzpmhxue69uhkummnw3ezumrpdejqd2970s nostr:nprofile1qqsvrlrhw86l5sv06wkyjgs6rrcekskvk7nx8k50qn9m7mqgeqxjpvgpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtctcf224 nostr:nprofile1qqsqfjg4mth7uwp307nng3z2em3ep2pxnljczzezg8j7dhf58ha7ejgpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqgcwaehxw309ac8yetdd96k6tnswf5k6ctv9ehx2aqpr9mhxue69uhhxetwv35hgtnwdaekvmrpwfjjucm0d54df670

He is also saying his company could be worth 10-40 times its earnings of a supply-capped asset, that there will not be a crypto winter until BTC hits 500k and then there will be only a 20% correction. Yeah... Maybe not

#bolt12 support for #lnbits: https://github.com/lnbits/lnbits/pull/3092

#bolt12 support for #lnbits #NWC provider extension:

https://github.com/riccardobl/nwcprovider/pull/12

nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezuamfdejj7qgwwaehxw309ahx7uewd3hkctcscpyug I would like to use nostr:nprofile1qqszm52qe2qdkc4u7dma0klx3532jka2g8geck6fwxncyp90wktq2xspp4mhxue69uhkummn9ekx7mqprpmhxue69uhhwetvvdhk6efwdehhxarj9emkjmn9qy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsy47788 with Bolt12 offers, but currently there is no make_offer, lookup_offer, fetch_invoice, etc commands as part of NIP-47 . What is the way forward to have it added to the specs so it can be implemented by different wallets and clients? Thanks!

Now let's properly implement Bolt12! Currently offers without node IDs are not supported by some nodes.

There is some connectivity to it, but it returns the error: "Cryptograhic handshake: Operation timed out"

I have not been able to connect to it for over a week, and mempool.space does not seem to be able either. Its IP addreas has not changed?

When do you expect your ln.coinos.io node to be back online?

The way I see it is that Knots can have some utility if you are a miner and want to exclude the spam from your block templates. Otherwise it does not do much useful besides being a sign of protest. Refusing to upgrade to the controversial version of Core would have a similar effect.

I am thinking about switching my node to #Knots. Is it causing any issue when used by a Lightning node?

Please someone correct me if I an wrong, but with JM it seems the on chain fees are paid by a single entity (single user with multiple market makers) for each tx, which is very costly?

Also the default behaviour in JM of consolidating all original input utxos is not ideal.

If a protocol could both share the txs between users and avoid tying the original input together, without impacting negatively the other characteristics, it would be awesome.

I really appreciate SideSwap, but my only issue with it is that the peg-out fee rate (mandatory?) suggestions tend to stay stuck at very high values compared to the rates suggested by mempoopl.space . is there any workaround solution for this?

This one was amazing, loved it! Right at the top with the Mandibles interview!