Domain - NLnet Grant Application - August 2022

This is my application to get NLNet funding to work on Domain as part of the User-Operated Internet Fund

I feel it’s important that such grant applications are made public so everyone has visibility into the process. This will allow us to collectively learn from the experience and perhaps even to improve the process itself.

As such, I’ll be making my end of the process as public as possible by not only sharing my original grant application but any subsequent communication I receive during the process. And I urge you to do the same on your own site when applying for similar grants.

Application

NLnet Grant Application for Domain

29 Jul 2022

This is my application to get NLnet funding to work on Domain as part of the User-Operated Internet Fund1

I feel it’s important that such grant applications are made public so everyone has visibility into the process. This will allow us to collectively learn from the experience and perhaps even to improve the process itself.

As such, I’ll be making my end of the process as public as possible by not only sharing my original grant application but any subsequent communication I receive during the process. And I urge you to do the same on your own site when applying for similar grants.

Public money, public process, public code.

Timeline

Call topic

  • Thematic call: User-Operated Internet Fund

Contact information

General project information

Abstract: Can you explain the whole project and its expected outcome(s). (1200 characters)

Domain creating an Owncast server in under a minute (live stream demo).

Domain aims to democratise the ownership of web sites and commoditise the gatekeepers.

“The best thing about the internet is that … [f]rom the edges inwards, users themselves can collectively own, operate and rewrite every aspect of the technology and infrastructure they depend on.” – User-Operated Internet Fund

Yes, we can. But it is technically difficult to do so.

This is the problem Domain aims to solve.

Think about what you have to do today to have your own web site (or self-hosted web application) running on your own server:

  1. Buy a domain name from a commercial domain name registrar.
  2. Sign up with a commercial web host (e.g., DigitalOcean, Hetzner, etc.)
  3. Provision a server (e.g., virtual private server) with your web host.
  4. Configure your Domain Name System (DNS) records to point to your server.
  5. Install or configure a web server, the site (or app) you want to host, as well as any other required software (database, etc.).
  6. Ensure your server is sufficiently secure.
  7. Maintain your server by installing updates to your operating system and other related software on a regular basis.

While none of this is terribly difficult for seasoned developers or system administrators to tackle, it is not a process you would expect someone without technical skills to undertake without a considerable investment of time and effort.

And we want everyone to have their own place on the Web, not just those of us who have the relevant technical knowledge.

Furthermore, it can easily take at least half an hour even for technically-savvy folks to go through all those steps to set up a simple site or app (and longer still if you have to configure databases, message queues, etc.) I once watched an experienced software engineer struggle to set up his own Mastodon instance for an afternoon before giving up. ’Nuff said.

The goal of Domain is to reduce this process to under a minute.

(So we’re talking about an order of magnitude difference or more.)

Here’s a video of Domain creating and running a new Owncast server in under a minute.

How does it work?

Domain is being built for use by two different audiences:

  1. Hosts: Organisations/technically-savvy individuals who run domain as a service for their communities.
  2. Everyday people: Who use the Domain instances set up by hosts to commission, own, and control their own web sites and apps.

For hosts

Domain enables organisations and individuals to provide web hosting services for small (personal) web sites and apps to the general public.

As a prerequisite, hosts need to sign up for the following constituent services:

  • A web hosting provider (initially only Hetzner will be supported2).
  • A DNS provider (initially only DNSimple will be supported).
  • A domain name that they’ve added to the Public Suffix List3.
  • Optionally, an account with a payment provider if they plan to charge for hosting (initially only Stripe will be supported).

Screenshot of the Domain administration panel showing the Public Suffix List (PSL) tab active. The domain small-web.org is on the PSL.

The Domain Administration Panel.

Once a host has acquired the required accounts and their domain is on the Public Suffix List, they will use the simple online administration interface provided by Domain to enter the relevant API keys for each of these services.

