generally users are already super confused about nostr, the more options they need to think about the more confusing they find it.

there is already an API for that on the nostr object.

nostr:npub1hxjnw53mhghumt590kgd3fmqme8jzwwflyxesmm50nnapmqdzu7swqagw3 is where even I go to read up on the latest Alby related releases.

nostr:note1lt92p3d5atvr3a6zrzxzyj2aa5s3uwfrqz094708cfaxrwarjcfsw77t2m

interesting, haven't thought about it that much in this way.

which would be again relying on DNS :)

why did they want to kill it?

but it seems to me the naming part is the hard one. It's not solved and needs adoption to work at all.

ENS is the only one that has current some scale and adoption.

yes, I know. but that's just what DNS and the naming authorities solve, isn't it? solving names in a decentralized way is hard but important for usability.

Namecoin(👴) and ENS seem to be still the best solutions for that part?

so no naming there? just keys in a DHT? how is the then a fix for the N in DNS?

who is the name authority there?

with 11 relays and let's say a relay URL is ~20 characters long that's then 220+ bytes in the zap request. that still should be good, I've seen muuuch more than that.

Alby Hub for example also returns that metadata in the transaction list and as the whole transaction list also has a size limit (as it's just a nostr event) a lot of transactions with big zap requests can become an issue there, too.

I've seen zap requests with maaaany relays (which could be considered an attack vector)

and I think some private zaps are also rather big - but I honestly don't know the spec there.

we currently have a size limit on metadata and saw some zaps failing because of that.

We have to reduce the byte size of zaps. Some zaps are just too big and are several KB of data (without the user even providing a comment) which causes problems.

zap space is limited!

with whom did you open a channel? that node seems to be offline.

hmm. what explanation ware you missing? about how lightning works?

you can choose the channel partner in “advanced” - most people like the default and don’t care.

Typical people who send and receive sats don’t need to care about some balancing.

but if you don’t want to use lighting then at this stage I guess it’s not for you. :(

sounds like there was a LND downtime at whoever you used there. Can you try it again?

any recommendation on how to make it better? your main issue was that the costs have been unclear to you?

which lightning address do you use in the nostr profile?

sending and receiving are different things there. Sending can be done through NWC receiving is done through the LN address

this is in Damus? hmm. maybe somebody from Damus can help?

it's still sometimes a bit confusing, but it works for me.

I think all is back up again. try to login again to the hub. does it work?

check the settings in the hub. there you can do that.

you can use multiple alby accounts with the same hub, but you have to do the wallet configuration manually.

create a new connection in the hub, copy the secret and go to the alby account - wallet configuration and configure it there

what do you mean with “manually collect”?

I think during the installation on startos it asks you if you want to use the LND node or the embedded LDK.

you just use the LND. it uses the LND grpc interface then.

no change needed, and you should be able to use lnbits etc. for sure.

in the albyhub transaction list you might only see transactions made with the hub as we store some more transaction metadata.

yes. you can use the installed LND

whoot, that sounds pretty cool.

yes, I used iterm before. but the hotkey got somehow broken in one of the updates for me.

it has split screens and is nicely configurable and simple enough imo.

I am critical with all those AI stuff as I don't want to send my data to some AI 😉