abiro

Thanks for the feedback, it should be better now.

For the tmux crowd: please consider sponsoring the author

https://github.com/nicm

https://liberapay.com/tmux

A lot of the apparel being destroyed is unsold inventory of up-market brands to protect their pricing power. If they shipped that to less affluent countries for destruction, it's unlikely that they'd be destroyed, because those items would fetch a good price on the black market.

I thought it weird that the post didn’t mention RustCrypto. It’s legit.

> The second step failed almost immediately, with an error telling me that a replayed log entry was recording data belonging to a machine which didn't exist. This provoked some head-scratching until I realized that this was introduced by some code I wrote in 2014: Occasionally Tarsnap users need to move a machine between accounts, and I handle this storing a new "machine registration" log entry and deleting the previous one

Recommend writing a TLA+ model to catch stuff like this

What to read on the slice universe?

Any details on how passkeys sync using external providers?

Very cool project, congrats to the author!

Baaed on the comments, I feel that people are both under and overestimating this. On the one hand it replaces the manual tasks of searching for a template and then googling errors and this is huge! It completely disrupts search on the internet as we know it. On the other hand it won’t be able to solve problems that you couldn’t just google anyway, since that’s what it basically does under the hood.

Another thing to keep in mind is that if you want the data to be end-to-end encrypted, then you need both devices to be online at the same time to sync with Automerge.

SwiftUI and UIKit compose well in both directions, so if you choose SwiftUI as your framework, but then run into a wall, it's an option to partially rewrite that difficult part with UIKit.

Of course if the problem is with the core of your application like the scrolling example in the article, this is not going to help you much.

This is great. I'd recommend the Learn Rust With Entirely Too Many Linked Lists [0] tutorial as the next step. It really helps you grok the borrow checker.

[0]: https://rust-unofficial.github.io/too-many-lists/index.html

This is pretty cool:

> Before we jump in, I wanted to share some history with you. Back in 2009 when we first built 1PasswordAnywhere, it wasn’t possible to use it with Dropbox. We couldn’t use Dropbox at the time because each file request needed to include a revision number and 1PasswordAnywhere had no way to know which revision numbers to use.

> Roustem and I explained this problem to the Dropbox Founder Arash, and he was kind enough to add a workaround to allow us to load files directly. This was state of the art technology in 2009.

Shopify supporting Passkeys for all merchant sites could be a great driver for adoption.

If you liked this, you'll probably like this interview with Diffie too: https://www.youtube.com/watch?v=DJxOz0I6z5A

Would be curious to see this broken down by fiction vs non-fiction. I read very few non-fiction books cover-to-cover. Most of them could be probably cut by 50% and not lose much.

Web3 refers to the emerging shift in internet value chains from permissioned, centralized databases to permissionless, decentralized databases where users own their data. The driving force behind Web3 is that we can now enforce invariants on state transitions in a permissionless, decentralized manner for a limited set of applications (mostly financial). For an even more limited set of applications, we can also enforce invariants while preserving the confidentiality of transactions.

With hindsight, the two technological breakthroughs that proved decentralized databases possible were Bitcoin and Zerocash. Bitcoin showed that state-machine replication (SMR) is solvable in a distributed, permissionless, partially synchronous setting with Byzantine fault tolerance. Zerocash showed that zero knowledge succinct non-interactive arguments of knowledge can be used to ensure the confidentiality of transactions in this SMR setting.

The tech is improving rapidly and it’s pretty easy to see where things are going from here: soon we’ll have general purpose decentralized databases where data is open as open source code is open. In fact, state-of-the-art blockchains can be viewed as special (financial) purpose decentralized databases.

As to why decentralized databases are desirable: imagine if you could fork databases in a completely permission-less manner like you can fork code. This is how web development would look like:

You, the programmer, take a look at a public data schema (eg. a smart contract that implements the ERC-721 interface) and decide to build on top of it. Then, a user, who has already interacted with what you built on, decides that they like what you built and lets your app use their data. You, the programmer, can be sure that the data you built on remains available, and the user can be sure that they'll be able to port the data produced by your app into new apps.

Re costs: it’s decreasing rapidly. Solana is within 100x of DynamoDB prices so costs are soon becoming negligible. At that point costs can be taken over by the app developer or paid by users on a subscription basis. There are also decentralized consensus mechanisms that don’t rely on paying fees (FBA, delay functions). Idk which will succeed.

Re open standards and “software that lets you export”: we’ve had this for the past 30 years and see how it turned out.

Re lock in: no, in a decentralized database, the data schema is public which means it’s trivial to write an app that works with another app’s data.

The new thing with blockchain tech is that we can now enforce invariants on state transitions in a decentralized manner. Paired with non-interactive zero-knowledge cryptography, we can also enforce those invariants while keeping the confidentiality of transactions.

The tech is rapidly improving and it’s pretty easy to see where things are going from here: soon we’ll have general purpose decentralized databases where data is open as open source code is open. In fact, state-of-the-art smart chains can be viewed as special (financial) purpose decentralized databases.

As to why decentralized databases are desirable: imagine if you could fork databases like you can fork code in a completely permission-less manner. This is how web development would look like:

You, the programmer, take a look at a public data schema (eg. a smart contract that implements the ERC-721 interface) and decide to build on top of it. Then, a user, who has already interacted with what you built on, decides that they like what you built and lets your app use their data. You, the programmer, can be sure that the data you built on remains available, and the user can be sure that they'll be able to port the data produced by your app into new apps.