Screenshot of the Domain administration panel showing the VPS Host Settings screen with API Token and SSH Key Name input boxes.

The VPS Host Settings screen.

Domain combines these fundamental services into a simple and seamless flow to enable everyday people to sign up for their own sites and apps at their own domain.

Screenshot of Domain administration panel showing the App Settings screen. Available choices are “Site.js”, “Owncast”… Owncast is selected.

The App Settings screen.

Hosts can decide which apps and sites people can install. These apps are defined in the online interface by their installation and configuration instructions in a standard format known as cloud-init. It is currently possible in the Domain prototype to install Owncast, for example, as well as a generic Site.js web site.

Screenshot of Domain administration panel showing lower part of App Settings screen with the Owncast cloud-init configuration

App Settings: Owncast cloud-init configuration.

Domain will democratise the process of being a web host and enable small organisations and even individuals to host sites and apps for their local communities.

The Small Web design of Domain sets natural limits on how large a host can grow. Our goal is to encourage a community of lots of small, independent, and ideally not-for-profit hosts around the world. Each of which, of course, can customise Domain for their own needs and culture, given that it is released under AGPL version 3. This license also means that any improvements to Domain must be shared back into the commons, thereby strengthening it for everyone. (And it prevents, for example, a venture-capital-funded startup in the future from taking the software, spending a few million dollars to improve it, and then keeping those improvements to themselves to create fragmentation and lock-in.)

Domain is being built with an integrated web server and web development platform called Kitten (previously known as NodeKit).

Kitten is being developed alongside Domain, with Domain’s requirements determining its features.

Kitten will also be used to create and serve small web sites that can be installed with Domain and will be a useful tool itself in lowering the barrier of entry to developing and hosting your own web site or app. While Kitten is not the focus of this grant application, it is important to understand that it is impossible to separate the two as they are being developed in parallel and any support for our development work will benefit both of these intertwined projects.

For everyday people

For everyday people, Domain presents a very simple interface:

Choose a domain and select an app to install. Optionally, provide payment information and, within a minute, you’re up and running with your own site at your own domain.

Screenshot of Domain’s public-facing page. Interface reads “I want my own (editable field) Place at (editable field) domain .small-web.org for €10/month. A green button reads “Get Started.”

The Domain interface for everyday people.

As far as I’m aware, there is currently nothing that approaches this in terms of ease of use.

The speed and ease with which everyday people can set up their own sites and apps at their own servers is at least an order of magnitude faster than what’s available today. We believe that this will have a substantial impact in democratising the Web by enabling more people to own and control their own place on it.

Have you been involved with projects or organisations relevant to this project before? And if so, can you tell us a bit about your contributions?

“Technology should be a commons for everyone to enjoy and contribute to, without gatekeepers or persistent threats.” – User-Operated Internet Fund

We formed Ind.ie in 2013 and have been working towards this very ideal ever since. In the intervening years, as our understanding of the problem grew, we honed our focus and limited resources on effecting change were we feel it will be most impactful and least likely to be threatened by proprietary systems and corporate control: the open web.

Screenshot of magazine: “…relying so heavily on the “free” data-slurping tech giants. But some people are trying to change the dynamic. Aral Balkan is an activist and co-founder of Indie, which develops privacy-minded tools and services. He is working with the Belgian city of Ghent to provide an alternative to social media sites. Citizens will be able to. sign up for their own .gent website, which will be able to follow and update other .gent sites. The sites will also connect to other like-minded services such as Mastodon, a privacy-respecting alternative to Twitter (see “Ditch and switch”, right). The idea is that it will work much like a Facebook profile, but each person will own their own site there is no central authority hoovering up your data. On the face of it, that sounds a lot like the old web, where people created simple pages hosted on computers they controlled. The crucial difference is that it used to be difficult to put things online without technical know-how —which is partly why easy-to-use services like Facebook are popular. Balkan wants the .gent project to be simple to use, with plans for the webhosting and domain registration to happen in the background. “We solve that problem, and that’s where we change the game,” he says. The project is being funded by the city of Ghent, which Balkan says is a model for the way forward. “We need to start funding these ethical alternatives from the commons, for the common good,” he says. He's not calling for social media to be run by the government or for Facebook to be nationalised, he says - the potential for surveillance is too high. The Chinese government plans to use personal data to rate individual citizens, for example. Instead, the taxpayer could fund online services, which are kept at arm's length from the state.”

