Let's apply this line of reasoning to any other centralized apps people use today.
With a fiat banking app, when you send dollars to someone using Zelle to pay for lunch, they never received anything other than a database update statement.
If you send Bitcoin on Strike or CashApp to another user on the same app, they never receive any actual Bitcoin... they simply get a database update statement representing an IOU for Bitcoin in the future.
This is exactly how a Mint works as well... only, the database is ecash instead of SQL. But why does it matter which DB implementation was chosen? The social implications are the same.
The average person knows that the money in our fiat banks are just numbers in a database. But they don't know HOW those databases work or how the bank's financial plumbing works. They don't need to. This is the same for a Mint. We don't need to know that ecash is being used to move things around. It's enough to know that we are trusting a Mint, just like we trust a bank, and we could be rugged. That is enough for 99% of users. Don't confuse the users with the inner workings of it... don't confuse them with terms like "ecash" at all.

"they may sell ecash tokens for USD or who knows what"
Okay, then they exchange their ecash for Sats from the Mint, and then exchange those Sats for USD or whatever else. And they do this exchange in an automated way, behind the scenes where the user never realizes they made such an exchange!!!!
I feel like you're arguing that people should be able to trade their SQL database entries in CashApp with each other instead of the IOU Bitcoin the entries represent.
Ecash is just the DB layer. Stop treating it like a tradable token.
Sure, we could trade SQL rows instead of the assets within those rows.... but holy shit, we're just being stupid at that point. Ecash should never be used like this. Let's just nip this crap in the bud now.
If we start treating ecash as anything other than a simple DB layer, we're going to start having problems. It will start to get very shitcoin-like very fast.
Although @machuPikacchu is right that people might start blaming Bitcoin if they get rugged by mints and all they know is that they had “Bitcoin”. People who get rugged by banks may not know how the bank’s database works, but they know that they don’t actually have cash in hand. I think we need that same distinction for ecash: it’s like putting gold in a bank and receiving notes in exchange.
reply
People only blame Bitcoin now because of how new and under-utilized it is (relative to fiat). They don't understand it.
In a world with thousands of local mints, with LN nodes connecting the mints, and millions of merchants taking Sats for payment.... Bitcoin won't be blamed anymore. It will be very clear that the Mint's guardians rugged you, and not the money itself.
I think we should develop for that future world, and not for today's world. Thus, we should treat ecash simply as the DB layer for Mints, and nothing more. In fact, let's drop the ecash term and start saying "Mint Specific Decentralized Database System." Or MSDDS.
Here's my new marketing suggestion for the Fedimint team:
"Ecash doesn't exist. Fedimint implemented MSDDS as a way to decentralize the internal databases of these Federated Mints which themselves are a new L2 strategy for the Bitcoin Ecosystem."
There, that's what devs need to start saying. Fixed this ecash debate right here, right now.
reply
No. If you build based on a future that doesn’t exist yet, you won’t have tools that work to get you to that future in the first place.
reply
I can sympathetic to this line of reasoning, but I don't understand how it takes into account the "bearer" nature of ecash. Thoughts?
reply
Let's use gold as an example. We all know the story of how banks started issuing paper notes that could be redeemed for gold at the bank. This way, the paper becomes a bearer asset as well.
This is the same scenario you're suggesting with Bitcoin and ecash, where Bitcoin is akin to gold and ecash akin to the paper notes.
However, what if instead of issuing paper, the banks could hammer the gold thin enough to become paper-like? Do a google search for "Gold Backs". I don't think they had the technology to create these Gold Backs way back in the day, which is why they went with paper notes.
Mint software can be written in such a way that we get the bearer-asset properties of ecash, without exposing ecash at all. Similar to how we could use Gold Backs instead of paper notes. (it's a rough metaphor, but work with me).
The code can be written so that the ecash piece is treated as a DB layer only. We don't have to acknowledge the bearer asset part of it. I mean, we acknowledge it by calling it an "internal, decentralized database". Internal to the Mint. We already have Bitcoin as a universal, global, external decentralized DB.
If new ecash is created and destroyed every time Bitcoin leaves or enters the Mint, then there is a 1-to-1 relationship between Sats and ecash. So why not just display the Sat value at all times to the users of the Mint? Why does the ecash layer need to be exposed? It's just the DB layer. But it's up to us to keep it that way and prevent people from trying to turn it into another form of shitcoin.
reply
As far as your banknote example, I think it is apt. I agree that ecash tokens will probably function like such notes, with a market developing to help people determine the real value of tokens issued by various mints.
The Goldback analogy seems to require changes to the various ecash protocols that currently exist, and that's way beyond my paygrade, but if you have ideas about it I hope you are able to implement them.
reply
Doesn't an ecash token differ from a DB entry in that the mint cannot stop me from trading it to another user?
I can't trade my zelle points (dollars in my bank account) without the bank's permission.
I can give you my ecash tokens and the only thing the mint can do to stop it is shut down the whole mint and stop doing business.
This is an important difference. And it us the thing that makes an ecash token more like an altcoin than a DB entry.
On the second point, if I directly trade ecash tokens for USD, there is no exchange function to the mint. WIth a LN gateway connected to the mint. If I sell them some ecash to get them to pay a LN invoice on my behalf, the mint has no insight on that transaction unless they are the runs running the gateway as well. I don't think there is any reason a mint won't have two or more LN gateways that you might use, run by different entities than the mint.
reply
Yes, absolutely.
Everything I've said here should be taken as design suggestions for the Fedi team and other Federated Mint devs.
Technically, Bitcoin is just a fancy, decentralized database as well. People give the DB entries value because we recognize its use-case for money.
I'm suggesting that we don't allow ourselves to give ecash any value, based on principle. The same way we don't value shitcoins, even though they technically are similar to Bitcoin. It's the social layer that I'm appealing to here.
I'm asking the users and the devs of Mints to view ecash simply as the DB layer. To give it special value based on its decentralized properties, the way we do with Bitcoin, is akin to shitcoining.
It is very fuzzy and complicated, which is why I'm having this conversation today with people here. I'm trying to organize my own thoughts and see if others can poke holes in my arguments so I can refine them or change them.
reply
Yes, absolutely.
Sorry, I'm a bit confused. Can you elaborate? I'm particularly interested in your thoughts regarding the point that ecash is a bearer asset, while a DB entry is not.
I'm suggesting that we don't allow ourselves to give ecash any value, based on principle.
I think I have been taking the extreme opposite view as what you say here. I'm trying to say that in the future ecash tokens may have value on their own, like shitcoins, but good ones.
reply
See my latest response to you above. We're starting to have the same conversation in 2 different places, lol. It's a good conversation, though!
reply
Sorry about that! Agreed!
reply