pull down to refresh

SN release: make lightning addr only works with attached wallets, bug fixes
1419 sats \ 14 comments \ @k00b 5 Mar meta

There isn't a whole lot in this release, but the lightning address thing is important.

Before, if your attached wallets failed when someone attempted to pay your lightning address, we'd fallback to CCs. We no longer fallback to CCs for our lightning address. If you don't have a wallet attached or that wallet cannot be paid for some reason, we return an error now.

It just kind of sucked not knowing if you were sending the stacker sats or CCs via lightning address. This should also make our lightning address more desirable as a proxy (for privacy) now or directly for folks that want a lightning address but lack a public ip/domain. Whether you receive via proxy or direct is configurable in your settings.

In the future we might make this configurable for the receiver, I know some of you want CCs, but in the meantime you won't be able to "buy" CCs via your lightning address. We'll be adding more fine adjustments like this that give the sender more control/transparency over which asset the receiver receives and vice versa.

The other main fix here was de-borking our trust algo. I'll be spending most of my week making improvements here, but I removed some bugs in it that I introduced 6 months ago.

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 20.5m sats to 41 contributors for 186 contributions! View a nearly up to date list of contribution awards here: https://github.com/stackernews/stacker.news/blob/master/awards.csv

Previous release: #902993

We are hiring.

write
preview
related posts
0 sats \ 3 replies \ @elvismercury 5 Mar

Be interested to hear how the trust algo was borked, and how it's de-borked now, if the explanation is not too onerous to make.

reply
353 sats \ 2 replies \ @k00b OP 5 Mar

Borking:

  • I updated the lib we use for linear algebra, and the api changed (without any notice being posted), so we effectively stopped updating trust scores when I updated the lib and I failed to notice until a few weeks ago.
  • Also, even prior to the lib borking, when someone lost trust completely we failed to remove the trust they should've lost.

Other changes:

  • the effect is minimal in my testing and I plan to adjust further, but the amount each person zaps now matters when determining if they trust each other's zaps. If we zap similar amounts, I trust you more (ie the amount of trust gained for a zap is proportional to the ratio of our zap amounts).
  • I also messed around with penalties for downzaps trying to account for the amount of money spent on a downzap relative to the upzap. This is very rough - I'm still trying to figure out how to achieve what I want with a function.

Planned changes:

  • remove personalized ranking (at least for the forseeable future ... we don't have enough people zapping that it matters, and I've uncoverd some research on how to do it more efficiently should we add it back)
  • give everyone a different trust score depending on the territory (I might know a lot about ~bitcoin but nothing about ~ai)
  • make territory founders the seeds to an independent web of trust used to rank items in their territory ... currently they're constrained by the global trust web and can't deviate from global consensus sufficiently enough to create a new vibe.
  • give everyone comment zapping trust scores in addition to post zapping trust scores.
  • possibly also give everyone post and comment trust scores so their posts/comments can start out more favorably independent of zaps (stretch goal this one).
reply
100 sats \ 1 reply \ @elvismercury 5 Mar

Wow, thanks for the detailed answer, that's fantastic. Some of those planned changes are really interesting -- I like the territory-specific trust stores a lot, and the founders creating territory-specific "vibes".

This isn't really the place for it, but would love to know the state of your thinking sometime wrt the "elevating the prominence / discoverability of good comments" issue that we've talked about in various places at various times. Seems like one of the most important things yet to figure out.

reply
0 sats \ 0 replies \ @k00b OP 5 Mar
would love to know the state of your thinking sometime wrt the "elevating the prominence / discoverability of good comments"

I need to do a real vision quest on this one. I haven't thought about it nearly enough.

reply
0 sats \ 5 replies \ @0xbitcoiner 5 Mar
If you don't have a wallet attached or that wallet cannot be paid for some reason, we return an error now.

Isn't this what @supertestnet wanted?

reply
142 sats \ 4 replies \ @k00b OP 5 Mar

No they mostly want to call CCs shitcoins, imply I'm a shitcoiner, and never have to ever touch or hear of CCs ever.

reply
0 sats \ 3 replies \ @0xbitcoiner 5 Mar

I mustn't have read that part!

reply
100 sats \ 2 replies \ @OneOneSeven 5 Mar

CCDS

reply
0 sats \ 1 reply \ @0xbitcoiner 5 Mar

what does that mean?

reply
50 sats \ 0 replies \ @k00b OP 5 Mar

cc derangement syndrome

reply
13 sats \ 1 reply \ @siggy47 5 Mar

I think you mentioned a while back that you had problems with failed payments from Zeus lightning addresses. Is this still an issue? I'm thinking of trying out their Bolt 12 address (@twelve.cash).

reply
109 sats \ 0 replies \ @k00b OP 5 Mar

They are

  1. more likely to fail given they attempt to do offline lightning payments and sometimes request locking up liquidity longer than we allow.
  2. more likely to fail because they require the recipient open Zeus to accept the zap within 24 hours.
  3. non-ideal for ranking because zaps will not be considered in ranking until they're settled which require manual acceptance by opening the app.

We don't support bolt12 yet but we have it implemented and waiting. We just have some higher priority work to do before we ship it (kind of an involved thing atm).

reply
0 sats \ 1 reply \ @supratic 6 Mar

Does then the LNaddress@stacker.news act as proxy?

reply
0 sats \ 0 replies \ @ek 7 Mar

if you enabled "proxy deposits to attached wallets" it in your settings, yes

edit: or I guess that's the default now, I think we only need the "direct deposit" setting now

/cc @k00b

reply