The Indienet project as covered in New Scientist

In 2017-2018 we worked with the City of Ghent, in Belgium, on prototyping the Indienet project. The goal was to demonstrate how citizens could have their own web sites (at a .gent domain) and own and control their own data when interacting among themselves and with the municipality. Sadly, a conservative local government was elected and our funding for the project was cut.

The Indienet project was the spiritual predecessor to Domain.

The Indienet project taught me several things: first, not to rely on public funding which might be taken away at any moment when the winds of politics change and, secondly, that we must build our own tools and frameworks at all levels of the stack to radically simplify the development and deployment of personal web sites and apps.

As part of our research and development efforts, I’ve been iterating on a personal web server and web development platform since 2019, when I first launched HTTPS Server which became Indie Web Server, and finally Site.js. The latter currently powers all our sites, including https://small-tech.org, my blog at https://ar.al, and, of course, https://sitejs.org itself.

Kitten, the server/framework I am building in parallel to Domain, is the next iteration of these efforts. It makes modern web development about as simple as it can get by eschewing a complicated build process and heavyweight JavaScript frameworks and enabling people to create web sites using plain HTML, CSS, and JavaScript and, optionally, enhancing them with HTML-over-the-wire via htmx and simple interactivity using hyperscript.

Domain is being written in and will be powered by Kitten.

Kitten (and thereby Domain) benefits from components that I created for Site.js, including the auto-encrypt library for simplifying secure sites with automatic Let’s Encrypt certificates and JavaScript Database (JSDB), a simple in-memory, streaming write-on-update JavaScript database for Small Web use that persists to a JavaScript transaction log.

(An earlier iteration of Kitten was called NodeKit and used Svelte instead of htmx. The current prototype of Domain in written in NodeKit and is being ported over to Kitten. The current prototype is able to deploy sites using Site.js. In fact, it’s how we set up our streaming server for Small Technology Foundation at https://owncast.small-web.org.)

Requested support

Requested amount: €50,000

Explain what the requested budget will be used for. Does the project have other funding sources, both past and present? (If you want, you can in addition attach a budget at the bottom of the form):

The requested budget will be used, after taxes, to pay me, a software developer with over two decades of professional development experience, to work on the project for the next 12 months (at a rate that’s less than half of what I was earning working in the mainstream two decades ago).

Our funding sources for Small Technology Foundation are and have been:

  • (Past) An initial crowdfunding round in 2013.
  • (Past) My selling two family homes in Turkey.
  • (Past and present) Patrons and donors.
  • (Present) Laura’s contracting work with Stately.

Compare your own project with existing or historical efforts.

The closest existing tools and projects to Domain are:

  • Hosting providers like DigitalOcean, Hetzner, etc. when combined with commercial domain name registration services.

These suffer from the complexity problem mentioned above and are profit-oriented corporate initiatives that do not have any sort of social mission to democratise the Web or technology.

  • Free and open source self-hosting platforms like Yunohost.

These systems provide web site/app installation functionality but they must themselves be hosted (which requires all the steps that Domain automates and streamlines). To illustrate, you could use Domain to create a server running Yunohost.

What are significant technical challenges you expect to solve during the project, if any?)

In terms of feasibility, I don’t believe there are any major questions left unexplored (as I have been working on the underlying infrastructure and design for several years now and I already have a functional prototype of Domain).

