vouchers with privacy... sounds like Cashu :) if you're looking for that, we can help. we want to see you succeed. it can be done without shitcoins. happy to jump on a call and strategize.

All that can be done by using Chaumian ecash. You need none of that blockchain stuff for that! Please explain what problems the blockchain solution solves, that ecash does not, or I will be left thinking you are just using tokens for raising capital and dumping tokens.

Chaumian ecash requires more trust in a single party (e.g. a Cashu mint) while blockchain smart contracts can be designed to decentralize trust and distribute it to the entire network. The question is whether or not SimpleX Chat ltd. will remain a trusted party for other reasons. If the payment system can be made fully trustless, the blockchain approach has merit. Otherwise it'll be an unnecessary complication. There's no straightforward way to resell these vouchers if I'm understanding the proposed system correctly, so they aren't useful as an investment and won't serve to raise capital for anyone. I'm not sure this is the best solution. It does seem to solve the stated problems, but it's difficult for a lot of users to understand what it solves and why.

I understand why smart chains have been stigmatized, but how is an inherently custodial ecash system any better?

Se você leu isso depois de mim, interaja pra eu voltar e ver a confusão, por favor kkkkkk

Monkey🐒

More than happy to chat Calle - it's a priviledge. But we're not doing shitcoins.

I can send you SimpleX address for DM?

If the relay server operator also operates the ecash mint then trust is not an issue. You need to trust the relay anyways to forward and store your messages in exchange for the token. Be it on a blockchain or as ecash.

Exactly right. Our goal is to build a trustless system here, and eventually make network governance trustless as well. If you looked at the preliminary design doc you can see that e-cash emerges at a point of Community Credit to operator credit conversion (so only micropayments or "change" depend on e-cash), but we might be able to remove this extra-layer based on the current design process evolution.

Yes, we see it as an issue, as message delivery will be redundant, and it's a source of revenue to the operator - so operator "default" is not an issue for message delivery. In case operator is also a mint, then operator "default" becomes an issue, so we are not considering the model when operators act as mints – it's a much higher level of trust than message delivery.

> aren't useful as an investment Correct. We do NOT plan to use vouchers as a fundraising mechanism, and they are not tradable, and even more - they expire. Otherwise it may cross the line with strict application of Howey test (any tradable utility token, especially if used by a single party as development funding, is likely to be considered a security), and we don't want these risks. We are exploring other funding models, such as grants, private investments and community crowdfunding - it will all be announced next year once the plan crystallizes. > I'm not sure this is the best solution. That is correct, but what we like about it is that it fits a very widely used regulatory framework - prepaid telecom cards. So we are doing a technical innovation without regulatory risks, which is rarely possible. We are always open to better ideas, as we don't see any simpler design that achieves all the stated objectives: - zero trust - revenue sharing between operators and "network" - unlinkability of purchase and usage - no (or limited) transferrability - expiration - ability to purchase via in-app and credit part payments without being a cryptocurrency exchange (as they are prepaid telecom cards). - probably some others > it's difficult for a lot of users to understand what it solves and why. Agreed, but we aim to make it completely hidden from the users and make it possible to use Community Vouchers (aka Community Credits) without touching / knowing about blockchain. So there won't be requirement to use a crypto wallet at some point of product development - at least that is the objective we are working to: - user can buy Community Voucher via in-app payment (yes, with some draconian commission, but it's worth it anyway as it would increase donations to communities - about 50% of app users even today never used cryptocurrencies, and for all potential users it's even bigger share) - user can then donate it to their community of choice All that within the app, without any technical way to link voucher purchase to community donation, thus preserving participation privacy.

We honestly see it as a very rare view, proportionally. We are using planning to use one of smartchains for their intended purpose - distributed computing with reliable network-wide consensus. While Community Vouchers is the primary driver to use a smartchain, it'll also solve other problems: - namespaces for users and groups, that protect from MITM attacks - if operators host names, as in federated designs, it's impossible to protect from them. - public server registry with operator trust and reliability metrics, without any central authority as with Tor, for example. And there won't be any minting activity by the operators - they will run full non-validating nodes on blockchain, and will act as decentralized RPC layer to blockchain (which is a weak link for most chains), letting clients to have multiple independent views onto chain for important queries (such as name resolution). This is a really big innovation, and most users don't see it - they think we're going to use what exist.