Utilizing Qortal data, any number of applications can be built. Initially, these applications will likely be built only by the Qortal development team or trusted community members until we have the availability (and more developers) in order to accurately vet and test each application created by ‘anyone’. The end goals will be to create a ‘plugin store’ wherein plugins that are not ‘default plugins’ (part of every base installation) will be available to browse, read reviews on, and install to any Qortal Node.

Every application built on Qortal data will be by default ‘unhackable’, decentralized, and redundant (moreso as each user accesses the application). The underlying functionality of Qortal data allows for extremely secure applications with innumerable possible use cases. Remember that Qortal is infrastructure and meant to be the base level for any potential application, website, blog, or anything used by people on a regular basis. Therefore the Qortal development team is focused on building the infrastructure and a few base level applications to demo what the platform can do. The rest of the applications and functionality within will be developed by whoever has the idea and takes on the task.

The Qortal development team is community-formed and community-run. Anyone can become part of the team by showing interest and demonstrating their skill. Therefore the team will continue to grow and the applications built will continually become more diversified, functional, and fully featured. As with the infrastructure of Qortal itself, more functionality comes with more development and more development comes as the developers have the availability. As the user count of Qortal increases and the price of QORT follows, the availability and subsequent development from the ever-expanding development team will also increase.

There is quite literally no limit to the number of nor functionality of the applications that could be built on top of Qortal’s unique infrastructure. The limitless nature of the potential of the platform is what will draw countless developers’ interest to help build out the platform and its applications.

Two main types of applications will exist: 1) default applications and 2) add-on applications. Default applications will come with the default installation of the software and will be ‘part of Qortal’ by default. These applications include some of which already exist like Q-Chat and the Trade Portal. Default applications are the ones that will ‘just be there’. Add-on applications (plugins and modules) are applications that will not be included by default when installing Qortal, but can be chosen by each user and installed to their node on an individual basis to provide whatever added functionality they seek.

Qortal is the only blockchain platform that has both the ‘data layer’ and the ‘application layer’ making it an all-in-one solution for hosting any application with blockchain security and true decentralization.

Here's some information from Cal on the Dev Server:

I think I might try and get the basic app store live in time for the Greater Reset. I remember at the last one John Bush asked "how do we build an app on Qortal?" - so I think that being able to present that as a real option would be great for that audience

I think that the extremely basic idea I have for the app store will allow anyone to create e.g. a blogging platform, or even a simple social network.Plus things like a youtube alternative and an iTunes alternative. I will probably make one or two apps to demonstrate what can be done, and to offer a template to othersz

We can lock it down so that apps are only able to a) request data and b) publish data - that way they can't get involved with user funds or anything like that and the user would have to approve all requests, especially those that involve signing an ARBITRARY transaction.

The architecture would work like this:

1. a user installs an app and accepts its requested permissions (i.e. the types of data it can request)

2. the app is served by the core, but being displayed by the UI in a sandboxed iframe

3. the app wants to display some data

4. app sends a message to the UI describing what it wants to request

5. the UI checks that the request is within the pre-approved limitations by the user

6. the UI then makes a request to the core, using the API key (this stops the app from requesting things directly)

7. the UI returns the data to the app via a message

8. the app displays the data

Then the app wants to publish data:

1. the app sends a message to the UI with the data payload, resource ID, service type etc that it wants to publish

2. the UI again checks that this is within the allowed params (would be really strict)

3. if the params are allowed, the UI displays a popup showing the user what the app wants to publish

4. the user can confirm or deny the request

5. if confirmed, the UI signs a transaction using the private key

6. the UI informs the app on the outcome

Luckily, HTML5 has an iframe "sandbox" function which is ideal for what we need. It allows us to completely separate the app from the UI that is running it, so that it has no access to sensitive data. javascript also has a postMessage() API to allow the container app to communicate with the sandboxed frame using pre-defined APIs (i.e. we allow it to request to show or update data, and nothing else). Which again is perfect for what we need.

We are also protected by the fact that the core and UI run on different ports, which browsers treat as different origins, and therefore are sandboxed automatically. But we can add the sandbox feature just to be extra careful.

Once the app store is ready I'm going to make one or two simple apps as an example. Then I hope others will give it a try too - they can extend my demo apps or start from scratch. I think one of them will be a really simple youtube alternative. So a place to upload videos and view them. The other might be a music player, or maybe a really basic blogging app, as that's probably more useful. The apps will be written in javascript, along with HTML, CSS, images etc. You can use any framework you like, such as React / Vue / AngularJS / jQuery, or even pure javascript. I will probably start by using a really lightweight framework called Alpine.js that allows you to add dynamic content to HTML really easily.

The best part is that it is completely permissionless. Anyone can add an app to the store without any prerequisites. It's basically the opposite of Apple's "approval" system for iOS apps. There could be 10 different blogging apps for instance, all written by different people and if someone doesn't like the existing options, they can make their own. Either by starting from scratch or by forking one of the existing ones and releasing a modified version with a new name. There will likely be a lot of "junk apps" and we'll have to find a way for people to filter them. Probably some kind of rating system, as part of the upcoming voting feature. So we won't have anything like that in the first version. We already have the ability to block a name, and once blocked, the node will stop showing or hosting data from that name. As time goes on, it can become more granular, so you can for instance block an app but still keep supporting the website hosted on the same name. But that is lower priority at the moment and will only be done if there is time before we go live at the end of the year.

We already have private blacklists, but we can easily make it so that a user can upload their blacklist (or any other list) to the data network for others to use or modify. The idea being that people can publish any kind of list - even one that is just their favourite content - and then others can browse it (or in the case of blacklists, choose to automatically block everything on the list). The data network supports this kind of thing already - we're just missing the UI/interface for it.