In the coming days, I will be porting Domain from NodeKit to Kitten and evolving Kitten to handle any unmet requirements this process might uncover in it. I feel very good about this as the replacement of Svelte with htmx has removed a large chunk of complexity from (the already lightweight) framework and developing with it feels excellent so far.

Now that the architectural decisions have been locked down, I expect a rather straightforward and sustained development effort with ongoing releases of both Kitten and Domain in the coming year.

Describe the ecosystem of the project, and how you will engage with relevant actors and promote the outcomes?

Initially, my goal is to launch our own Domain instance at https://small-web.org to demonstrate how it works and so it can start bringing in income for Small Technology Foundation. (Our goal is to become sustainable so we can keep working on the Small Web.) I envision that the initial people who play with it to set up their own sites and apps will be people who hear about it because they follow me on the fediverse.

I hope that once other developers see that it works, they might want to start becoming hosts themselves (either individually or with their organisations). My goal is to eventually see a healthy ecosystem of independent (and ideally not-for-profit hosts) around the world using Domain to empower their communities to own and control their own places on the World Wide Web.

I would love to see community groups, cooperatives, municipalities, and other organisations experimenting with alternative means of sustaining such efforts. The token ‘payment’ system in Domain, for example, could be used by a city to mail out codes to all its citizens that they can then use in lieu of payment to set up their own web sites and apps. (This is the model we were exploring with the City of Ghent.)

Finally, although Kitten is not the focus of this grant proposal, since it is being developed in parallel with Domain (and given that Domain is being written in it and will be powered by it), I believe that Kitten will also open up web development to a wider group of people by removing the complexities inherent in current corporate stacks. I foresee it being used to teach web development (at the very least, I foresee myself using it to teach web development).

Attachments

None.

(Please see links in the body of the proposal.)

How may we handle your information

(If you haven’t, please check our privacy policy).

When your project gets selected, we will legally need to retain your information for compliance purposes for at least seven years. Also, in case you are submitting to one of the NGI related funds, at that point we will need to share some information with our (not-for-profit) partner organisations in order so they may assist you with mentoring as well as complementary services e.g. accessibility, documentation, localisation, packaging, etc. By submitting a proposal you grant us permission to handle the data in the proposal in the manner described.

What should we do in the other case, e.g. when your project is not immediately selected?

  • I allow NLnet Foundation to keep the information I submit on record, should future funding opportunities arise
  • Send me a copy of this application.
Questions

Nlnet Grant Application for Domain – First Update: Questions and Answers

28 Sep 2022

This is the first update to our NLnet Grant Application for Domain.

You applied to the 2022-08 open call from NLnet. We have some questions regarding your project proposal Domain.

Thank you for getting back to us. Please find the answers, inline, below.

You requested 50000 euro, equivalent of one year of effort. Can you provide some more detail on how you arrived at this time estimate? Could you provide a breakdown of the main tasks, and the associated effort? What rates did you use?

As a funding body, I can see why the question of funding amount is the primary question. However, as someone who has eschewed mainstream income and other benefits to work for the common good, it is the least important one for me so I’ll leave this to the end and tackle your other questions first.

Can you compare Domain to chatons.org and Libre.sh (note the former community also already uses the word Kitten…)?

Let me tackle them separately:

Domain vs. Chatons

CHATONS is an excellent initiative by the lovely folks at Framasoft – who have supported our work in the past with translations of our articles into French – to create “a collective of small structures offering online services (e.g. email, web hosting, collaborative tools, communication tools, etc.)”. They call these structures “hosters.”

Within the CHATONS, model, Domain is a tool to enable the creation of more hosters. Everyday people can then use the Domain instances of those hosters to set up their own small web places.

Once Domain is ready for use, CHATONS is a collective that I can see us considering becoming a part of with Domain and Kitten (after all, as you point out, they’re already called Kittens so even that fits).

Domain vs. Libre.sh

