https://github.com/haplo/pelican-copy-code — A Pelican [1] plugin to add a Copy button to all source code blocks. It happens at build time, so no DOM manipulation at page load time.
I'm currently writing a series of blog posts about these that I call Vibe-coding Escapades [3]. I will also write about bugs and technical problems that AI helps me debug and solve, some are non-trivial and have been pestering me for years.
You are correct, this article is part of my self-hosted Tailscale series using Headscale, which is why I'm receiving the full benefits of moving Syncthing to it. Otherwise Tailscale would keep the same metadata that Syncthing discovery and relay servers were. I talk about that in Part 1 of the series, it's a main motivator for self-hosting Headscale.
Right, that's why the whitepaper is titled "Bitcoin: A Peer-to-Peer Electronic Cash System". The idea is to bring many of cash payments features to the digital world, which are not possible with payment systems with intermediaries: uncensorability (nobody can keep you from transferring cash); non-reversability (no chargebacks, escrow systems are optional); low fees (contentious because BTC decided not to scale on-chain, but that was Satoshi Nakamoto's idea.
That was precisely Bitcoin's goal as stated in its whitepaper [0]
> A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution.
> Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments. While the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model. Completely non-reversible transactions are not really possible, since financial institutions cannot avoid mediating disputes. The cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions, and there is a broader cost in the loss of ability to make non-reversible payments for non-reversible services. With the possibility of reversal, the need for trust spreads. Merchants must be wary of their customers, hassling them for more information than they would otherwise need. A certain percentage of fraud is accepted as unavoidable. These costs and payment uncertainties can be avoided in person by using physical currency, but no mechanism exists to make payments over a communications channel without a trusted party.
> What is needed is an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party. Transactions that are computationally impractical to reverse would protect sellers from fraud, and routine escrow mechanisms could easily be implemented to protect buyers. In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes.
The interesting thing about cryptocurrencies is using them directly, i.e. when users have their own wallets under their full control. Then it's magical when you make a transaction to somebody and think that nobody is censoring, filtering, moderating or rejecting it in any way. Oh and no PII either.
The Digikam DB is SQLite on a fast NVMe drive. The photos are on a 4 TB SSD. I have been using Digikam for maybe a decads, so the collection has been growing with me, but no issues so far.
[1] https://blog.fidelramos.net/software/how-i-sandbox-ai-agents...