"The internet is as bad as it is partially because payments are so bad. Payments forced us to think in accounts and accounts forced us to be traceable." 🎯💯

This is interesting 🧐

All of what you are pushing and creating with ecash is so powerful as it’s just not worth the state even trying to censor which in turn means they are forced to accept privacy.

So then are you kind of living within the ecash systems you use? Meaning, the SP will be incentivizing staying within their garden?

Kagi needs this. Every web search today could be linked to the payment, they pinky promise it's not. Should be a low hanging fruit as they already accept LN and are familiar with nostr.

In cybersecurity there’s the “zero trust” model. I wonder if collateralizing all network requests with eCash can be part of the model too?

⚡️

Keychat APP

Keychat is the super app for Bitcoiners. Autonomous IDs, Bitcoin ecash wallet, secure chat, and rich Mini Apps — all in Keychat.

Keychat is a chat app, built on Bitcoin ecash, Nostr protocol and Signal protocol. Keychat is inspired by the postal system — stamps, post offices, letters. Keychat uses Bitcoin ecash as stamps and Nostr relays as post offices. Keychat uses Signal protocol to ensure message encryption security and meta-data privacy

One reason why pay with lightning never took off on the web is using sats denomination when everything is priced in $$. The cashu tokens should be of unit USD or Euro to make this possible..!

Could you elaborate on not having a risk to be regulated? Why do you think that is so?

cashuAeyJ0b2tlbiI6W3sibWludCI6Imh0dHBzOi8vbWludC5taW5pYml0cy5jYXNoL0JpdGNvaW4iLCJwcm9vZnMiOlt7ImlkIjoiMDA1MDA1NTBmMDQ5NDE0NiIsImFtb3VudCI6OCwic2VjcmV0IjoiTEVEYzN4OWpQNGpUVEZaSmMwMFBQY3dCYnJUaC9UNGJId0V6c1paZnNjMD0iLCJDIjoiMDNhYzQ0MDM0YmM4NjIxNzFkNDdiNTBiYTAyNzhjNzMyZDgyOTdiN2YwMTY3NTJhMTJhNzA2NzAzMGU5ZGQ4YTJkIn0seyJpZCI6IjAwNTAwNTUwZjA0OTQxNDYiLCJhbW91bnQiOjMyLCJzZWNyZXQiOiIyWS8wdGFINk5QRnc0eHdpclpsQWcrQUtvOU9CS3EyTE05a0ZCV1kyVmJNPSIsIkMiOiIwMjViYWE0ZTgwYmNhNzVmNzdlZGViZGU3Mzc4ZDQxYjMxNGRiZTc3ZTlkMjM4NzNkNzk0ZjFiZTRmNjMyYWQzNTYifSx7ImlkIjoiMDA1MDA1NTBmMDQ5NDE0NiIsImFtb3VudCI6NjQsInNlY3JldCI6ImNkV3ZZdkpRajdLZTJjcVJaRGpwSkxoWEhvSko4OXUxV2x5TVIxVEdCZnc9IiwiQyI6IjAzMGMyYzZjY2NiYTFiNWY0ZDIyNWQxMWRhNmQxMjAyZjk0NGY4ZmE5N2Y2YWExZjFmNjFmYjZmM2MwZDA4NmQ1OSJ9LHsiaWQiOiIwMDUwMDU1MGYwNDk0MTQ2IiwiYW1vdW50IjoxMjgsInNlY3JldCI6ImJPMVRmR05LQmF1SVZvT1FDdHdDZFBGZGlZVy91RmR4RWxYUmVoQXUxV2c9IiwiQyI6IjAyNDFiZDBmYjIwZWI4NmJmZjFiMjM5NTYxMzhlOWVlNDBjOTVmMzgwNGE5MTBlNjg3NDkxMDA2YWQ1MjhiMWIwYSJ9LHsiaWQiOiIwMDUwMDU1MGYwNDk0MTQ2IiwiYW1vdW50IjoyNTYsInNlY3JldCI6InVaSDBucmhnNStvcDEzaUZOUlNFbTA5RVBLZ0FmWTJ0YnZRZ0JHR3BmTlE9IiwiQyI6IjAzODdhMGQ2ZDg1ODk5NzkwMDA5YzVkNWY2NGVhZDM5YzI2Nzg0OTNjNTFhMDk2NzBmZDlhODFiOGE5YzhlMzk1MiJ9LHsiaWQiOiIwMDUwMDU1MGYwNDk0MTQ2IiwiYW1vdW50Ijo1MTIsInNlY3JldCI6IlpDZ0ZHM3VIUGZNZXVrcHdqK0NIRC9mNDJaUml2SER0L0ZhbDZWbW5IbWM9IiwiQyI6IjAyOTE1MjhmMmQ5YTBmMzkyOWJiMTE3NTdjNDU3OGY0ZWMxZTc4YTQ3YzcyNjUwOWY3ODFlNzE1YmQwY2VlZGI1NyJ9XX1dLCJtZW1vIjoiU2VudCB2aWEgZU51dHMuIn0