Libre.sh, from what I can tell based on their web site, is a tool for people with technical knowledge to set up web sites using Kubernites or Docker Compose. These are enterprise technologies used by Big Tech and involve a high level of complexity. In the Getting Started guide for the Kubernites version of libre.sh, you are shown how to deploy a cluster with 9 machines: “3 masters, 3 ingresses, 3 compute”. Needless to say, this is a completely different use case than Domain.

The goal of Domain is to enable organisations to become small web hosts, where they can provide a simple interface for everyday people without technical knowledge to set up their own small web places (sites/apps). As such, you can think of it as “Digital Ocean in a box” for anyone who wants to run their own small web host.

Domain provides a holistic solution that integrates the necessary components of provisioning a VPS, managing subdomains (DNS), installing web applications, and (optionally) charging for the service (or otherwise controlling access to resources).

The problem libre.sh solves is how do we “host free software at scale?” while the problem Domain solves is “how do we enable people to host free software that doesn’t scale?” (in other words small web places). And, crucially, how do we make it possible for any organisation to become such a host? And easy for people without technical knowledge to set up small web places using it?

if one would use Domain to install e.g. Yunohost or Sandstorm, what would be the added advantage compared to deploy a preconfigured image of these directly at a VPS hosting company (which is already on offer with some hosters).

You wouldn’t use Domain to install Yunohost or Sandstorm as they are different approaches to solving similar problems. Both Yunohost and Sandstorm offer dashboards for installing existing web applications. These are applications that, for the most part, have been created in the traditional multi-user, Big Tech design, with out-of-process databases, etc.

Domain, on the other hand, is for hosting single-tenant Small Web applications. The kind that you can create, for example, with Kitten.

Domain does not aim to support every type of web application but a very specific type (single tenant, small web application). This is its greatest strength as this focus and control means that we can simplify the experience and reduce the system requirements throughout the stack and lifecycle (e.g., when it comes to automatic updates and maintenance).

Yunohost, Sandstorm and similar projects are great in that they allow more people to install and use existing free/open source “multi-user” web apps that have almost entirely been designed with Big Web architectures.

Domain aims to do the same thing for Small Web apps while reducing complexity and the need for technical knowledge and improving the overall experience.

The Domain approach could be interpreted as poor-mans hosting and/or entry level shared hosting (which is already a very competitively priced economic area). In order to cut prices ,there are definite significant tradeoffs which may bite the user in the longer term.

I wouldn’t call Domain’s approach to democratising hosting by enabling independent organisations to become small web hosts “poor man’s hosting” any more than I would call the platform cooperative movement “poor man’s corporations”. The goal is to democratise not just the ownership of small web places but to do so without centralising them at a single host (e.g., us).

While price is an important factor for commercial providers (in that there is likely a psychological number beyond which it would be deemed too expensive for a small web place), it is definitely not the primary focus. As mentioned in the original funding application, Domain can be run as a private instance (e.g., internally for organisations, neighbourhoods, families, etc.) or using a token-based system (where, for example, a municipality can issue tokens that citizens can exchange for the own small web places instead of using legal tender).

Finally, the type of hosting integrated into Domain is Virtual Private Server (VPS) not shared hosting.

Borrowing a subdomain from someone doesn’t offer much legal standing, whether it is on the public suffix list or not.

Borrowing a subdomain from an organisation offers the exact same legal standing as borrowing a sudomain from a commercial top-level domain (like .com, etc.) provider in that they are both subject to contract law. So whatever terms are in the contract are the legal standing that is offered.

The difference between a commercial top-level domain provider and organisations that will be running domain (like our not-for-profit Small Technology Foundation) is the reason why the domains are being offered. In the former, it is to make a profit. For us, it’s to provide people with a location that they can be easily reached on the Web with.

