btw. what I want to generally spend more time on is the talk about supply-chain attacks of wallets. It's potentially easier to compromise some dependency or a build than accessing some RAM on servers directly.

I agree. this word has a bit of different meanings for different people. Ultimately it is a bit of a range and imo also it's about the context of usage and goal. I think so far the focus is on the Hub here I guess. The cloud hosting is an offer we provide. And the talk about unencrypted memory is a bit tricky imo and also quite different to persisted storage. but yes, it's a cloud setup where hosters put servers somewhere and run it for you.

I really appreciate this feedback we have to try to be very clear here and explain things well to users. thanks!

All data is encrypted and only decrypted to start the node in memory; nothing is on disk. But yes, this is similar to any hosting provider. If one has access to the machine and can read the RAM one could find keys. This gets a bit in the direction that if you don't build the software stack yourself and ideally build the hardware yourself nothing can be trusted. You might not use a hosting setup for your bitcoin stash - that's probably on a hardware wallet from a trustworthy vendor, potentially in a multisig. But it's a solution for your accessible lightning wallet to do all the exciting lightning things. Generally I guess the hosting is a bit comparable to voltage. Phoenixd also goes in the direction of an always-on, server node (afaik they don't encrypt the seed on disk).

We put a lot of work in to make it possible to run the Alby Hub everywhere that users can choose what works for them: this can be a Raspberry Pi Zero (some $20 hardware!), your desktop computer, your own server (e.g. we have docker and one-click deploys for hosters, too), etc.

Yeah, LSAT/L402 for the win! we need more adoption of this. had experimented with it here a while ago: https://github.com/kiwiidb/insatgram

thanks for the feedback! we plan to update the plugin to use the new NWC protocol to connect wallets. this makes it easier and more reliable.

let me know if you want to test it and need help.

You can connect the Alby lightning address to your LND node. But the UX is not as good as we want it to be so far. (current sats are not forwarded for example). We push for NWC there and it will become quite easy then.

yeah, a lot is happening there. it will get easy. check out NWC I think this could be helpful for you - more universal and future proof.

where are you sending to?

We are currently deploying an update there that allow users to specifically create lndhub credentials when needed. One issue that lndhub currently has is that there are no permissions and that credentials can not be revoked. This is a first step to give the user more control. Please give us a bit and sorry for this.

Even though going forward I believe lndhub connections will be soon be replaced with NWC.

sending dev and op hugs!

whoot! looking forward to it and have fun!

If somebody wants to run their own lndhub: we maintain an API compatible version written in Go: https://github.com/getalby/lndhub.go It is has no run-time dependency and is deployable. Currently it is using PostgreSQL for data storage - but SQLite would actually also be supported.

that's great to hear. would for sure love to support it. Rust is just not my main language and it was easy to write those lines of JS.

Can the relay be disabled? because I assume if it gets used as a relay it needs much more resources and has more traffic.

My use-case is mainly that existing apps can publish events to Nostr without the requirement to add the websockets handling. Potentially also loading specific notes through a HTTP get.

yes.

fetching notes? It would be possible I think, but that was not my use case so far.

I didn't really know about blastr. thanks for sharing it. Is it correct that blastr sends to as much as relays out there? here the client defines the relays that an event should be sent to. It is also NOT intended to be used in a Nostr client but simply tries to be a tiny, stupid HTTP function that takes an event and an array of relays and publishes to those. So the goal is a bit different.

You can add multiple accounts to Alby.