Me: Write a blog post comparing chatGPT to ETFs
ChatGPT and ETFs are two very different things, so it's difficult to compare them directly. However, both are interesting in their own ways, and understanding the differences between them can be helpful in understanding how each can be used.
[.. the rest of ChatGPT's answer read like an 7th grader's essay... so I thought to explain further... ]
Yes, that makes sense. ChatGPT is a large language model trained by OpenAI, which means that it has been trained on a huge amount of data and can generate text that sounds like it was written by a human. However, it is not capable of creating new knowledge or making unique insights. It can only generate text based on the knowledge it has been trained on.
Similarly, ETFs are based on the systemic knowledge of the market as a whole. Buying a market ETF will give you exposure to the overall market, but it won't allow you to make unique bets or take advantage of mispriced securities. It will simply track the performance of the market index or basket of assets that the ETF is based on.
However, both ChatGPT and ETFs can be used as a starting point for human ingenuity and talent. In the case of ChatGPT, a person can use the generated text as a starting point and then focus on improving it and adding their own unique insights. With ETFs, a person can use the market knowledge provided by the ETF as a starting point and then focus on identifying mispriced securities and making bets on them in order to potentially outperform the market. In both cases, human ingenuity and talent can be used to build on the systemic knowledge provided by ChatGPT or ETFs in order to create something new and unique.
In his widely-read post on web3 , Moxie Marlinspike re-iterates over and over again that “If there’s one thing I hope we’ve learned about the world, it’s that people do not want to run their own servers.” The image he seems to have in mind is of a big old-style PC with a cd-drive sitting under the messy desk of a nerd, who spends his(!) time making sure it is running smoothly. So of course, seen in that way, as Moxie notes, “Even nerds do not want to run their own servers at this point.” But then he goes on to say that “Even organizations building software full time do not want to run their own servers at this point.” And therein lies his logical flaw. All these “organizations building software” do have their own servers – except that the servers are running in the cloud – some are even called ‘serverless’. Of course individuals don’t want to maintain physical personal servers sitting under their desks, but, much like those software organizations, we may all very well want to have our own personal servers in the cloud, if these were easy enough to install and maintain, and if we had a rich eco-system of apps running on them.
This has been an ideal since the beginnings of web1, when, as Moxie himself says, we believed “that everyone on the internet would be both a publisher and consumer of content as well as a publisher and consumer of infrastructure” – effectively implying that we each have our own personal servers and control our data environment. Moxie says it is too “simplistic” to think that such an ideal is still attainable. Many web3 enthusiasts believe web3 can provide the answer. My view is that (regardless of the number we put in front of it), at some point, technology and technology mores will have advanced far enough to make such a personal server ecosystem feasible. We may be close to that point today.
But before laying out my reasoning, let me present two other minor critiques of Moxie’s excellent article.
First is the way in which Moxie criticizes what he calls “protocols”, as being too slow compared to “platforms”. Although he may be right in the specific examples he notes – i.e. that private-company-led initiatives from the likes of Slack and WhatsApp have been able to move so much faster than standard open ‘protocols’ such as IRC – he makes this argument in a general context of web2 vs web3, and thus seems to imply that ALL open community-led projects will fail because private-led initiatives will inevitably innovate faster. But how could such a statement be reconciled with something like Linux, the quintessential open source project which is the most used operating system to access the web and to run web servers? How can one not think of html and the web itself, and javascript, each of which are open platforms, or simple agreed-upon conventions – upon which so much innovation has been created over the past decades? In defense of Moxie’s point, if you talk to anyone involved in the development of these over the years, chances are that they will complain about how slow moving their respective technical committees can be. But perhaps that is how fundamental tech building blocks should be – it is precisely the slow-moving (and arguably even technologically under-innovative) nature of platforms and protocols that provides the stability needed for fast-moving innovators to build on them. The critical societal question isn’t whether a particular protocol or web3 initiative will be innovative in and of itself, but whether any one or multiple such initiatives will serve as a foundation upon which multiple fast-moving innovations can be built, preferably using an architecture which supports a healthy ecosystem. The base elements (or ‘protocols’) don’t necessarily need to be fast moving themselves – they just need to have the right architecture to induce innovations on top of them.
In this light, as Azeem Azhar has noted, a couple of the more interesting web3 initiatives are those that are trying to use crypto-currency-based compensation schemes to create a market mechanism for services, thus tackling problems that web2 companies had previously failed to solve. One example is Helium, which is a network of wifi hotspots, and another is Ethereum Swarm, which is creating a distributed personal storage system. Both of these ideas had been tried a decade or two ago but never gained the expected popularity, and they are now being reborn with a web3 foundation and incentive system. Indeed, as it tends to, technology may have advanced far enough today to make them successful.
My last critique of Moxie’s article is that he contends that any web2 interface to web3 infrastructure will inevitably lead to immense power concentration for the web2 service provider, due to the winner-takes-all nature of web2. I would contend that it does not need to be that way, and we can point to the cloud infrastructure services market as evidence. This may be seem like a counter-intuitive example, given the dominance of big-tech and especially Amazon’s AWS of the cloud infrastructure market, but the dynamics of this market are vastly different from the b2c markets that are dominated by the same big-tech companies (Google, Amazon, and Microsoft). Despite every effort by these big-tech usual suspects to try and provide proprietary add-ons to their cloud services so as to lock in their customers, they are ultimately offering services on a core open-source tech stack. This means that they are competing on a relatively level playing field to offer their services, knowing that each of the thousands of businesses that have thrived on their infrastructure can get up and leave to a competing cloud provider. The customers are not locked in by the network effects that are typically seen in b2c offerings. That is clear from the rich ecosystem of companies that have thrived on these platforms. Furthermore, not only can competitors in the cloud infrastructure market take on various niche portions of this giant market, but new entrants like Cloudflare and Scaleway can also contemplate competing head-on.. This competition, which is enabled by the existence of a core open-source tech stack, keeps even the most dominant service providers honest(!) as their customers continue to be king. There is no better evidence for that than the vibrancy of the ecosystems built on top of these services, and in stark contrast to the consumer world where the lack of interoperability and the strength of the lock-ins provide immense barriers to entry. Given a similar architecture, there is no reason these same dynamics can’t be transposed to the personal server space and the b2c market.
Yet, by going in with the assumption that such a thing is impossible, Moxie misses the opportunity to think through what new architectural solutions are possible by combining web3 elements with our existing technological interactions, and whether such new architectures could enable strong enough competition and portability, to curb the winner takes-all dynamics of the current b2c consumer web services market.
This brings us back to my pet peeve of personal servers – a concept that has been around for more than a decade, and that the tech world has come to believe will never work. The question is: have recent developments in tech fundamentally shifted the landscape to make the original ideal of web1 viable again. My view is that the stars may be finally lining up, and that such an architecture is indeed possible.
✨ Web 3
A first star may be the launch of Ethereum Swarm, “a system of peer-to-peer networked nodes that create a decentralised storage”. As mentioned, Swarm uses Ethereum smart contracts as a basis of an incentive system for node participants to store data. It is quintessentially web3. Yet, it acts as a core infrastructure layer, on which anything can be built. So, the Fair Data Society, a related organization, built fairdrive, a web2 based gateway to access this storage infrastructure – a key building block for allowing other web2 based applications on top of it. Moxie’s blog post would argue that any such web2 interface would reconcentrate power in the hands of the same web2 service provider. But that really depends on what is built within and on top of that gateway – the architecture that lays on top of the foundational storage. If the data stored is in an easily readable format, based on non-proprietary and commonly used standards; and if there are multiple competing gateways to access this data, allowing anyone to switch providers within a minute or two, then there is no reason for those web2 interface service providers to be able to concentrate undue power.
So how could these two elements come together – the data format and the portability / switch-ability?
🤩 Web 2 Switch-ability
As mentioned above, the competition among b2b cloud infrastructure providers has continued to allow for immense value to accrue to their customers. Until now, these customers have been other businesses that use the cloud. Even so, the cloud providers have done such a good job providing better and better solutions for these customers, which are ever easier to deploy, that such solutions have become almost easy enough to be also deployed for consumers. So not only can one easily envisage a world where multiple service providers compete by providing the best possible personal cloud services to consumers, one does not even need to wait for that. Today, it takes just a few clicks to create a new server on Heroku or on glitch.com or a myriad of other services. Anyone can easily set up their own server within a few minutes. This bodes well for a leading edge of tech-savvy consumers to do exactly that!
But then what? What would you put on those servers? What data, and in what format? How can you make sure that such data is compatible across server types, and that such servers are interoperable (and switch-able), wherever they may sit?
💫 Web1 and the Personal Server Stack
A first step towards such interoperability is the CEPS initiative, which came out of the 2019 mydata.org conference and aimed to define a set of Common Endpoints for Personal Servers and datastores so that the same app can communicate to different types of personal servers using the same url endpoints. (ie the app only needs to know the base url of each user’s server to communicate with it, rather than create a new API for every server type.) With CEPS, any app developer can store a person’s app data on that person’s personal storage space, as long as the storage space has a CEPS compatible interface. CEPS also starts to define how different CEPS-compatible servers can share data with each other, for example to send a message, or to give access to a piece of data, or to publish something and make it publicly accessible. This data, “users’ data” – sitting on their personal servers is assumed to be stored in nosql data tables associated with each app. And whether the data is sitting in flat files or a cloud-based data base, it can easily be downloaded by its owner and moved somewhere else without losing its cohesiveness. This ensures that ‘user-data’ is indeed easily portable and so the ‘user’ or ‘data-owner’ can easily switch services – ie that the service provider doesn’t have a lock-in on the data-owner.
A second step would be to also store the apps themselves on the personal data space. Code is data after all, and so, having our apps be served from other persons’ servers seems incompatible with the aim of controlling our own data environments. It would leave too much room for app providers to gain the kind of power Moxie has warned us against. These apps, like one’s data, also need to be in a readable format and transportable across servers and mediums. Luckily, since the advent of web1, we have all been using such apps on a daily basis – these are the html, css and javascript text files that together make up each and every web page. Instead of having the app-providers host these files, these files can also be stored on each person’s personal storage space and served from there. Then each data-owner would have control over their data, as well as the app itself. The use of such an old standard not only ensures easy portability of the apps, but it also means that thousands of developers, even novices, would be able to build apps for this environment, or to convert their existing web-apps to work in that environment. It also implies that the server-layer itself plays a very small role, and has less of an opportunity to exert its dominance.
I started this essay by claiming that people “may very well want to have their own personal servers in the cloud, if these were easy enough to install and maintain, and if they had a rich eco-system of apps running on them.” I have tried to depict an environment which may have a chance of meeting this criteria. If we start by converting our existing web-apps to this architecture, we may be able to use the web3 foundation of Swarm to forge a path towards the web1 ideals of controlling our web environment and data, all with the ease-of-use and the ease-of-development which we have gotten used to from web2.
🌹 Any Other Name
So then, the only problem remaining would be the name ‘Personal Server’… because Moxie may be right on that too: after all these years of false starts, it has become such a truism that no one would ever want a ‘personal server’, that the term itself may be too tainted now for anyone to want to run one.. so perhaps we should just rename ‘personal servers’ to “Serverless Application Platforms”.
____________________
Note: freezr is my own implementation of a personal server (ahem.. Serverless Application Platform), consistent with the architecture laid out above.
I will giving a demo of freezr at the We are Millions hackathon on March 10th.
I modified NeDB for freezr so it can use async storage mediums, like AWS S3 and or personal storage spaces like dropbox. The code is on github, and npmjs.
Each new storage system can have a js file that emulates the 16 or so functions required to integrate that storage system into nedb-asyncfs. A number of examples (like dbfs_aws.js) are provided under the env folder on github. Then, to initiate the db, you call the file as such:
const CustomFS = require('../path/to/dbfs_EXAMPLE.js')
const db = new Datastore({ dbFileName, customFS: new CustomFS(fsParams)})
where dbFileName is the name of the db, and fsParams are the specific credentials that the storage system requires. For example, for aws, fsParams could equal:
To make this work, I moved all the file system operations out of storage.js and persistence.js to dbfs_EXAMPLE.js (defaulting to dbfs_local.js which replicates the original nedb functionality), and made two main (interrelated) conceptual changes to the NeDB code:
1. appendfile - This is a critical part of NeDB but the function doesn't exist on cloud storage APIs, so the only way to 'append' a new record would be to download the whole db file and then add the new record to the file and then re-write the whole thing to storage. Doing that on every db update is obviously hugely inefficient. So instead, I did something a little different: Instead of appending a new record to the end of the db file (eg 'testdb.db'), for every new record, I create a small file with that one record and write it to a folder (called '~testdb.db', following the NeDB naming convention of using ~). This makes the write operation acceptably fast, and I think it provides good redundancy. Afterwards, when a db file is crashsafe-written, all the small record-files in the folder are removed. Similarly, loading a database entails reading the main dbname file plus all the little files in the ~testdb.db folder, and then appending all the records to the main file in the order of the time they were written.
2. doNotPersistOnLoad - it also turns out that persisting a database takes a long time, so it is quite annoying to persist every time you load the db, since it slows down the loading process considerably... So I added a donotperistOnLoad option. By default the behaviour is like NeDB now, but in practice you would only want to manage persisting the db at the application level... eg it makes more sense to have the application call 'persistence.compactDatafile()' when the server is less busy.
Of course, latency is an issue in general, and for example, I had to add a bunch of setTimeOuts to the tests for them to work... mostly because deleting files (specially multiple files, can take a bit of time, so reading the db right after deleting the 'record files' doesnt work. and I also increased the timeout on the tests. Still, with a few exceptions below, all the tests passed for s3, google Drive and dropbox. Some notes on the testing:
I made one other general change to the functionality: I don't think empty lines should be viewed as errors. In the regular NeDB, empty lines are considered errors but the corruptItems count starts at -1. I thought it was better to not count empty lines as errors, but start the corruptItems count at 0. (See persistence.js) So I added a line to persisence to ignore lines that are just '/n'
Finally, nedb-asyncfs also updates the dependencies. underscore is updated to the latest version, as the latest under nedb had some vulnerabilities. I also moved binary-search-tree inside the nedb code base, which is admittedly ugly but works. (binary-search-tree was created by Louis Chariot for nedb, and the alternative would have been to also fork and publish that as well.)
vulog is a chrome extension that allows you to (1) bookmark web pages, highlight text on those pages, and take notes, (2) save your browsing history, and (3) see the cookies tracking you on various web sites (and delete them).
I wrote the first version of vulog 3 years ago to keep a log of all my web pages. It seemed to me that all the large tech companies were keeping track of my browsing history, and the only person who didn't have a full log was me! I wanted my browsing history sitting on my own personal server so that I can retain it for myself and do what I want with it.
At the time, I had also added some basic bookmarking functions on vulog, but I have been wanting to extend those features and make them much more useful:
So these are all now implemented in the new vulog here:
https://chrome.google.com/webstore/detail/vulog-logger-bookmarker-h/peoooghegmfpgpafglhhibeeeeggmfhb
The code is all on github.
This post is supposed to be a live document with the following sections:
Here are some known problems and deficiencies with vulog :
Current tab
Click on the vulog button to see the main "Current" tab, and tag a page or bookmark it using these buttons:
- The 'bookmark' and 'star are buttons for regular bookmarking.
- The 'Inbox' button is for items you want to read later. You can also right click on any web link on web pages you visit and add it to your vulog inbox right from the web page.
- Links marked with 'archive' do not show in default search results when you do a search from the Marks tab. For example, once you have read a page from your inbox, you might want to remove the 'inbox' mark, and add it to your 'archive'.
- The 'bullfrog' button makes the link public. Note that you need a CEPS compatible server to store your data and to publish it, if you want to use this feature. (See Below)
Marks tab
In the Marks tab, you can search for items you have bookmarked.
Click on the bookmark icons to filter your results. (eg clicking on inbox turns the icon green and only shows items that have been marked 'inbox'. Clicking it again will turn the button red, and you will only see items that have NOT been marked 'inbox'. You will notice that the 'archive' mark is red by default, so that archived items do not appear in the default search results.
In the marks tab, you can search for the items you have bookmarked.
When clicking on bookmark buttons, you will filter your results. (eg clicking on inbox turns the icon green and only shows items that have been marked 'inbox'. Clicking it again will turn the button red, and you will only see items that have NOT been marked as inbox. You will notice that the 'archive' mark is red by default, so that archived items do not appear in the default search results.
History tab
Search your history. The general search box searches for words used in your tags and notes and highlights, as well as meta data associated with the page.
Right Clicking on web pages
On any web page, you can right click on text you have selected to highlight it, and you can right click on a any link to add it to your inbox
Cntrl/Cmd S on web pages
When you are on any web page, you can press cntrl-S (or cmd-S for mac) and a small menu appears on the top right corner of the web page, to allow you to bookmark it. While the menu is open, pressing cntrl/cmd-I adds to inbox, cntrl/cmd-A archives, cntrl/cmd-B adds a bookmark, and pressing cntrl/cmd-S again adds a star. You can remove marks by clicking on them with your mouse. The Escape key gets rid of the menu, which disappears automatically after a few seconds in any case.
Data storage
Your bookmarks and browser history is kept in the chrome's local storage, which has limited space. After some weeks (or months depending on usage), vulog automatically deletes older items.
vulog doesn't send any of your data to any outside servers, and you can always delete your data from the 'More' tab. If you want to store your data on your own server, you will need to set up a Personal Data Store. vulog was built to be able to accept CEPS-compatible data stores. (See here for more details on CEPS - Common End Points for Personal Servers and data stores. )
Having your data sit on your personal data store also means that you can publish your bookmarks and highlights and notes. Press the bullhorn button to publish the link from your server.
I expect to use vulog as an example app for the development of the CEPS sharing protocol.
Highlighting functionality was largely copied from Jérôme Parent-Lévesque. (See here.)
Rendering function (dgelements.js) was inspired by David Gilbertson (who never expected someone would be crazy enough to actually implement his idea I think.)