When a host folds the entire reputation of its user base is immediately destroyed (unlike the case of a TLD, which has an escrow arrangement enforced by their ICANN contract). When someone forgets to backup and things crash, users have little resort. And small payments are expensive to process, eating further into the “Domain” hosters margins. What countermeasures do you propose for such scenario’s to give users peace of mind? Is there some form of service portability?

Indeed, if a host shuts down, this would take down everyone they host. This is a problem inherent with decentralisation and we see it when a fediverse server goes down too. This is not to say that the solution is then to ensure that only a handful of mutli-billion-dollar commercial hosts should exist. Just as the solution to fediverse servers being shut down is not to say that everyone should use Twitter instead because we can trust it’ll be around in one form or other.

Instead, possible mitigations for this fact of life include:

  • Supporting small web hosts from the commons
  • Encouraging as many small web hosts as possible so that if one goes away the damage is limited
  • Ensuring that it is as easy as possible to move between small web hosts (portability)

While the first one would involve political will, the second and third are issues that Domain exists to tackle.

On the topic of payments, Domain initially supports Stripe which, to the best of my knowledge, does not impose higher fees for the sorts of amounts we’re talking about. Microtransactions (which is not what this is) might be a different matter but do not concern our use case for Domain.

Finally, while the initial setup is on a subdomain, it will be easy to configure the site to use any domain (on a regular TLD) after the fact. The initial setup using a subdomain is a design decision to both enable people to have a small web place without paying separately for a commercial domain name and to keep the setup time as quick as possible.

If people are expected to pay 10 euro’s a month, that puts them in the realm of CPanel and Plesk/managed services which are already common with hosting companies for decades - and at prices going down to below 1 euro per month for e.g. Wordpress hosting for which tens of thousands of tutorials and extensions to make everything possible. What planned features are supposed to lure people over from that competition (and the marketing power of players like Strato)?

First off, to clarify: the €10/month number is an initial estimate. It’s based on our own research into what could make Small Technology Foundation sustainable by hosting a Domain instance at small-web.org. It’s also based on my belief that it’s likely the maximum amount you could charge that still feels “small.”

And, again, Domain instances can be private and token-based. The commercial payment aspect is a sad necessity for organisations like ours that need to survive under capitalism today while hopefully creating systems that will mean that eventually we will have kinder and fairer systems tomorrow where we better understand the value of the commons and support it accordingly.

If cheap is the main target, would it not be more convenient to point people to dot.tk et al, which gives them a ‘real’ domain name (discussion about their security aside) at no cost, conveniently exposed by an API that allows for automation?

Cheap really isn’t the main target. If anything, affordable is. And, ideally, in time, we’d love to see small web hosts supported from the common purse for the common good. But until that time, we aim to prove, even within the success criteria of the current system, that we can be sustainable.

If someone wants to use a dot.tk name (not linking to them as their site doesn’t use TLS which doesn’t give me a lot of confidence about them), they will be able to.

You state that a domain on the public suffix list would “provide all the privacy and security guarantees that any other top-level domain can”. Is that actually true? i

Yes, like the other statements in our funding application and that we make in general, it is true :slight_smile:

(If we wanted to get into lying, we’d be working in the mainstream. You can make a lot of money there doing that. It’s actually quite a sought-after skill.)

To reiterate, from the official description:

It allows browsers to, for example:

  • Avoid privacy-damaging “supercookies” being set for high-level domain name suffixes
  • Highlight the most important part of a domain name in the user interface
  • Accurately sort history entries by site

When a domain is on the Public Suffix List, it is, for all intents and purposes, a top-level domain and is treated as such by browsers. This is a very useful hack for creating domains that are not part of the commercial top-level domain business and is one of the fundamental design decisions in Domain that sets it apart from other initiatives in the area.

A lot of information can already be learned just from the DNS requests the second level nameservers would see. How do you intend to deal with e.g. TLSA records, DNSSEC, SPF, etc? What kind of alternative services will be delivered (for instance e-mail? ) How will e.g. spam and blacklisting impact sibling Domain-hosted efforts?

