I had this idea / pet project once where I did exactly this for email. Emails would immediately bounce with payment link and explanation. If you paid you get credit on a ledger per email address. Only then the mail goes through.
You can also integrate it in clients by adding payment/reward claim headers.
Bill Gates already had this idea. All efforts to change email were already documented 25 years ago. The biggest changes are it is more centralized these days, SPF/DKIM/DMARC, JMAP innovation, oh... and one more thing! It is HUGE!! HTML email is the default...
And it would even still work for the CEO, they would just have to charge more than $1.
The real problem is we don't have a low-friction digital payment system that allows individuals to automate sending payment requests for small amounts of money to each other without requiring everyone to sign up for a merchant account with a financial bureaucracy.
> The real problem is we don't have a low-friction digital payment system that allows individuals to automate sending payment requests for small amounts of money to each other without requiring everyone to sign up for a merchant account with a financial bureaucracy.
>First you have to make it low-friction. If I want Joe Average to send me $1 in cryptocurrency, how is he getting $1 in cryptocurrency to send me?
Absolutely. You're 1000% correct. Cryptocurrency is way too high friction for stuff like that. When I wish to spend crypto, I need to:
[If you don't have an exchange account already, you'll need the 0.x steps too!]
0.0 Create an account on an exchange which is legally allowed to operate in your state/country;
0.1 Provide all sorts of KYC/AML info including photos of yourself and your government ID;
0.2 Wait hours/days/weeks for the exchange to "validate" your KYC/AML info and allow you to purchase crypto;
1. Log in to an exchange which is actually allowed to operate in the place where one resides;
2. Purchase Bitcoin or other coin the exchange deems appropriate (leaving aside the hefty fee charged for using fiat currency/traditional credit card);
3. Wait days/weeks until the exchange allows you to transfer the purchased cryptocurrency out of your exchange-hosted wallet;
4. Transfer crypto to a wallet you actually control;
5. Convert the crypto purchased on the exchange to the crypto coin required for whatever your purpose may be;
6. Transmit the crypto to the destination wallet.
Total time (not including setting up the exchange account, which can take anywhere from 1-10 days): 3-10 days.
All the setup is no worse than setting up a bank account
And technically it can be avoided through back channels if you know someone who already has it - can just pay them cash or whatever and they can send crypto to you
Crypto is very easy to transfer once you have a wallet
Its the exchange to/from real world currency where the friction is.
> All the setup is no worse than setting up a bank account
Which is a huge pain in the butt. If someone invented a new lower-spam email ecosystem that required everyone to make a new bank account, very few people would join.
I would say something about a combined account but many countries have already figured out free bank transfers without needing crypto so maybe do that?
If Kargo requires R/W access to GitHub, and auto updates charts/images, isn’t that asking for your production environment to be infected by a change prepared and cultured in your dev environment and then auto updating / hiding itself into prod freight?
We disallow writing back to GitHub to avoid this issue, and manage stages through branches, combined with directories for overlays. Things can get out of sync, but comparing branches is easily automated.
If the image doesn’t leave the device and only the hash does… What is stopping one from uploading existing public images, banning a whole lot of innocent people?
Honestly, this seems like little. We should be wary of the source we try to pull, but given how easy it is to upload something malicious you’d expect thousands of images of this kind. Maybe DockerHub is already detecting and deleting these packages?
Or why aren’t more people interested in this?
Not sure, but maybe injecting into commonly used libraries via subdependencies is seen as a more effective method, getting more focus. Would be interesting to have a broader analysis of malicious artifacts!
I’ve been wondering about this too and always used full sha’s until now. But recently I’ve made an action myself: You actually need to publish the action to the marketplace with each tag manually. It feels like there might be more going on.
Is GitHub storing those published tags and avoiding tampering by only letting you use those tags once? Are they warning or blocking runs if you tamper? …
I’m really curious because it seems like SUCH a giant risk otherwise.
When the threat is an action repo becoming malicious and force-pushing its existing tags to malicious code, the policies of the action repo preventing force-pushes is not a safeguard.
I agree; there should be more protections and I'm pointing out that they could be offered. Github could certainly enforce at the platform level that the only tags allowed for use in Actions must be annotated, maybe even signed, and must never be force-pushed.
The use of tags isn't necessarily the wrong strategy: I'm mostly just pointing out it is treating tags as mutably as branches that is the problem. I don't think you should ever force push a tag, personally, and I always find it problematic when people treat tags like branches and confuse the two.
You can also integrate it in clients by adding payment/reward claim headers.
reply