SN release: CLINK wallet, recent search order, improve related posts, bug fixes \ stacker news ~meta

pull down to refresh

SN release: CLINK wallet, recent search order, improve related posts, bug fixes

3178 sats \ 17 comments \ @k00b 24 Sep meta

If you are running https://lightning.pub/, you can now send/receive with CLINK. Also we now pickup the lightning address from NWC strings if it's present. (via @ek)

Many people complained about recent searches not being ordered how they expected. They are chronologically ordered again. (@SimpleStacker's fix inspired me to fix it another way.)

I've also improved related posts again. Before, we weren't doing term matches, only semantic ones - now we do both. This should improve their quality quite a bit. edit: it looks like by relaxing the term frequency limits, we get some weird results sometimes. I'll refine it.

There are a variety of small bug fixes in this.

View all commits here: https://github.com/stackernews/stacker.news/commits/master/

Since starting the Open Source Contributor Award Rules (OSCARs), we've paid a total of 25.7m sats to 50 contributors for 273 contributions! View a nearly up to date list of contribution awards here: https://github.com/stackernews/stacker.news/blob/master/awards.csv

Previous release: #1205629

view all related items

851 sats \ 12 replies \ @justin_shocknet 24 Sep

you can now send/receive with CLINK

Game changer. Well done SN team and special h/t to @ek for feedback throughout the implementation.

Will get a more detailed guide up in the next few days and maybe an "in 100 seconds" video once we merge a few more things, but here's a quick outline:

CLINK is a nostr based transport for invoices, a bit like LNURL, but end to end encrypted and key-identified so you don't need a web server of your own to use it trustlessly, works with any open relay. Also provides an much better alternative to the slow and unreliable onion-based messaging of Bolt12. The spend spec offers functionality like NWC or LNURL-Withdraw, but without prior account setup and secret sharing.

Lightning.Pub is the fastest and easiest node to set up BY FAR.

Paste one line into a terminal, and you've got a full nostr-based account system over LND.

wget -qO- https://deploy.lightning.pub | bash

In less than a minute, assuming a half decent internet connection, it'll look like this:

The nprofile:string in the output is what you'll paste into ShockWallet to connect (with administrative dashboard privileges) to the node over Nostr. No horsing around with a network config required and no flakey ecash gateway!

ShockWallet is available on iOS Test Flight, an Android APK, or as a WebApp

Fire up and hit "add connection"

Hit "add" to insert your nodes nprofile (and :adminkey).

You should get a green toast and then see the node available as a spending and receiving source

Click the logo to go back to the main screen navigation, and click Linked Apps

At the bottom you'll see the debit string to provide to SN an endpoint.

Copy and pasta that bad larry into SN

For the receiving next step, go to wallet nav for Offer Codes, copy your default offer to paste into SN... this default offer is fine for all arbitrary payments (you can set up others with webhooks etc but that's out of scope here)

As soon as you go to Zap some content, ShockWallet will request authorization for the spend, you can also set up a rule for future requests

This rule gives SN a 1000 sat per month budget without requiring additional authorizations

If you've made it this far, you're now based and CLINK-pilled.

67 sats \ 1 reply \ @deSign_r 19h

trying wget -qO- https://deploy.lightning.pub | bash give me an error in macOS. It's that normal?

$ wget -qO- https://deploy.lightning.pub | bash
dyld[84152]: Library not loaded: /usr/local/opt/libunistring/lib/libunistring.2.dylib
  Referenced from: <EA607B2B-AD3B-3A0D-85F9-B4E54C36EC2F> /usr/local/Cellar/wget/1.21.1/bin/wget
  Reason: tried: '/usr/local/opt/libunistring/lib/libunistring.2.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/opt/libunistring/lib/libunistring.2.dylib' (no such file), '/usr/local/opt/libunistring/lib/libunistring.2.dylib' (no such file), '/usr/local/lib/libunistring.2.dylib' (no such file), '/usr/lib/libunistring.2.dylib' (no such file, not in dyld cache), '/usr/local/Cellar/libunistring/1.3/lib/libunistring.2.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/Cellar/libunistring/1.3/lib/libunistring.2.dylib' (no such file), '/usr/local/Cellar/libunistring/1.3/lib/libunistring.2.dylib' (no such file), '/usr/local/lib/libunistring.2.dylib' (no such file), '/usr/lib/libunistring.2.dylib' (no such file, not in dyld cache)

All smooth on Linux

0 sats \ 0 replies \ @justin_shocknet 13h

Yea macos support not implemented yet, though I should probably make sure to give a better error...

17 sats \ 6 replies \ @ACYK 14h

I meant to circle back and try Lightning.Pub to see how it was progressing, but the easiest device to do that on is an Ubuntu machine that is already running Alby Hub. With the one line install there are port conflicts. Since running Alby Hub is fairly common, is there any way to get a one line install that uses alternate ports and doesn’t interfere with Alby Hub?

0 sats \ 5 replies \ @justin_shocknet 13h

The bigger problem would be both trying to use LND, the script installs LND as well which is probably the conflict

17 sats \ 4 replies \ @ACYK 13h

Alby hub is using LDK. Would there still be a conflict with LND then?

100 sats \ 3 replies \ @justin_shocknet 13h

Ah, LDK must be using 9735, that's the standard lightning P2P port... Maybe I can add a switch to change the default...

17 sats \ 2 replies \ @ACYK 12h

That’d be great

0 sats \ 1 reply \ @justin_shocknet 9h

Testing this now but can't reproduce it with 9735, can you show me the error exactly?

0 sats \ 0 replies \ @justin_shocknet 6h

I think I got it, merging now...

The new change will check if the port is occupied before installing LND and then bump it

Take it for another spin, should work over the existing failed install, but if not just stop the hung lnd first systemctl --user stop lnd so the script can confirm its not lnd hogging the port

After its up if you cat ./lnd/lnd.conf you should see what port is is listening on, it increments so likely 9736

reply on another page