As a project from a not-for-profit that exists to protect privacy, Domain includes privacy policies for hosts based on data minimisation. While the initial service providers for DNS, VPS, TLS (DNSimple, Hetzner, Let’s Encrpypt), etc., do have the means to gather data, this is true in general (not specific to Domain) and they are bound by the rules of GDPR.

Because of ACME, meanwhile there has been a lot of work on automation of DNS challenges (acme.sh/dnsapi at master · acmesh-official/acme.sh · GitHub). Would it not make sense to seek a similar approach for the DNS management, where one does not depend on hardcoding a single US based domain name company (DNSimple) as exclusive provider?

DNSimple is not used for TLS certificates. Kitten uses Auto Encrypt (another of our free and open source libraries) to automatically provision TLS certificates using Let’s Encrypt’s HTTP-01 challenges.

DNSimple is used for setting up the domain records for subdomains.

And, again, DNSimple is simply the first provider we are building support for to get Domain up and running. The goal is to support others that have APIs and to thus abstract out the APIs, hopefully commoditising these services to some degree in the process.

How would applications be packaged and maintained/security hardened? Is this something you have experience with?

Applications are “packaged” (insofar as we can use that term for it) in Domain using cloud-init. Currently, this is on standard Ubuntu 22.04 instances with unattended security updates enabled. However, we are keeping our eyes on immutable operating systems like CoreOS to aid in OS updates in the future.

Much of the security of Kitten and Small Web sites comes from their simplicity and small attack surface. There are fewer moving parts, less code, and basic standards being used.

Can you elaborate on deployment and maintenance requirements after initial deployment - which tend to forms a continuous drain on resources at the project level and the user level?

Small Web sites/apps built on Kitten and deployed with Domain will be entirely self-maintaining.

Kitten’s installation process is based on git and it also clones git repositories to deploy apps.

There is also work underway to implement:

  • Automatic updates for the deployed app (via git)
  • Automatic updates for Kitten itself (again via git)

Eventually, when immutable server operating systems become available, the goal is to have automatic major version operating system updates as well for completely hands-off maintenance. (In the meanwhile we will be deploying to LTS versions of Ubuntu which will give us quite a few years of headroom on this.)

You mention that setup can be done in under one minute, but surely beyond that someone will have to do the hard work?

No, that’s the whole idea: there isn’t. When you install a small web app and, say, 45 seconds later, it’s ready, it’s actually ready. You hit your domain. You start using it. That’s all there is to it.

Is there a threat analysis that you’ve considered during the design phase - if one of the fellow hosted community members doesn’t update their version of X, how do you prevent compromise of the rest? Is configuration and user management separate from delivering bits? Would Domain packages offer reproducibility, like Nix/Nixpkgs (which has a vast collection of software, see repology.org)?

The security model of Domain follows, in the words of Joanna Rutkowska (of Qubes, etc.) “security through distrust”.

This results in some core design decisions:

  • Domains are on the Public Suffix List (so no one can set supercookies, etc.)
  • Every person gets their own virtual private server (we don’t use shared hosting)
  • Every site is automatically protected by TLS

And, to reiterate, some related properties even if they may not seem to immediately be security-related:

  • You can use your own domain.
  • You can easily move away from a host.
  • All code is free and open.

Regarding reproducibility, since small web apps are installed via git, there isn’t necessarily a build process involved. Where one is (e.g., via npm install), it would be up to the apps themselves to ensure that dependencies are locked and loaded from trusted sources and that commits and tags are signed.

You requested 50000 euro, equivalent of one year of effort. Can you provide some more detail on how you arrived at this time estimate? Could you provide a breakdown of the main tasks, and the associated effort? What rates did you use?

Finally, to return to the first question: I work full time at Small Technology Foundation and my work these days is full-time on Kitten and Domain. So, let’s say I work 40 hours a week on average (it can vary and I often work on the weekends too):

