Mitar's Point

Source code and results are available, for JS driver and for native driver. First I populated the database with two tables, posts and comments, where each comment has a related post. I generated 10000 posts, each with 100 comments. I tested these queries.

Green color marks combinations I would recommend. Red color shows JSONB should be avoided.

My insights from the benchmark are:

JavaScript driver is surprisingly faster than a native driver. Even just for a simple SELECT * FROM comments. So I will focus just on JavaScript driver and would not recommend using native driver at all.

We can immediately see that converting query results to JSON in the database and then sending them over is generally much faster then sending over raw PostgreSQL fields. I believe this is because JSON parsing is so much faster in JavaScript than parsing of PostgreSQL field types. We can see that using native driver there is no such boost.

Doing a traditional JOIN without aggregation is really slow. I attribute this to the fact that traditional join repeats all column values in the main table. So for 100 comments, related post’s row is repeated 100 times. Doing aggregation of comments into an array seems to really improve things. MongoDB’s idea of embedding is really powerful and you can see benefits even here.

While using JSONB for storing JSON in PostgreSQL and even having indices on JSON fields is very cool, but using it to transport results to the client is not a good idea. Again, probably because JavaScript’s JSON parsing cannot be used.

Subquery is faster than JOIN. A surprise because the word is that subqueries can be at best as fast as joins, but sometimes they will be worse. Here, there are better.

It seems that the best approach is to use subqueries to get related documents, aggregate them into an array, and convert the array to JSON. Or, you can be lazy and just simply always convert the whole result (with aggregated arrays) to JSON.

Important to note is that while it looks that using a subquery and just aggregation is the fastest, the results you get on the client are not really parsed into a JavaScript object, because the driver does not parse embedded records. Probably parsing them properly would add quite a bit.

Proof of luck is an example of such a Intel SGX based consensus protocol where all participants select a random number (luck) and one with the highest number wins (luckiest). The luckiest block is then used as the next block in the blockchain. Because random number selection happens inside an SGX environment one cannot fake it. Each CPU can choose only one random number per block.

We made a blockchain implementation based on the proof of luck. Check out its demo. Instead of reimplementing lower layers needed for a blockchain we built it on top of IPFS. It is written in JavaScript and uses a NPM module to run JavaScript inside SGX environment. Because it is build on top of IPFS, its transactions can reference any other object stored in IPFS, whole files, large or small, and other linked data structures.

Two main properties we want from a blockchain is liveness and persistence. Liveness means that transactions submitted into a blockchain cannot be prevented from being added to a blockchain. One could ignore a particular transaction in their block, but because somebody else's block might win instead, they cannot really prevent that winning block to include the transaction. And even if their block wins this time, the next winning block might include the transaction instead.

