Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy.
Why? Because:
* It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to prevent secrets from accidentally being sent in the clear.
* Email encryption is never forward-secure. The most popular standard, OpenPGP, involves a long-term key that is the root of secrecy for all messages from a particular person. Lose that key, ever, and not only is every message you send in the future unsafe, but every message you've ever sent in the past is too. That's a terrible property for a secure messaging system.
* Email leaks metadata. In fact, some of what we call email "metadata" isn't even metadata --- stuff like subject lines are simply content. They're sent in plaintext. We would never accept a new secure messaging system that behaved like that.
* Most email users get their email from a website. Unless you make them install something on all their computers --- and at that point, just get them to install Signal, WhatsApp, or Wire --- "encrypting" their email involves schemes in which those websites can get their plaintext mail.
* Most email clients are searchable-archive-by-default. Again, if you're using a secure messaging system to keep secrets from a state-level adversary, that's exactly what you don't want. And again, what matters here is the behavior of the overwhelming majority of clients. If you can stipulate a special mail client that is extra-careful, why not stipulate a forward-secure advanced messaging system and stop bothering with email?
Everything that makes email effective in the real world makes it inhospitable to secure messaging. We should stop trying to push this particular boulder up this particular mountain and instead just get people to adopt serious secure messengers.
The MakerDAO/DAI community fucked up. People have criticized that community's collateral choices for a long time, as the article mentions, it is pejoratively called "wrapped USDC".
Their primary issue was being early and there weren't really collateral choices.
There was no trustless bridge for Bitcoin when they needed it. So they wound up using BitGo's WBTC. People got afraid of the volatility of the assets so started approving stablecoins as collateral, and Tether wasn't an option, other stables didn't exist, so they went with USDC.
For more modern iteration of this concept with different collateral choices and community ethos, look at Magic Internet Money $MIM (yes, naming is intentional re-appropriation). So far all the collateral are yield generating assets, they generate yield from liquidity pools and volume. The automated liquidation functions the same and its worked. It has ancillary issues from its founder's reputation on other projects, so there is still room for yet another stablecoin that inspires more confidence without really needing the baggage of a leader.
> The other alternatives all suck to the extent of my knowledge, they're either prohibitively convoluted, or web3 cryptocurrency micro-transaction nonsense that while sure it would work, also monetizes every single interaction in a way that is more dystopian than the actual skull-crushing robot apocalypse.
In the interest of practicality: There's a way to go the web3 route without being laden with transactions:
- Mint a fixed-cost non-transferrable NFT to an address, with ownership limit of 1 per address.
- Use SIWE (sign-in with Ethereum) to verify ownership of address & therefore NFT.
- If malicious behaviour is detected, mark the NFT as belonging to a malicious actor at the server's end & block the account.
- Require non-malicious-marked NFTs in order to use the site/app.
At most, the user only had to perform 1 transaction (minting the non-transferrable NFT) on any blockchain network where the contract resides, & the costs to do so can be made cheaply with Layer 2 networks. (Polygon PoS, Arbtirum, Optimism, zkSync 2.0, etc)
Can this be done entirely without web3? Yes, but the added friction imposed onto malicious actors to generate new addresses & mint new non-transferrable NFTs increases the costs for them considerably.
> If anyone could go ahead and find a solution to this mess, that would be great, because it's absolutely suffocating the internet, and it's painful to think about all the wonderful little projects that get cancelled or abandoned when faced with the reality of having to deal with such an egregiously hostile digital ecosystem.
In all honesty, there's no perfect solution, just hard-to-make tradeoffs: The prevention of botspam inherently requires tracking in some form to resolve said issue, as there's no immediately-recognizable stateless solution for botspam tracking. Someone has to do the tracking to prevent botspam, which inherently involves in state being changed in order to mark an actor as malicious.
I disagree - declining population is a disaster that only ends in a country becoming poor. As you allude to in your response, sub-replacement-rate fertility is what drives population decline, so declining populations are always ageing populations. The economics of ageing populations don't work for obvious reasons - as people get older they need more care and produce less, and with fewer workers to provide that care, the care becomes more expensive in ways that governments never provisioned for (see Japan and many countries in Western Europe for good examples of this in practice).
In the longer term this depresses GDP per capita as resources have to be diverted from productive industries like high-tech manufacturing into extremely unproductive industries like aged care. Again, Japan and many Western European countries provide good examples of this in practice. Finally, as the reality of the broader economic decline sets in, second order effects start to take hold like brain drain - as young workers see higher wages working in more productive economies, they decide to leave, worsening the population pyramid and depriving the government of precious tax revenue needed to pay for aged care. (Japan and many Western European countries are sadly, again, examples of this phenomenon).
The short term effects you're describing of nominal GDP rising and per capita GDP falling is only true when populations are growing through bad immigration policy, which is what we commonly see in the US for example. Growing population organically and sustainably, or through productive immigration that targets gaps in the country's labor force, should never have that effect as the new member of the population should eventually increase GDP by more than the average existing worker today.
At an individual rather than population level of course, having fewer or no children is easier, which is why people are doing it. But this describes a local optimum only, while the true optimum is population growth.
Markdown is severely limiting for prose and blogging though and leads to unsemantic element abuse or having to do a lot of manual HTML markup (which with no controls over styles means you’re limited further). There aren’t good conventions for a lot of ‘normal’ concepts like admonitions, figures, definition lists, citing blockquotes, footnotes, table of contents, etc.
Another red flag to me is supporting GitHub-flavored Markdown over CommonMark which actually tries to follow good standards practice for everyone. Instead projects like Pandoc have to work hard on alternative parsers because GitHub does whatever it wants with little regard for CommonMark's RFC, and in some cases, even basic semantic HMTL.
"The medium is the message." Twitter-like systems are prone to failure modes: emotionally unpleasant or intellectually barren interactions.
So how do you foster civilized online communication? This is primarily a social problem, not a technical one, although the structure of a system (like the Fediverse) is defined by technology.
The two online forums I know of personally that are pleasant and productive (HN and Permies.com) both have strong and consistent moderation by small, highly-dedicated teams, which then fosters a self-reinforcing culture that values, protects, and promotes norms of civil interaction. Interestingly, both were started by "big men"* (Paul Graham and Paul Wheaton, respectively) who rapidly gathered a critical mass of community. They also both have an entrepreneurial aspect. HN is paired with YC, of course, and Wheaton runs a kind of Permaculture incubator in Montana.
- - - -
*Big man
> A big man is a highly influential individual in a tribe, especially in Melanesia and Polynesia. Such a person may not have formal tribal or other authority (through for instance material possessions, or inheritance of rights), but can maintain recognition through skilled persuasion and wisdom.
I'd argue the only meaningful online social network is git, and maybe soundcloud/bittorrent, the rest is just somebody elses variable source of narcissistic supply.
You could use one of those p2p-blockchain messengers to talk to other people who use p2p-blockchain messengers, but then you are talking to people who use p2p-blockchain messengers.
It's really a question of how much breadth you want/need.
The internet itself reduces to a politically atomized individual sitting alone at a keyboard, struggling to connect, while being neutralized from all sides by random noise to stimulate both outrage and helplessness. It really is the totalitarian dream. You'd have to leave The Internet proper as we know it now, and create the next one, just as AOL/Compuserve were walled gardens that the internet grew outside of, a new network that resembled the 90's era internet could emerge in as little as a few years.
Think about what Linux was: a new kernel for bare metal that broke out of the constraints of an OS landscape that looked a lot like today's internet giants. At the time, global communication was novel, today, privacy and regional networks are novel. Most linux users had a bsd/solaris/windows machine to connect to the legacy world, so you don't have to design the whole thing at once.
A p2p-reddit that used a blockchain that operated with a kind of old fidonet/UUCP/nntp over bittorrent as transport could be a source of new community. A bare metal blockchain client kernel for open RISC and ARM processors that uses a wireless mesh, and includes a kind of regional pub/sub pattern would do it.
Gatekeeping is the only way communities can keep themselves healthy. There is no such thing as a universal 'community'.
From day one, life has been about letting in certain elements, and keeping out others. Without this selection, development and differentiation are impossible. Similarly we don't (and shouldn't) let every person into our homes, or our countries, or our servers. Why is it seen as an obvious truth that we should allow every single person onto the Internet, without ever being able to remove them?
Solidity has far worse problems than not being an advanced research language. Just being a sanely designed normal language would be a big step up. Solidity is so riddled with bizarre design errors it makes PHP 4 look like a work of genius.
A small sampling of the issues:
Everything is 256 bits wide, including the "byte" type. This means that whilst byte[] is valid syntax, it will take up 32x more space than you expect. Storage space is extremely limited in Solidity programs. You should use "bytes" instead which is an actual byte array. The native 256-bit wide primitive type is called "bytes32" but the actual 8-bit wide byte type is called "int8".
Strings. What can we say about this. There is a string type. It is useless. There is no support for string manipulation at all. String concatenation must be done by hand after casting to a byte array. Basics like indexOf() must also be written by hand or implementations copied into your program. To even learn the length of a string you must cast it to a byte array, but see above. In some versions of the Solidity compiler passing an empty string to a function would cause all arguments after that string to be silently corrupted.
There is no garbage collector. Dead allocations are never reclaimed, despite the scarcity of available memory space. There is also no manual memory management.
Solidity looks superficially like an object oriented language. There is a "this" keyword. However there are actually security-critical differences between "this.setX()" and "setX()" that can cause wrong results: https://github.com/ethereum/solidity/issues/583
Numbers. Despite being intended for financial applications like insurance, floating point is not supported. Integer operations can overflow, despite the underlying operation being interpreted and not implemented in hardware. There is no way to do overflow-checked operations: you need constructs like "require((balanceOf[_to] + _value) >= balanceOf[_to]);"
You can return statically sized arrays from functions, but not variably sized arrays.
For loops are completely broken. Solidity is meant to look like JavaScript but the literal 0 type-infers to byte, not int. Therefore "for (var i = 0; i < a.length; i ++) { a[i] = i; }" will enter an infinite loop if a[] is longer than 255 elements, because it will wrap around back to zero. This is despite the underlying VM using 256 bits to store this byte. You are just supposed to know this and write "uint" instead of "var".
Arrays. Array access syntax looks like C or Java, but array declaration syntax is written backwards: int8[][5] creates 5 dynamic arrays of bytes. Dynamically sized arrays work, in theory, but you cannot create multi-dimensional dynamic arrays. Because "string" is a byte array, that means "string[]" does not work.
The compiler is riddled with mis-compilation bugs, many of them security critical. The documentation helpfully includes a list of these bugs .... in JSON. The actual contents of the JSON is of course just strings meant to be read by humans. Here are some summaries of miscompile bugs:
In some situations, the optimizer replaces certain numbers in the code with routines that compute different numbers
Types shorter than 32 bytes are packed together into the same 32 byte storage slot, but storage writes always write 32 bytes. For some types, the higher order bytes were not cleaned properly, which made it sometimes possible to overwrite a variable in storage when writing to another one.
Dynamic allocation of an empty memory array caused an infinite loop and thus an exception
Access to array elements for arrays of types with less than 32 bytes did not correctly clean the higher order bits, causing corruption in other array elements.
As you can see the decision to build a virtual machine with that is natively 256-bit wide led to a huge number of bugs whereby reads or writes randomly corrupt memory.
Solidity/EVM is by far the worst programming environment I have ever encountered. It would be impossible to write even toy programs correctly in this language, yet it is literally called "Solidity" and used to program a financial system that manages hundreds of millions of dollars.
Why? Because:
* It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to prevent secrets from accidentally being sent in the clear.
* Email encryption is never forward-secure. The most popular standard, OpenPGP, involves a long-term key that is the root of secrecy for all messages from a particular person. Lose that key, ever, and not only is every message you send in the future unsafe, but every message you've ever sent in the past is too. That's a terrible property for a secure messaging system.
* Email leaks metadata. In fact, some of what we call email "metadata" isn't even metadata --- stuff like subject lines are simply content. They're sent in plaintext. We would never accept a new secure messaging system that behaved like that.
* Most email users get their email from a website. Unless you make them install something on all their computers --- and at that point, just get them to install Signal, WhatsApp, or Wire --- "encrypting" their email involves schemes in which those websites can get their plaintext mail.
* Most email clients are searchable-archive-by-default. Again, if you're using a secure messaging system to keep secrets from a state-level adversary, that's exactly what you don't want. And again, what matters here is the behavior of the overwhelming majority of clients. If you can stipulate a special mail client that is extra-careful, why not stipulate a forward-secure advanced messaging system and stop bothering with email?
Everything that makes email effective in the real world makes it inhospitable to secure messaging. We should stop trying to push this particular boulder up this particular mountain and instead just get people to adopt serious secure messengers.