What is the best platform or tool to properly search and setup all your relays (inbox, outbox, dm, search, etc...)? Is there a standard or best principles to follow?

Ehi nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 curious on what distro/DE/VM you are using, is that i3, sway or something else?

Ok this: https://guides.getalby.com/user-guide/v/alby-account-and-browser-extension/alby-hub/faq-alby-hub/why-do-i-need-to-link-my-alby-account should clear pretty much all doubts, the Alby Account is the middle man to make everything which is public work, so they basically see all that is related to the getalby LN address if you link the node with the Alby account. I mean, it makes sense.

How does the thing work? What about VPNs, Tor and LN addresses when I am self-hosting it inside a private network without opening anything to the public?

Solved it, obviously it was something strange between an async/await function and a framework component.

Yep, it's a problem on my part, the future connection in a simpler rust program does work.

Oh ok, thanks, but it seems I am unable to make it work even following that example. I'll try by doing a simpler cli program, maybe the problem is more with the web framework I am using.

nostr:npub1drvpzev3syqt0kjrls50050uzf25gehpz9vgdw08hvex7e0vgfeq0eseet Hi, I was trying the nostr rust crate to test the nostr connect feature where a web app is generating a qrcode with the "nostrconnect://..." url for Amber to scan and sign. So in this case I am creating the NostrConnectURI object by providing the local public key of the app (not the remote signer) and the usual relays. This goes all well as I am able to then use the Client object, the problem is that when I refresh the web page all the internal state, meaning the Client object, get lost (I am using dioxus as web framework if it can help). The thing is that during the initial "login" phase I save every important value as a String by leveraging the integration with the browser localstorage, so I am fairly certain that the Client object can be recreated, but I don't understand how. I have looked at the examples on the github repo and tried different options but I am unable to properly recreate/parse the NostrConnectURI and then the Nip46Signer. What should be the correct way to do it if I initially "logged in" with a "Direct connection initiated by the client"?

nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr Thinking about some alternative home feed: I have to say I find "duplicated" content from people I follow too much often, what I mean is that when someone is resharing other people posts I see both the original post and the reshare it confuses me because I see multiple time the same content. I think it could be an interesting idea to have the option (not a DVM, just an option for the feed that I can decide to enable permanently) to display reshares from people I follow only when they reference a note from a person I don't follow, so that I can avoid duplicated content and feed is less bloated.

What would you say? Could this be useful?

I might not have the ability to properly view each pro and con since I am not that technical into cashu and LN low level details and for sure you make some good points, but I still have some questions/doubts:

- Aren't people connecting with shockwallet to a Lightning.Pub node effectively using a custodial service? More trusted for sure if they use a friend or family one, but still custodial right? So in this case isn't using a cashu mint as a base adding only benefits? You still need to trust the node not to "rug pull" the LN liquidity right? Which is the "same" with a cashu mint or am I missing something? (A part from the added technical layer obviously)

- So if I am understanding right, under the hood you basically have "multiple keys for each user" so it would be problematic to add whitelisting (please "explain like I am 5" if not 😅 ) and it will negate the benefits of it. Then again the anonymity set is usually low in uncle jim nodes, so almost perfect privacy of cashu mints is not that perfect and not that almost 🤣 .

So basically you say that the Lightning.Pub implementation is actually more private (for this kind of use case) and simpler (less technical layers)?

Hope I am understanding right.

Thank you, that was very helpful for me.

Sorry to bother you again, but is there a way with nostr-sdk to save the state of the client and/or signer/bunker in the localstorage of the web app that is running everything? Or is this outside of the scope of the crate and therefore needs to be achieved by the framework in use? I am trying something with Dioxus Web but apparently the Client and NostrConnectURI types doesn't support serialization.

I am still a beginner with Rust, so I might say stupid and incorrect things.

I think it would be really cool if the Lightning.Pub accounting system (for users using shockwallet) was on top of a cashu mint and not only a pure LN node (neutrino). In this case you could have both the nostr real-time sync and connection to the node (instead of having to manage VPNs, Tor, etc...) and privacy for each user wrt the node operator, right? And maybe this could enable a "private cashu mint" where only whitelisted npubs could connect (family, friends, etc...).

Ehi nostr:npub1drvpzev3syqt0kjrls50050uzf25gehpz9vgdw08hvex7e0vgfeq0eseet I see you are working on the Rust Nostr library, I was playing around with it mostly for NIP46 and NIP65 stuff following the example codes on the repo and I was wondering: if I want to publish an event using the outbox model what do I need to do? Is there a method or option on the Client object to automatically publish the event on the outbox relays of the user or do I need to make sure to "client.add_relay(...)" for every outbox relay (taken from "Kind::RelayList" events) prior to sending the event?

Ehi nostr:npub18ams6ewn5aj2n3wt2qawzglx9mr4nzksxhvrdc4gzrecw7n5tvjqctp424 , is it possible to configure the well-known content on nostrplebs.com with the nip46 key to advertise relays used for remote signing with apps like Amber? I am talking about this login flow: https://github.com/nostr-protocol/nips/blob/master/46.md#nip-05-login-flow

Do you mean the well-known stuff with the nip46 relay urls inside?

Oh nice.

Now I am trying to play with the NDKNip46Signer but I am not sure about this: if I want to sign in using the nip05 or npub string, does the remote user need to have advertised the relays in which it will "listen" for bunker connections? I am thinking about the scenario where I want to login on a desktop web page while I have Amber on mobile to sign requests. At least with nostrudel you have the whole bunker url with hex pubkey and the relay you want to use, and I am not sure how this translate in NDK.

nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc nostr:npub1w4uswmv6lu9yel005l3qgheysmr7tk9uvwluddznju3nuxalevvs2d0jr5 nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr After watching some Nostr Dev videos about NDK I was wondering: are there some nostr clients that uses the outbox model and the "Nostr Connect" login option (the one with the bunker url talking with Amber, like in nostrudel) that are done with NDK? Does NDK support this type of auhtentication?

Motherfucking client*

Some thoughts about Fedimint and Fedi given the recent launch event:

I like the idea behind distributed eCash at least in principle, BUT I still have some doubts on the practical side of things:

- As I understand, Fedimint is distributed only at the cashu level as the federation still requires a SINGLE lightning gateway to function properly. While it is obviously a nice thing to have, I wonder whether this will really make a difference in practice: if we think federations as communities or companies, they might be "distributed" technically, but are still a "single" attackable entity, so what's the difference here from a simpler cashu mint?

- When Fedi open source code? You have money and chat together and expect us to trust a closed source app? I hope the code will be available soon (and with reproducible builds)

So in the end, what I want to say is that unless we get federations composed of different entities that have little to do with each other, like a sort of good "cartel" (so that multiple guardians will actually make sense), fedimint "is only" useful to increase (how much? You still rely on a single LN gateway) the technical difficulty to attack a federation (guardians on geographically distributed nodes, on different cloud provider or datacenter, with different implementations, etc...).

I might have been to harsh here, but this is just my first thought about this, anyway I still like the general fedimint idea.