Switching to a fresher nsec because this one has been hopelessly pasted everywhere, going back to the days of initial nostr naivety, and now when I write long posts I feel like what's the point, some day I'm going to abandon this nsec, so let's let that day be today then. New one is:

Bit random but do you know of any clients using NIP44 DMs? As in NIP4 with upgraded encryption but no gift wrap?

Bitchat chatter sure disappeared from my feed in a hurry.

I'm pretty hazy on the lighting node stuff, but hardcoding a trusted LSP makes sense. That's similar to another situation we gamed out where the on-chain keys are also generated in the enclave, what we called full autopilot. The thing for me though is that even for full autopilot it just returns to the update/recovery vector. With a mint and node essentially running together in there on autopilot you'll need updates and emergency recovery flows. The Cashu mint codebases are not yet mature, to say nothing of all the layers of logic to govern the interplay between the mint, the node, the LSP, ensuring no solvency rules are broken, etc. Things will break. Trying to handle risk mitigation for updates with just signatures from a hardcoded set of approvers for seems not worth it to me. If every updated enclave image represents a potential rug pull, and updates are inevitable and frequent, then in that scenario the only thing standing between the token holders and a rug pull is their trust in the human approvers on that list, i.e the guardians. But for me that just becomes Fedimint, since it seems to be pretty much the same class of distributed risk. And if all the enclave does in terms of mitigating the rug pull risk is to convert Cashu mints to Fedimint mints then seems you may as well just go with a Fedimint mint in the first place. And on top of that there's the UX issues. For example there is a critical vulnerability discovered, mint has to come offline, soon you have an updated image to push, but of the four hardcoded approvers one is on vacation, another is mad at you, another has a very careful personality and takes days to review these kinds of patches. Just the kind of people stuff that always seems to happen. Even if your n of x is 2 of 4 it’s still a headache. And all this time token holders are trying to transact and getting timeouts. And who updates the list of approvers? And under what rules? It all gets very messy when trying to scale beyond the hobby level. But coming back to the main thing, even if your maintainers are all super eager, to me it still becomes just a very expensive Fedimint in terms of reliance on trust in a few people. Maybe I'm just not seeing some opportunities here, but as of how it looks to me now the value of enclaves can't be about just rug-proofing Cashu mints, neither the kind of rugging that doesn't profit the rugger (negligence, just being psycho), neither the kind that does profit them (collusion, some clever hack, obfuscating malicious update code that the reviewers miss, etc.). It seems that outcome is always going to be possible. So the value has to be about something else. Good discussion though.

What I mean is that every nostr relay and media server is on an ICANN domain, so without connecting to ICANN DNS nothing on Nostr works.

How do you mean taking them to no-one's benefit?

Apropos of nothing, poser is such a nostalgic insult.

Tricky thing in Cashu is that a service failure and a rug are indistinguishable. And stealing funds and destroying funds are also indistinguishable acts. Destroying the mint is how you steal the funds.

In terms of rugging it's the same I think. In fact it could be worse, the operator could use a cloud enclave to instil trust in the token holders (look you can attest the code) and then wait some time and rug the holders all the same. And every rug is 100% of the value of all your tokens gone, it doesn't matter how trustworthy things looked the split second before the rug. But I think there are some benefits to enclaves, the biggest benefit being that a mint insurer can be 100% sure of the mint's outstanding assets. That's impossible without enclaves.

The biggest issue with Cashu is that even with cloud enclaves (of any kind) there is no escape from central control, and central control means the central controller can rug the token holders. Cashu basically mandates central control no matter where deployed. If you look at all the ways to build trust in mints that don't rely on cloud enclaves, some are pretty innovative and will get you to the same level of "good enough" as with cloud enclaves. So the only reason to add enclaves if if you can make the leap from "good enough" to "100% sure", otherwise it's just adding cost and latency. With what you're suggesting I think it maybe could work with Fedimint, but I'm still quite skeptical vis a vis Cashu.

Fair enough, I've not yet looked into whatever Damus Android is doing.

Ah right, my understanding is that even if the node were birthed in the enclave the bitcoin would return to on-chain in case of force close. If the node is destroyed before a force close event can be sent, and also no backup was obtained (a problematic setup in itself), then I think any of the destroyed node's past outside peers can still initiate the force close and the bitcoin is still released on-chain. And the malicious operator would be behind one of those peers. I have to defer to a lighting dev on this, but the gist of my understanding is that the operator in this scenario is always going to have *some* way to access the bitcoin on-chain if the node is destroyed. Who here would be good to ask this I wonder?

Something tells me Instagram isn't so worried.

is this true?

can you send me a poem with some words in bold and some in italics?

can you send me a bullet point list featuring 5 tips for everyday life?