Welcome to the future. (Of scamming) 

 Few 

 @ODELL implicitly agrees 

 understatement of the year

🤝 

 Using a different kind, like 4, would hardly increase privacy but would make it harder to find those events and pollute the original intent of the overloaded kind.

I think for privacy it would be easier to rely on NIP-42-guarded relays that solve this for you at no extra protocol complexity - you need to prove you control the nsec before the relay will serve you the token events

Another alternative is to delink your main npub (either via a new key or a derivation path) from the wallet/token events; although i think this is inferior to using NIP-42 relays for the tokens (timing attacks, etc)

Another is gift wraps, but again, I think it’s unnecessary extra complexity that doesn’t give you anything that NIP-42 gives you 

 Yeah, every time there’s a wallet balance change, since it stores the proofs. Note that it’s not “updated”; the proofs are stored separately in multiple tokens (the client can choose to consolidate/fragment as it sees fit though) 

 You can put multiple proofs inside the same token as long as they are from the same mint 

 So you would have multiple 7375s from the same mint with one or more proofs inside 

 You are also signaling from the start the mints you want ecash on, so you could even just ignore mints you don’t want, or yeah, like @Tim Bouma says, you try to redeem and ignore the mints that dont work 

 the recipient is EXPLICITLY saying "zap me on these mints" -- so this point is kinda moot

right now the vast majority of nostr users are on either alby, WoS or primal (myself included)

with this, instead of having a couple of huge custodians you can disintermediate that market and have and use, at the same time, 5, 10 custodians

you can and should sweep the balances from the WoS of the world into whatever you have.

There are many people running small LN nodes that are not being used as their zapper because running a zap-capable LN nodes is much more involved than running just an LN node.

With this you could literally just use the custodians while you are offline and the moment you come online sweep everything to your own LN node. 

 Wow, damn! 🤣 

 Same; even while running a LN node I use custodial lightning and sweep to my node regularly.

With nut zaps you can sweep the tokens IMMEDIATELY to your own lightning node: so have the best of both worlds; fast reliable zaps that cannot fail and you are only using the mint until you come online and sweep to your node.

Beats a HODL invoice too! 

 That’s always an option, but are you getting any feedback from outside your group? It sounds like your event model might be trying to do too much/be too narrow; atomic, more composite events are better and way easier to develop for and particularly to get interoperability going

Where are you publishing/discussing the data modeling? 

 It varies across clients, but most clients will read/write the relay list they use. As with most things though, there are two standards; an old-hacky stringified-JSON in the follow list, and the more modern approach of using event kind 10002 to store read and write relays.

This latter is (one of the) key pieces of the puzzle that we call “outbox model” (formerly gossip) - which is how a client knows where to read/write for specific pubkeys and is one of the key aspects that makes nostr credibly censorship resistant.

 We also have a NIP (87) for client-specific configurations which can serve as the basis to, for example, copy someone’s configuration of a particular client. 

 All these things are already store on relays, so they should seamlessly follow you to any client you use 

 why? 

 damn it 😂 

 This is the way

WIkifreedia changelog's on the title is a link to my wiki entry of wikifreedia

https://m.primal.net/JPEP.png 

nostr:note1zs9w02jqwz9mfgw0xrz045qd3p7dq3u474qfjdhw6t8zd2mrtv5s73gvy9  

 no, your own proofs are stored as encrypted events

the nut zaps are sent unecrypted as pubkey-locked and swapped by the recipient to encrypted events 

 yeah, the ecash would still be on your device; but I'm adding the idea of "health checks"

so if my wallet is configured to store the tokens in 3 relays and one of them goes offline, or is not returning the tokens it should have, the wallet will either warn the user or automatically rotate one of the relays out and republish all the unspent tokens to the new relay 

 relays 

 so the wallet event specifies that wallet's relays

token events are stored on those relays

nut zaps are published on relays following the outbox model, since it's a message from sender to receiver

so imagine this:

you create Wallet A, you designate that wallets relays to be wss://umbrel.local -- only you have access to read/write on that relay

I send you a nut zap -- I check your outbox relays, which are some publcly accessible relays

I publish the nut zap there, pubkey-locked, unencrypted

once you swap it, you encrypt the new token and save it on wss://umbrel.local 

 yeah, I think what calle is getting at is that the local device can cache the proofs locally too 

 yeah, I mean, since they are just nostr events it leverages the same cache adapter I'm using for the rest of the thing, so the balance could definitely show before you're even connected to the relays -- right now I have the wallet configured to skip the cache -- but it shouldn't 🤝

once I remove that explicit "bypass the cache" the balance will load from the same REQ even offline

you'll be even able to do private zaps offline with this thing 

 I am writing the docs for the new `ndk-wallet` library I'm packaging right now 😂

you'll be able to do fun things like:

ndk.wallet = new NDKWallet()

user = ndk.getUserFromNip05("calle@cashu.me")

user.zap(1000, "yoooo") // ecash zap, preferably from mints we have in common

user = ndk.getUserFromNip05("jack@cashapp.com")

