Update concept of “application” #16

New issue

Closed

opened 2022-10-04 19:37:29 +02:00 by aral · 2 comments

aral commented

2022-10-04 19:37:29 +02:00

Owner

In the original prototype (built in NodeKit), the concept of an application was rather generic and meant “a cloud-init script.”

When defined this loosely, an application can be anything that can be installed on a Linux machine.

(And this is similar to the functionality afforded by free/open hosting solutions like Yunohost, etc.)

Initially, I went this route for the prototype as I wanted to demonstrate the ease of use of Domain by installing Owncast instances. Owncast, being a single-tenant app, is a good example of what small web apps can do without resorting to multi-“user”, centralised Big Web designs.

However, on further thought, I feel we need to narrow down the scope of what an application is in Domain to further focus on the creation of Small Web apps using Kitten.

With control over the provisioning system and the platform used to make apps, we can further improve the experience by:

Ensuring apps/Small Web places (servers) have an admin panel where you can communicate with the Domain instance that provisioned the server to do things like update your payment details, cancel your account, etc., without requiring the Domain instance itself to implement and administration panel. This feels far more decentralised to me as the only time the person is required to visit the Domain instance is when provisioning the server. Afterwards, they can do everything else from their own server, including communicating with the Domain instance when they need to.
Creating an ever simpler definition of what an app is: An app is the Git repository of a small web app written in Kitten. Apps in the interface have names (for ease of use) but people can also install any Kitten app just by providing its URL.
Given that Kitten apps will host their own source in their own Git repositories (this will eventually be part of the featureset of Kitten), you will be able to install your copy of any Kitten app you see on the web.

So imagine:

Someone tells you they made a Kitten app (let’s say a simple blog app). You visit it (at https://my-lovely.blog) and like what you see.

You then go to a Domain instance and you say “I want my own copy of the app at my-lovely.blog.”

Since it’s a Kitten app, Domain knows that its source is at https://my-lovely.blog/.well-known/source.git

So it sets up your own copy at, say, my-very-own-blog.org by cloning that repository.

This will also decentralise distribution of apps. Of course, you must trust that that server/instance has the upstream source. So there should also be an option to clone the canonical repository. Perhaps that could be another well-known location like https://my-lovely.blog/.well-known/canonical-source.git, which redirects to the canonical git repository.

I feel this approach to apps for Domain will result in (an initially small but) vibrant community creating and easily sharing, cloning, modifying and remixing small web apps.

It’s also not a million miles removed from Tim Berners-Lee’s original vision for a read/write web.

In the original prototype (built in NodeKit), the concept of an application was rather generic and meant [“a cloud-init script.”](https://ar.al/2022/09/28/nlnet-grant-application-for-domain-first-update-questions-and-answers/) When defined this loosely, an application can be anything that can be installed on a Linux machine. (And this is similar to the functionality afforded by free/open hosting solutions like Yunohost, etc.) Initially, I went this route for the prototype as I wanted to demonstrate the ease of use of Domain by installing Owncast instances. Owncast, being a single-tenant app, is a good example of what small web apps can do without resorting to multi-“user”, centralised Big Web designs. However, on further thought, I feel we need to narrow down the scope of what an application is in Domain to further focus on the creation of Small Web apps using [Kitten](https://codeberg.org/kitten/app). With control over the provisioning system and the platform used to make apps, we can further improve the experience by: - Ensuring apps/Small Web places (servers) have an admin panel where you can communicate with the Domain instance that provisioned the server to do things like update your payment details, cancel your account, etc., without requiring the Domain instance itself to implement and administration panel. This feels far more decentralised to me as the only time the person is required to visit the Domain instance is when provisioning the server. Afterwards, they can do everything else from their own server, including communicating with the Domain instance when they need to. - Creating an ever simpler definition of what an app is: An app is the Git repository of a small web app written in Kitten. Apps in the interface have names (for ease of use) but people can also install any Kitten app just by providing its URL. - Given that Kitten apps will host their own source in their own Git repositories (this will eventually be part of the featureset of Kitten), you will be able to install your copy of any Kitten app you see on the web. So imagine: Someone tells you they made a Kitten app (let’s say a simple blog app). You visit it (at https://my-lovely.blog) and like what you see. You then go to a Domain instance and you say “I want my own copy of the app at my-lovely.blog.” Since it’s a Kitten app, Domain knows that its source is at https://my-lovely.blog/.well-known/source.git So it sets up your own copy at, say, my-very-own-blog.org by cloning that repository. This will also decentralise distribution of apps. Of course, you must trust that that server/instance has the upstream source. So there should also be an option to clone the canonical repository. Perhaps that could be another well-known location like https://my-lovely.blog/.well-known/canonical-source.git, which redirects to the canonical git repository. I feel this approach to apps for Domain will result in (an initially small but) vibrant community creating and easily sharing, cloning, modifying and remixing small web apps. It’s also not a million miles removed from Tim Berners-Lee’s original vision for a read/write web.

👍 2

aral commented

2022-10-09 23:39:04 +02:00

Author

Owner

Progress: a3a60e6, 29bf975

Progress: a3a60e6, 29bf975

aral commented

2022-10-25 17:19:29 +02:00

Author

Owner

The admin applications section has now been updated to reflect this new understanding of what an application is (as of 653bdb8).