I wrote a draft of this article back in 2018, but never published it. Reading back on it now, I'm surprised how much I still agree with the fundamental premise.
For me, it wasn't about tokenization. It was exciting that we could build trustworthy decentralized systems, without entrusting any single centralized party with power.
Now 8 years later, it's interesting to see "blockchains" that aren't really BFT, or semi-centralized.
- For the chains that stuck to their decentralized BFT roots, I'm bullish.
- For the chains that are trying to tokenize on software that is strictly harder to use than straight up web servers. Good luck with that. Banks seem to be pretty good at launching stablecoins without it.
I think it’s time we create a coalition of open source projects that band together and re-license in a way that requires that companies fund their dependencies. In my proposal, I’m trying to maintain as many of the freedoms of free software as possible (to run, study, modify, distribute), while adding simple license terms that force companies that use and make money off of the software to give back.
Let me know if you have any questions or feedback, I’d love to make something work for a wide spectrum of projects!
Congrats on the launch! I’ve been following this project and I’m really excited to see how much it has matured. For projects currently on GitHub, what’s the best way to migrate? Is there a mirror mode as we test it out?
I’ve been using Plasmic for the last 6 months to build rich featured Dapps in the web3 space. It takes some time to import all the React components I need but once you do, it is really incredible how much this speeds up my development. We now have non-developers (like designers and PMs) regularly shipping entire features to production without developer help. Really takes some of the pressure off the engineering team while drastically improving team velocity.
Just for fun during the ETHDenver hackathon, I shipped an LLM-powered NFT generator, with 0 lines of code in 3 hours, and won a cash prize. This tool completely changes the game for me and my team.
Hi there! OP here, very open to feedback and questions. Because there doesn't seem to be a single canonical way to do localization in React, I got stuck down a rabbit hole of exploring all the different options (and there are many!). Here's a write up of my findings, which I hope might be useful to someone else in the planning stages. In other words, you haven't already decided you want to use a particular library, but want to see at a high level the pros and cons of different approaches (e.g. i18n libraries, CMS'es, automated services etc).
On the other side of this, it's fascinating how often people fall susceptible to arguing why something should or shouldn't exist for someone else, rather than just making a limited statement about utility for themselves. Something to stay cognizant of, this article is a good lesson on empathy!
Hi everyone! Author here. Happy to answer any questions or take any feedback.
I was inspired to write this post when exploring all the many different ways to do implement personalization, and realizing just how powerful Next.js middleware is. So I thought I'd share some of those learnings and a step-by-step guide on how to actually implement it. Totally changed the game for me, makes it so easy to make custom content for different segments while maintaining high performance for my site.
If you live in California, I recommend getting involved in your local housing element. This program will have huge implications in how zoning and development occurs in the state for years to come.
https://www.hcd.ca.gov/community-development/housing-element...
Hi all! I just wanted to say thanks for the awesome questions. I can't say I have the answers to these questions, but I can lay out some of my intuition and would love to work together with anyone that also finds these questions interesting!
But it is also read-heavy. Let's say if 10% of the workload includes writes (probably too conservative), we barely squeak by... I'm willing to guess the number is way lower than that. They saw 10M page edits for the entire month of Dec 2018.
https://stats.wikimedia.org/EN/TablesDatabaseEdits.htm
My guess is, this might be doable :-D
2. Who runs this? and who pays?
Great question. The blog completely skips the question about incentives which in my opinion will vary depending on the app. For creating an censorship-resistant Wikipedia, it'll be different than a communications app. Some apps might be better off permissioned (e.g. enterprise settings)
great point! This was about as simple as it got in order to ship something quickly that was minimally intrusive. So the prototype as it is now buys you sequential consistency, but I want to detangle some great points you made.
So there is a ton of space to improve the performance here, I just wanted to build something quickly.
2. Authentication: Definitely an interesting technical challenge here. Most web apps are written assuming they are one-of-many servers accessing the database, but honest and has root authority. So how do we make sure that a validator has the authority to write to a particular table/row? Right now, this is still an open challenge and would love to engage the community on ideas here. There might be some way to tag/sign all tables/rows with creator, and do some write access control based on that? I'm not sure how many web apps would break though.
3. Write-conflicts: Even without good access control as specified above, most web apps are written assuming they are not the only web server to be accessing the database concurrently. So I would anticipate honest servers would have either good failover logic or be wrapping operations in SQL transactions if they really needed them to be atomic. Either way, I don't see any issues being serialized and appended to the log.
That's a great point. And it's definitely a tricky term to navigate because "blockchain" means so many different things to different people. (e.g. tokenization, governance, finance).
I'd say you identified the key aspect though, which I agree is not explicitly answered in this blog. "Who runs this" is a critical question and I think it will vary depending on the end application. I'm going to guess there will be settings where a permissioned deployment may be appropriate (think enterprise settings). There will be settings where a permissionless deployment will make more sense (think globally censorship-resistant Wikipedia). It all boils down to who wants to control it and how to convey trust. And for each of those, you probably have different access control policies too.
That's exactly right! The argument is that if you look at truly reliable cloud services (think Google). They already use consensus protocols to replicate the database globally for fault tolerance purposes. The spanner paper does a decent job explaining their architecture.
https://static.googleusercontent.com/media/research.google.c...
Why not do it for decentralization purposes too?
Blockchains are just a another class of consensus protocols. IMO one of the defining aspects of blockchains is the stronger threat model. Traditional consensus protocols are designed to be crash-fault tolerant, not byzantine-fault tolerant.
I wouldn't get tripped up by the word "validator". In the academic world we probably would have used the term "node" or "replica". It has a special meaning in the blockchain world because it conveys a sense of trust and work-checking.
"Who pays" is a fantastic question. The blog completely elides the question about incentives which in my opinion will vary depending on the app. For creating an censorship-resistant Wikipedia, it'll be different than a communications app. Hoping to write a blog post about that soon after we get more built to show.