Lfg

I think this should be the model for some (or even most) nostr relays. Relays are service providers, if you rely on them for reach, why not incentivize them for every post, and since you directly rely, ecash makes more sense

This looks very neat!!

Soon ™️

@calle , is there currently a feasible easy way to build this kind of service-specific credit system without user accounts? For example, if someone wanted to create a website with a credit system similar to a real-life arcade (user buys credits with money, and credits can only be used for the games within that arcade place), how could they get started?

Coming soon, not Comming Soon - on the website, for whoever is maintaining it

When you say ecash, do you mean Cashu? If so, I think we're on the right path. 🥜🫡

Coming when ? Can you add an email subscribe to be notified when it’s out please

@Dan Are you building keychat? If so, I'd love to chat with you abot how you're implementing the Signal protocol. I have an open PR on the NIPs repo right now to bring Signal like double ratchest to Nostr.

GitHub

NIP-104: Double Ratchet (End-to-End Encrypted) DMs by erskingardner · Pull Request #1206 · nostr-protocol/nips

This NIP adds several events and details a protocol to add E2EE DMs to Nostr that use a double ratchet (based on the Signal protocol, but without t...

Yes, of course 😉

Legend. Looking forward to what you guys are working on.

Give me apkkkkk

Since this is using Signal, will it require a central coordinator?

No, just need nostr relay as post office. Encryption/decryption is processed on client.

Hi Jeff. About message encryption, Nostrat fully reuses the Signal protocol (X3DH + double ratchet) and reuses libsignal. First, let's return to the mechanism of the Signal app. The Signal app uses phone numbers as user IDs. When Alice downloads the Signal app and knows Bob's phone number, she adds Bob as a Signal friend by entering Bob's phone number in the Signal app. The Signal server then returns the following data associated with Bob's phone number: Bob's identity key IKB, Bob's signed prekey SPKB, Bob's prekey signature Sig(IKB, Encode(SPKB)), (Optionally) Bob's one-time prekey OPKB. Alice then combines this with her own identity key IKA and her ephemeral key EKA to complete the X3DH operation, and then initiates the double ratchet algorithm to start encrypting messages. When Bob receives the message, he can also initiate the double ratchet to decrypt the message. Let's now assume that Alice and Bob have both downloaded Keychat and want to communicate using it. Bob displays his QR code, which contains his Nostr key and Signal-related keys. Alice scans it. Alice can then complete the X3DH operation and start the double ratchet encryption. It can be said that Keychat, unlike Signal, does not use a server to pass the related Signal keys. Keychat treats the Nostr key as a phone number. If Alice only knows Bob’s Nostr key, she can send a special NIP4 message to retrieve Bob’s related Signal keys.

>>Keychat fully reuse signal protocol.

Sure that all makes sense. I just wrote NIP-104 basically codifying that into the spec. Just curious how your implementation is done. Is your code open source somewhere? Would love to have a look. Have you looked into syncing on multiple devices yet?

Code will be released soon. Keychat doesn’t support syncing on multiple devices. Every device has its own ID. And those devices can communicate through group chat. It’s very hard to support syncing for double ratchet algorithm. More difficult in conditions there is no coordination server.

We are pleased to find a very good 【prototype】; people can easily understand the postal system, which allows them to comprehend ecash as e-stamps, Nostr relays as post offices, and the necessity for messages themselves to be end-to-end encrypted. Messages need to continuously update the recipient and sender addresses.

Thanks. Modified.

you are Chinese developers? i feel I can read that in your English. who is backing you guys? very very nice and clean and sophisticated looking project.

Just bitcoiner.

Concert tickets.

If I understand correctly I believe that's what @OpenSecret did.

Mutiny Blog

Blinded Authentication Tokens in Mutiny

Mutiny's unique privacy-preserving approach to solving lightning addresses with fedimint and blind authentication tokens.

Yo. Check this. `/mint` only. No `/melt`. Maybe `/swap`?

frick im excited

Sorry to be so frank, but, why doesn't the BIS , regulators, etc follow their own fiat pronouncements and definitions that the legal tender of any country is by definition money/currency globally?!

I think one difference is that credits on an account can't be traded for cash, but ecash can be. Amazon vouchers and gift cards can also be traded for cash, but something something FBI! GET ON THE GROUND! or something. I feel like even gift vouchers are going away like cash, and when as it does, its perception as a tool for criminals and the subsequent lack of empathy from the people lead to it becoming criminal.

Looking at this as a possibility for a meatspace project I'm working on

Interesting Before being bit by the orange bug, I was a CPA/data analyst Sounds promising!

This will be possible when USDT lands on lightning in usable form. Should start appearing in a month or two, but someone needs to build the rails from taproot to cashu.

Can someone elaborate this part? "Closed ecash systems also do not run into risk of being regulated as money transmission services for the same reason you don't have this issue when you use a BTCPayServer for selling a VPN, for example. "

This use case would require regulatory cover in most places.

How so?

We’ve talked to a few regulators in Asia about that very model specifically. The crux is that it’s not generally seen as a closed system. A BTC Pay server doesn't hold funds or issue tokens. It just automates the process of generating invoices and verifying that a payment has been made to the merchant's wallet (or whatever). A Cashu mint though is a tokenised credit system, which most regulators see differently. For example if you're a merchant and you issue gift certificates then as long as they can't be exchanged for cash (either outright or by giving change in any serious amount relative to the gift certificate's value) then you're good to go in most places. But for Cashu the holder can cash out anytime, either remaining value after a purchase, in any amount, or they can cash out the top up without purchasing, etc. So it's open and exchangeable. In some countries that's a grey area, but in others it's pretty clear that this is a regulated use case. If looking for Cashu entry points that are less likely to require regulatory green-lighting then I think there are better ones than this, again though depending on the country.

In the example I've made, they can't cash out but just pay back.

Which entry point do you suggest looking into?

Employee-facing use cases for businesses, such as small-expense reimbursement (think of a Cashu-powered Expensify) and other things like internal employee rewards programs. We're actually going through a VC accelerator out here right now to try and get funded for a Cashu + these types of use cases pitch, so fingers crossed. (We're in the "VCs can be good people too" camp.) These use cases are generally much easier via a vis regulation, as the employer-to-employee payment relationship is a whole different thing from the regulator's point of view.

He was already thinking about bitfamily a year ago. Lol View quoted note →

Ah right. Though “pay back" and "cash out" would be seen as the same thing I feel. The only path to argue that I can see is to argue that Cashu tokens represent a form of gift certificate. But gift certificates are supposed to be non-monetary, limited-purpose instruments. Depending on the country, customers can sometimes get a refund on higher-value gift certificates, often on condition that they ID themselves and jump through a lot of other mandated hoops. But for smaller gift certificates the merchant is not allowed to refund. And when it comes to giving change, usually the customer can't get back any change except if it's a small amount in view of the original value of the gift certificate. So they’ll just add a pair of socks or whatever to use up the remaining amount. What you’re suggesting might work if you *must* spend *all* your tokens at that merchant (once obtained there is no way back to the lightning network for your tokens drawn on their mint). But then besides some of the niftier programmatic aspects of Cashu you lose a lot of the value and it becomes something like a virtual in-game currency. Cashu could still be a good backend for only that though, which goes to show just how versatile it is.