Persistence is the one we commonly associate with a blockchain. Once a transaction is committed into a blockchain block, an attacker should not be able make the transaction or the block be removed later on from the blockchain. Effectively this means that the attacker should not be able to convince all other participants to switch to a blockchain version with that block removed (or changed to not include the transaction). In our blockchain participants switch to a new blockchain when the new blockchain is luckier as a whole (sum of all blocks' numbers) than the old blockchain. But an attacker would have to create an alternative chain with many blocks luckier than those in the original chain, and this is harder and harder as the chain is getting longer, because all other participants are choosing the luckiest block among all of their block candidates, and the attacker would have to surpass them all.

As a consequence, developers did not try at all to imagine how to address the spirit of the law and allow users to minimize their tracking around the web, but searched for a way to satisfy the letter of the law with the least amount of effort. Plugins have been developed which made it easy to turn site into a “compliant” site by showing users a banner where they were informed about cookies. Developers used them and move on.

Looking now back we can observe multiple issues with the whole process. First, different EU countries adopted the directive differently, but that was not really part of the public discourse, nor big international websites really payed much attention to it. This meant that if you read international information about the cookie requirements you got different information than if you would really read a local law itself. Even local news organizations got confused about it, sourcing information from their international partners. If you used a plugin developed by someone in a different country you might got a plugin which did not really made your site compliant. But because everyone wanted to do the least effort and least amount of work required by users, soon everyone converged to use the least demanding solutions.

For example, in Slovenia we required that users have to opt-in. It is not enough to just display a banner saying that by continuing using the website you agree with cookies. User had to click on a button to confirm. Some other countries focused more only on educating users about cookies and informing them that the website is using them, but not requiring them to do any action about it.

If you do provide a banner requesting from user to confirm, the question is what happens if they do not. Most developers I have seen decided to simply prevent user from using the website by redirecting them away. Or sometimes they redirected you back to the same website, displaying a banner again, forcing you to stay in this loop.

This made users learn that they should not really care what cookies are or whether they like them or not, but that they simply have to confirm the banner to be able to use the website at all. Developers managed to get users to confirm, but of course users were not really empowered in any way. Developers themselves understood that such banners do not really do anything meaningful. And this made part of a negative cycle which further diminished the perception of the law, and why would anyone spend time working on a good solution for a bad law?

Moreover, users became habituated to this banner and that they just have to confirm it and this is it. Even if a website would allow operation without cookies, users learned from other websites that this is not really an option to even try.

Furthermore, most banners are simply claiming that those cookies are required for site operation. But this is simply not true. Most 3rd party cookies are not. When using web with disabled 3rd party cookies as an experiment I noticed an issue only with commenting platform Disqus: I had to make an exception to be able to login to comment. But cookies for website analytics is definitely not needed from the perspective of the user.

It is interesting to note that in this case developers’ perception of the law guided their response which was then coded into the code and became interpretation of that same law, effectively became the law. The normative technology became the law. While original intent of the law was slightly different, at least how it was discussed during the process of adopting the EU directive, the code implementing it became the real law. Became what users see what the law is, and what other public see how reasonable and useful the law is. And because it is clear that banners are not really useful, the law itself is perceived as such as well.

In big international companies it seems that dealing with this regulatory change was done mostly by lawyers who are not really in a position to imagine technically changes needed to their website stack to innovate in a way which empower users and at the same time satisfy regulatory requirements. The easiest thing is to come up with a text to put on a banner and request from developers to display this banner to users.

The issue underlying this law is of course also the issue of enforcement. How to really enforce such requirements when web is global? If different EU countries have different requirements, how can a website know what to do for a particular user? Even before user really interacted in any meaningful way with the website. The website can use their IP to try to guess users’ geographical location, but this is not always precise. Who is liable when they make a mistake?

Moreover, having multiple versions for multiple countries is hard to develop and maintain. So the question posses itself: should websites implement the strictest requirements and thus satisfy everyone? But what if authors of a website believe that this degrades users’ experience of the website. Then we want to minimize the number of users who have to experience this degraded version of the website.

But it is really so hard to address legal requirements in a way which empowers users? When we were debating the law before it passed it was straightforward to us how it should work. Users should not get any 3rd party cookies by default and then only when they would request some feature of a website which requires them, they would be informed that cookies are needed for this particular feature and to proceed with loading/enabling it. This can work great for Facebook like and share buttons, YouTube and Google Maps embeds and many others. But it cannot work well for ads and analytics. Which is probably exactly those which the law wanted to protect against.

Social Share Privacy is an example of a plugin which behaves in this way. It uses a two-click approach, where the first click loads the 3rd party content and the second click then interacts with that content. It is a great and simple idea, which does not drastically worsens user experience, while at the same time empowers users.

Sadly, I have not seen other web frameworks or plugins providing such feature out of the box. If this would be something which would just work it would be much easier to get adoption. Similarly to how Cross-Site Request Forgery (CSRF) protection became widely used once web frameworks provided it automatically. Then even developers would not see legal requirements as unreasonable. But privacy is not yet seen as important as security itself.

Existing web frameworks even use cookies in an anti-pattern in the respect to cookie laws, setting them immediately when user visits a website, and not when user requests a feature. For example, session cookie is automatically set, even if a website does not even use sessions or even if user has not yet logged in.

In some way it is thus understandable that developers have chosen an easier path. Law tried to force this change in an architecture of web applications but it did not happen. Maybe this effort was not coordinated enough and core developers of web applications did not feel enough personal motivation to coordinate better. So what could be a better way?

Maybe instead of requiring websites to provide such protection for users, law could first require it from web frameworks and service providers. Similar to how YouTube provides a nocookie version of its service. Maybe government could simply develop plugins for popular web frameworks. All that so that when later on developers are required to change websites, tools and services are ready.

Take Bitcoin for example. Its technical innovations are undeniable, but as a currency itself, it lacks innovation. It is still a one-dimensional numeric-like value assigned to each transaction. If we are comparing it with the Internet, then it is the Internet in the form where people would take physical books, scan them as images, and make them available online. No interactivity, no multimedia, no searching or social capabilities, no additional value besides digitizing the content in the most simple way. Bitcoin does the same. It just digitizes existing concept of money. It does this in an interesting and innovative way, but it is still just a digital image of money.

How much can then Bitcoin as a technology really influence the society, if it just copying and digitizing existing practices?

To answer this question I asked myself another question: how would a cryptocurrency which would not be just digitizing existing practices look like? How would we design a new cryptocurrency which would by its design influence and change the behavior of its users?

To be able to answer these questions I needed an additional insight about current cryptocurrencies: it is not true that they provide just a one-dimensional numeric-like value. As a side-effect of their public nature they in fact provide a vector for each transaction, direction and a magnitude of the value transfer.

Using this idea we can design an anti-cryptocurrency. If our current economy operates on debt, we can design a cryptocurrency for an economy which operates on giving. If currently you lend money to somebody, you want to record this fact to assure that they return the money to you eventually. In our cryptocurrency, you would record this fact to assure that they give the money further and do not keep it for themselves. We know the direction of money, so we can make sure that it never flows back. That one cannot return the money it received. If currently money transfer is instantaneous, independent from your behavior and existing wealth, in our cryptocurrency it would be a process depending on your behavior and existing wealth.

In short, our cryptocurrency would be a pay-it-forward cryptocurrency.

Its properties would be:

Everyone can have only a non-negative amount of money.

When somebody wants to send you money, they direct a flow of that amount of money towards you. Less money you have, quicker can that money flow towards you.

Moreover, looking at the network of your past transactions, less money you sent in the general direction of the sender, quicker can that sender send you money.

Once the sender directs a flow, they cannot cancel it anymore.

The money once directed (even if not yet transferred completely) is reserved for that flow.

The less money you have, quicker and more money others can send you. You have incentive to send the money forward as soon as possible, because only this is how you can get even more money. If you do not have any concrete reason to send money, you can always donate it. If you do not know of anyone to donate to, you can always send it to a special address for universal basic income. In this way you get rid of your money, and at regular intervals then all money from that address is redistributed back to all users of the cryptocurrency. (How one would assure unique users is another problem.)

One would still be able to pay in a store with this cryptocurrency. Only that store would have to have by itself little money in its account to quickly receive your payment. A store can donate as well if needed.

There are some interesting details. Like if I direct a flow towards somebody with a lot of money, they are receiving my money slowly, but then also I cannot receive money from others, because I still have money. So I should be selecting recipients who do not have much money.

There are also some issues to be ironed out. Such cryptocurrency might incentivize wealthy people to hire other people to be their wallets. They could distribute their wealth among those people-wallets. So some form of regulation might be needed to forbid this. Or laws which would allow people-wallets to claim the money as theirs, if wanted.

Jo Freeman in her essay The Tyranny of Structurelessness reminds us that humans tried to remove centers of power and organize themselves in a horizontal way in the past as well, and presents to us issues with power relations she observed in a 1960s women's liberation group.

What she observed was that once you removed explicit centers of power, implicit and hidden centers of power emerge. I see this is as a normal social phenomenon. More people we have to coordinate with, more effort and time coordination requires from us. Especially as the community scales up and more people join. We start interacting more with those we interact easily, and cliques emerge. Through time some of those gain more power than others because they do not distribute their power outside the clique in the same way as inside. So power concentrates.

The difference is that this power is implicit, hidden. While in traditional communities with centralized structures we established institutions for checks and balances, like transparency and accountability, those do not exist for implicit centers of powers. The whole concept of a "public service" is based around public being able to oversee the service. But once we remove those public services and replace them with private services we loose mechanisms to oversee their behavior. We are lucky if we can even detect that such concentrations of power exist at all.

Thus, I would name the first fallacy of decentralization: a fallacy of structurelessness. It is better to have clear and explicit centers of powers with transparency and accountability than pretend that we have decentralization, just for those centers of power to emerge hidden and unchecked.

Moreover, just having a decentralized underlying technology like blockchain does not mean that the community using it is decentralized. Or that using a centralized technology means that the community is centralized. Wikipedia and many open source projects can be seen as communities with centralized technologies which help the community operate together, but the community itself is decentralized and global. On the other hand, Bitcoin mining power has concentrated in few mining pools, despite technology being decentralized. This leads to the second fallacy: a fallacy of equating decentralization of power with decentralization of structure.

Those building such new decentralized systems to replace existing governments and institutions often become victims of a fallacy of beautiful models and designs. Our minds are limited. To be able to think about complex processes we create simplified models using many assumptions and reductions. We love such models. Simplicity is beautiful.

Those tools are important to help us give insight into those complex processes, but we have to be wary of starting to believe that this is all there is to those processes. That we can then just create code which encodes this simplified models and require humans to adapt their behavior to the code. We can observe that in modern urbanism where we segment cities into clear and predictable areas of different uses. This makes it easier to reason about cities, but it establishes artificial limits on possible interactions between people living in those cities. We get commuter parts of a city where people just sleep over the night. And parts of a city like financial districts where people work just over the day, but over the night nobody is around. This makes those cities and communities fragile. So different from old cities like Jerusalem.

Such models are maybe locally useful, but globally restricting. It is simply not possible to make one model, one design, which will serve everybody. Nobody likes to make programs with a long list of exceptions, but I would claim that this is what we should start doing. We should start making programs which can be messy. Be easily adapted, changed, modified. Web is like that. Wikis are like that. Programs should also be like that.

Arthur Brock talks about this by describing how cryptocurrencies have crises of governance because they have removed people from the design. It is easier to design things without messy people, but then do not be surprised when design collapses in practice.

Lawrence Lessig discusses the idea that there are four modalities which regulate us: the law, social norms, the market, and architecture/structure. Of course they also interact with each other and are dynamic, changing. On the Internet, we can see architecture/structure in a form of the code which governs cyber spaces we inhabit. Lessig talks how the government has multiple ways to regulate, not just by passing laws. And not just the government, but everyone who controls cyber spaces. Moreover, he talks also about the danger of moving from direct and explicit regulation by laws to implicit and indirect. For example, by changing the architecture/structure. Instead of using laws to legalize segregation one can use highways without easy crossings and railroad tracks to divide communities. Such urban changes still regulate, but we lose on transparency and oversight. It is a similar issue to the previously described fallacy of structurelessness. Those issues exist online as well. We replaced regulation of the cyberspace by law with the code operated by private companies. Who oversees that code? Does public have any say in it? Do you know what Facebook removes from your feed and which videos are deleted from YouTube?

But for this discussion much more important is realization how many things regulate us and how are they all intertwined, besides just law. We developed through centuries so many social institutions for all bugs and issues we discovered in our social and economic processes. We might think those institutions are rigid and slow, unneeded, and obsolete. But this is often a consequence of a fallacy of beautiful models and designs. We just do not realize all the reasons for some things to exist. Yes, we could often improve them and modernize them. But it is a fallacy to believe we can reboot a living system from scratch.

Through that we lose all the knowledge embedded inside those institutions. Most of them we are not even realizing we have. Many of them are there to protect us against misuses and mistakes which can happen. Inefficiencies are sometimes a feature to allow for a human to detect a problem.

Every founder of a community can tell you how many small things are necessary to establish for a community to really live, and especially to make it pass the first generation. Even in software we are often unable to rewrite the code from scratch successfully. And we would want to do this for such a complicated ecosystem as our society and economy is?

Current system is a mess, but how can we know that without it we would be better of? We already had unrestricted capitalism in 19th century and learned that it has shortcomings for those who do not own the capital and means of production. How we know that by removing safety belts embedded inside current institutions the old oligarchies will not reappear? That we will not have again the wild wild west. Just this time, instead of six barrel manual guns we will have assault weapons and cyber attacks at a disposal of every individual.

The DAO hack was an example of such realization. We are unable to write perfect contracts. This is why we created the judicial system. It is not perfect, but it is still better than what was at the disposal to the community to do in the case of the DAO attack. At the end, effectively rebooting the system to try again.

Traditional perspective on decentralized systems is that you have agents which communicate with each other to form a system. Many decentralized protocols use some form of voting to decide on common decisions, e.g., to which new state they should all transition. What the majority of agents vote for is seen as the correct new state for the whole system (so called consensus). This means that there can be up to half of malicious agents and the decentralized system will still operate correctly.

But sadly it is not so easy. The issue is that if membership of agents in the system is open, then a malicious agent can join the system multiple times with "puppet" agents, and because each agent gets one vote, can then enforce its view of system's state. This is know as the Sybil attack. In centralized systems this is not a problem because you can have a centralized entity controlling membership.

The ingenious solution made by Satoshi Nakamoto for Bitcoin's blockchain is to replace this "one person, one vote" voting with "one dollar, one vote" voting. In Bitcoin's case you vote with CPU cycles, not dollars. Even if you create multiple "puppet" agents they all have to share the same amount of CPU cycles you have at your disposal so you do not really gain any advantage over others.

This innovation revived the interest in decentralized technologies. A hope emerged that we could completely decentralize all aspects of our society and remove intermediaries who require fees we do not like, or can abuse power they have. We have seen many projects embark to achieve this.

But while the solution is ingenious and is an innovative shift in a perspective, it has not solved the problem at a fundamental level. As such it has issues we have to be aware of.

"One dollar, one vote" voting is the most suitable for use cases where we are already used to such voting: markets and companies with shareholders. But we have to be wary of attempts of everything being transitioned to this type of voting because we might lose true democracy of "one person, one vote" without even noticing. This is often not conscious and is just a consequence of uncritically applying blockchain technology to the problem. Especially if blockchain is already used for other aspects of a project.

While I can understand that some people like transition to "one dollar, one vote" for all aspects of a decentralized society, I would like to warn especially people who otherwise do not align with this ideology to be careful when embracing blockchain as a technology of choice for their projects. For example, projects around the platform cooperativism idea.

Another issue is that "one dollar, one vote" environment is susceptible to concentrations of power, like any other environment which is built around power. While initially it looks like such voting is democratic as well, through time an oligarchy forms. This can be seen in Bitcoin as well, where all mining is now effectively done only by a very few large mining pools.

We can see that while "one dollar, one vote" voting solution addressed one technical challenge, it brought new (but known elsewhere) challenges to the technical realm.

A consequence is that we have not really solved the problem of a decentralized true democracy where each user person would have only one vote and where we would have an open membership. We still do not know how to do achieve both at the same time. This can be seen with all governance issues of Bitcoin and Ethereum communities. One could say that those communities are not interested in true democracy, but the real issue is that they do not really have a choice at the moment. We do not yet know a necessary solution (and are we even working on it?). So we have to decide what to do in meantime: use centralized technologies which allow true democracy, or use decentralized technologies which do not?

I have heard so many times the idea of combining blockchain and IoT, but I do not get it. IoT will be producing potentially much more data that anything we had before, and a lot of that data will be privacy sensitive. How can a public and decentralized technology with scaling issues help here?

It is true that data on a blockchain is public and interoperability seems easier if everyone agrees on one blockchain. But those properties are not the fundamental properties of a blockchain. Any common technology, if parties agree to use it, improves interoperability. But nobody assures that data stored on a blockchain would be in open standard. And what when people will encrypt data stored on a blockchain to address the privacy concerns with IoT data? How does this prevent data silos?

There are many other ways to address issues of interoperability and data access. One I like is that gateways for IoT should not be black boxes but something end-users can control. You can control your home Internet router, and you should be able to control your home IoT router. If you can do that, you can prevent data silos and you can assure interoperability with those you want. Furthermore, we could enforce it through regulation (require open standards for IoT), instead of trying to get IoT companies to adopt a new technology which is not even yet ready for this use case. Why would those companies do that?

A common way to analyze signals is to do a frequency transform and try to learn about properties of the signal from there. But the issue is that most signals change through time, including speech, but a frequency transform tells us just an average presence of frequencies at the interval we are looking at. There are other ways how are people trying to address this and they might be compatible with my idea, but to keep it simple we will just use a basic frequency transform as a primitive.

We can take a small interval window (which window function exactly is another parameter here) and slide it through the input signal and compute frequencies as we are sliding. We can visualize the result for an audio of few spoken vowels into the following spectrogram.

But we can also move a window very slowly, sample by sample in the original input audio. Then we get for each frequency a new signal corresponding to how this particular frequency has been changing on average inside this window (I used a 30 ms long rectangular window). An example of such new signal is depicted with green border on the spectrogram above. Now, to use my idea, we run a frequency transform on these signals for each frequency again. As a result we get for each frequency in the input audio what are frequencies of changes of that frequency. To me this is similar to a derivative of a derivative, a second derivative.

As na experiment, I ran this on recordings of individual speech sounds. In this case I simply computed the second frequency transform over the whole new signal for each input frequency. But we could be doing windowing and sliding again, to determine how sounds are changing through time.

When doing a series of such transforms we hit against a problem of frequency resolution vs. time resolution. Shorter the window is, higher time resolution we have, but less frequency resolution we have. For speech we are interested only in a short frequency band inside which humans speak, so we could use different ways to get good frequency resolution at that band, but I simply used recordings made at a 192 kHz sample rate which provided me with more samples so I was able to have a 30 ms window but still reasonable frequency resolution.

For each of multiple samples per sound I made a double transform and visualized results below. On Y axis we have various frequencies from the input (oriented the same as in the spectrogram above, but just band around human speech shown), and on X axis we have power of each frequency of frequency, starting from the left. It seems changes to frequencies are itself at a very low frequency so I am showing only low frequencies. Each image continues far to the right, but does not contain anything visible there.

Visually, they look pretty similar to each other when comparing the same sound, and nicely different when comparing across sounds. This is great! This gives us 555 values (37x15) we can feed into a pattern recognition algorithm. Deep learning or something similar. I will leave to somebody else to test deep learning on this and to determine how to upgrade this one sound recognition to speech recognition when sounds are changing through time. Good luck!