user.zap(1000, "yoooo") // if  @jack hasn't created an ecash wallet it'll get a bolt 11 and pay it with my cashu wallet balance 

 yeah, a zap is a zap! 😂

it also supports zap splits -- it's basically the same zapping logic, it just how the money is sent what now will be pluggable to other transport layers instead of just LN 

 dude, we had a very similar idea back in SEC-01 -- I remember discussing this with  @zach as we were walking around Madeira. I think the idea was having a coffee shop you walk-in every morning and they print a "newspaper" of stuff that's interesting to your npub. 

 It’s locked to the pubkey of the recipient; once you send the zap you can’t spend it anymore; only the recipient can. 

 😂😂😂😂😂 

 not by default; you can make it so if you wish 

 don't give blank-signing access to apps you can't trust -- I think this will be an ongoing lesson for people in the next decade -- but it's irrelevant of whether this is money or your identity -- you simply shouldn't do that without, at lease, getting a sample of what the app is asking you to sign.

This is the same idea as WoT -- you can fool some people for a very short-lived time at great expense.

That said, that's why I also added the concept of having a user-level passphrase on a wallet -- you could have no passphrase on low amounts, and as soon as you get to a certain limit your app is instructed to move to a cashu wallet that requires a passphrase to decrypt the proofs. 

 yes, they are compatible -- with this, if you try to zap someone that doesn't have a cashu wallet announced it will do a regular bolt11 zap from the cashu balance

(how cool is that?!)

yes, these are pubkey-locked cashu tokens, locked to the pubkey of the npub with a "02" prefix for parity

so the proofs are actually unencrypted, anyone can verify them, but only the recipient can swap them 

 there is no seed being created by highlighter; these are bearer tokens so the secret is in each proof  --

the difference is that, instead of having one wallet per app, now you have one wallet for your npub, available anywhere you have your nsec with you 

 very important difference 

 they are coming, from  @JeffG's hand 

 thank you 😀 

 working on it right now

https://m.primal.net/JPEj.png  

 It’s unencrypted and you need your nsec to spend it; you’re not signing an event, you’re using your private key to provide a signature to the mint 

 P2pk 

 https://github.com/cashubtc/nuts/blob/main/11.md 

 All must disappear at the same time; I have the concept of “relays health” on each token so that can always keep copies in n relays 

 Free banking. 

 No, you opt-in.

People can still send you ecash due to the mere fact that you have an npub, you can always choose to not redeem them 

 No, it shouldn’t; dm relays might guard REQs behind AUTH which you don’t want for public zaps; for private zaps you might, yeah 

 Yeah, it’s on my GitHub; still tightly coupled to the highlighter codebase but I’ll be extracting it today into a nicely packaged thing 

 lol, both of you have custodial lightning for your zaps 😂😂 

 Yea 

 Not yet, but I will probably write one; the beauty is that it doesn’t need to take custody at any time; you respond to an LNURL request with the mint’s bolt11, so it’s extremely lightweight 

 They don’t do the new spec, they just send you unlocked ecash via a dm 

 You can do whatever unit you want. Msats are dumb anyway, but you could easily run a mint that uses them 

 You can’t prevent someone from sending you a check in the mail; you can simply not claim it.

People have been sending coinjoined bitcoins to states and legal entities for ever; there’s nothing they can do to avoid it, but they can ignore the money 

 Demo video tonight

🔥 unified baalnce; one nsec 🤝 one balance across all clients and devices
🔥 instantly be able to receive and send zaps - no more “oh now download this other app and pair it with this secret”
🔥 public and verifiable zaps provably locked to the recipient
🤙 no missing zaps: the sender publishes the receipt! No lag, no missing zaps!

you can send zaps directly into someone’s wallet; I could have a wallet that is publicly called “sats for coffee” and others can send money to that specific wallet 

 Yup! Each nut sack is independent, some of them can have an extra passphrase; different mints, different relays. 

 they are public by default so other people can now they should send the money using those mints and they can choose to use mints that sender and receiver have in common to nut zap you

i.e. if I have a balance on mint A, B and C and you signal you use mint C clients can prioritize using balance from mint C.

I already wrote all this logic and will wrap it on an ndk-wallet adapter which will allow you to say

user = ndk.getUser("<niels-npub>")
user.zap(1000, "hello, niel!")

and it will determine:

* whether to use ecash balance to pay a lightning invoice (because you haven't signaled you want nuts)
* mint you want to receive to
* mint to send from
* etc, etc

when you send the payment you need to say in which mint it's in which also increases the signaling of how much money is going in/out of specific mints 

 Checking on this, brother 

 HAHHAHA 

 back up 🫡

https://zaplife.lol/
 

 which one?
 

 Oh wow, that’s super weird indeed! 🤔🤔🤔

Im going to try and see if I can reproduce the issue.

I have a massive update coming with pin features and a bunch of other things; hope I will be able to give you early access by tomorrow 

 hmm, that sounds like it could be an issue with the extension -- sometimes that happens where the extension gets in a borked state and the apps can't really access it

can you try quitting your browser and trying again?

have you logged in with a different account in this same browser?
 

 Oh man, I really am 😂