€50K/yr comes down to about ~€26/hour.

Let’s put this into perspective: over a decade ago, when I doing regular development work as a contractor, I was charging €100/hr. My partner, who is contracting with Stately (a startup), makes more than double this amount a year and this is the main source of income that is currently sustaining Small Technology Foundation (the two of us and our dog). Previously, I’ve sold two family homes in Turkey and we’ve relied on a combination of sales of our tracker blocker (Better, now retired) and fees from conference speaking to scrape by.

All this to say that I don’t actually care how much funding we get. (I wonder if this is why they don’t usually let me write the funding applications?) Whether it’s €50K or €0 or something in between, we will keep working on Kitten and Domain and we will keep working on our vision for a Small Web owned and controlled by people, not corporations. We’ve always found a way and we will continue to do so.

What would be nice, however, is to feel like we are supported. We have been working for the common good for almost a decade now and it would be nice to have it funded from the common purse to some degree at least. And it would also be nice to have some stability so we can keep working on this without worrying about how we’re going to exist in X months time.

While I understand that the funding from ngi/NLnet is mostly project (and maybe even feature)-based, I do believe we need to think longer term and support folks like ourselves who are essentially carrying out research and development.

Silicon Valley understands the value of funding teams and then allowing them to pivot, etc., as they explore a problem domain and learn more about it. Sadly, it does so with the worst possible success criteria (how to best farm you for your data and monetise it). As I mentioned during one of my talks at the European Parliament, I hope that we can do the same thing for folks working on technology for the common good.

So I’m not going to give you an hour-by-hour breakdown of tasks because I don’t know what those are going to be beyond a few days’ time. You can keep track of the current ones on the issue trackers of the Kitten and Domain projects.

Apart from that, I get up in the morning and work on Kitten and Domain and that’s what I’ll be doing for the foreseeable future.

Please support us financially if you feel that what we’re working on should exist and you’d like us to exist long enough to make sure that it does.

If you have any other questions, please don’t hesitate to get in touch.

1 Like

This grant was not bestowed unfortunately:

Rejection

NLnet Grant Application for Domain Rejected

20 Oct 2022

On October 12th, 2022, we recevied the following form letter, informing us that our NLnet Grant Application (original application, follow-up questions and answers) for Domain has been rejected.

Dear Aral,

I'm sorry to have to inform you that your project "Domain" (2022-08-099) unfortunately was not selected for a grant.

This in no way means that we do not see the value of the work you proposed. We get many more excellent proposals than we can grant with our limited means, so competition is extremely tough. There are unfortunately many talented independent researchers, developers and community leaders that need funding. In addition to that, the specific scope and rules of play of each call pose (sometimes artificial) limits in our selection that mean excellent projects leave empty-handed - because they just do not fit well enough within a certain fund.

Again, we are very sorry that we cannot offer you support for your good efforts. We hope you are not discouraged, and are able to secure funding elsewhere for the project, for instance from any of these organisations:

 https://NLnet.nl/foundation/network.html

or through other calls from the Next Generation Internet:

 https://www.ngi.eu/opencalls

And do trust that we have your funding need and the outline of your project in the back of our head from now on, and so we might come back to you if an opportunity arises (unless you asked us to destroy your contact details in the application form, in which case we will do so).

If you should have any questions, please let us know. And in case you have another good project in mind in the future, do not hesitate to submit again!

Kind regards,
on behalf of NLnet foundation,

This means that, to date, we have received and continue to receive no European Union funding for our work at Small Technology Foundation.

I’m also done wasting time writing grant proposals to organisations that clearly do not care about supporting the work we do.

Instead, there is code to write and we will continue to work for the common good – as we have been doing for almost the past decade – even though we are not funded from the common purse.

If you’d like to help us continue to exist, please feel free to become a patron or make a donation.

1 Like