NGI Assure call deadline 01/08/2022

Deadline August 1st, 2021

https://nlnet.nl/assure/
https://nlnet.nl/propose/

Thematic call: NLnet; NGI Assure
Your name: Loïc Dachary
Email address: loic@dachary.org
Phone numbers: [redacted]
Organisation (if any): Easter-Eggs
Country: France


Project name: Friendly Forge Format (F3): an Open Standard for secure communication between software forges
Website / wiki: About the Friendly Forge Format (F3)
Abstract: Can you explain the whole project and its expected outcome(s). (1200 characters)

There is no Open File Standard to share the content of a software project in a forge such as GitHub or GitLab. Only undocumented internal formats with no guarantee of integrity or portability. This is one of the main reasons preventing interoperability and federation between forges. When a project is hosted on a centralized forge, even the owners are not provided the assurance that it was not tampered with: the supply chain may be at risk. Obtaining the full state of a software project is a challenge.

The Friendly Forge Format (F3) is a digitally signed Open File Format for storing the state of a software project obtained from a forge such as issues, pull requests… as well as the VCS (Git…). It is designed to provide strong assurances regarding its integrity and the identity of the authors. It can conveniently be stored for later reference and compared to detect malicious or accidental changes.

It also enable forges to communicate with each other by reducing the complexity from N² to N. With F3 a forge can communicate with all the others by implementing a conversion to and from F3 (N). Without F3 they need to implement a conversion to and from the all specific forge formats (N²).


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?

I worked full time with https://forgefriends.org, https://forgefed.org, https://gitea.io and https://www.softwareheritage.org/ for the past eighteen months to advance forge federation.

I made contributions to the forgefed specification and played an active role in 2022 to revive the project with a broader community.

The forgefriends project is a proxy designed to enable federation for software forges that do not yet implement it natively. I participated in forgefriends from the start, in January 2021. I authored most of the code and documentation that exist today. I published activity reports on a monthly basis and organized videoconferences to keep the larger community up to date.

I have worked with the Gitea project since late 2021 to natively implement federation with code contributions. I filed a successful grant application (2022) for the benefit of the Gitea owners to allow them to work on forge federation.

I designed a novel storage system for Software Heritage early 2021, implemented a proof of concept and derived ideas on how federation can play a role in preserving software.

Back in 2001 I created and maintained https://savannah.gnu.org as an alternative to SourceForge.


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 Friendly Forge Format (F3) is new and has no funding sources.

The budget will exclusively be used as an income source for Loïc Dachary (480€ per day) to enable him to work on the project over a period of twelve months.

The roots of F3 can be traced back to closely related projects that received funding in the past. It emerged as an idea while my work was funded by the “Storing Efficiently Our Software Heritage” grant ( NLnet; Storing Efficiently Our Software Heritage ) and has since been completed. The forgefriends project in which the Friendly Forge Format project was drafted (around March 2022) was funded by DAPSI from March 2021 to October 2021 ( fedeproxy - DAPSI - Data Portability & Services Incubator ).


Compare your own project with existing or historical efforts.

The State of the Forge Federation: 2021 to 2023 published in June 2022 contains a detailed description of the projects related to F3. It is designed to be a building block that can be reused by all of them to facilitate the implementation of forge federation features.

F3 is different from ForgeFed. ForgeFed is an ActivityPub extension with its own vocabulary and models represented in JSON-LD. F3 is an JSON based Open File Format providing a strongly consistent representation of a software project at a given point in time. Despite these differences, there are overlaps: they both need to define a glossary of terms and explain concepts that are common between forges. This already led to contributions to Forgefed and more are expected in the future.

F3 emerged in the context of the forgefriends project where the Gitea internal file format was improved to make room for federated features. The effort duplication of maintaining internal file formats in all existing forges and its consequences inspired the authors to create F3 and publish it as an Open File Format.

F3 is at the crossroad of a number of forge related projects funded by NGI in the recent past: ForgeFed, Storing Efficiently Our Software Heritage, Federated software forges with Gitea, Contribute to all Free Software from the comfort of your forge. It adds an essential piece to the puzzle that will eventually be completed and allow forges to continuously exchange data using open standards.

The forgefriends and ForgeFlux forge federation proxies will include F3 in their upcoming releases. This integration will be a showcase demonstrating how the Go and Python API can be used for integration in other software forges.

Deploying F3 in production is challenging because it does not yet have a reassuring reputation of stability and robustness. When problems are discovered, they will require a level of understanding and an investment in time from system administrators that most service providers consider too costly. The Hostea service provider is committed to advance forge federation and will deploy F3 as soon as it is available. It will likely be the first production instance supporting F3.


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

Reliable release process

A release of F3 is a specification document composed of the description of many forge artifacts that evolve independently. It is bound to the reference implementation that shows how each aspect of the specifications work. Dataset generators and fixtures can then be used by the reference implementation to verify the conformance with the specifications.

These three parts (specifications, reference implementation and datasets) must be used to establish a Quality and Assurance process that verifies a F3 release candidate is consistent before it is published.

Representing a very large number of forge artifacts

A forge is an unbounded set of tools (e.g. issues, pull requests, comments, releases, VCS, etc.) that are used by developers when they work on a particular software project. Each of these tools also has an unbounded set of features. It is common for a forge to provide tools and features for which there is no equivalent in another forge (e.g. there are mailing lists on SourceHut but not in Gitea).

Even when there is an equivalence (e.g. Woodpecker CI provides the same kind of functionality as GitHub actions), representing both in F3 is challenging because there capabilities often have subtle variations.

Robust test infrastructure

The reference implementation must track in real time the evolution of forges for which it provides conversion to an form F3. A continuous integration pipeline must be run against all supported versions as soon as a new change is proposed. It involves bootstraping forges from scratch and feeding them with sample data created from fixtures which is a resource intensive process.

Ensuring the stability of the CI pipeline is, in itself, a core engineering challenge. A flaky pipeline that fails randomly or is too sensitive to environmental problems will create false negatives. When there are too many, the developers and contributors maintaining the reference implementations may spend more time debugging the CI than improving F3.

Seamless contributor onboarding

Setting up a local development environment that allows a contributor to modify:

  • the JSON Schema of the specifications
  • the reference implementation

must be made as easy as possible so that they can debug problems and try new ideas. It is critically important because the very large number of details that F3 needs to address requires crowdsourcing development. Without a seamless contributor onboarding process there will be too much friction for that to happen effectively.


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

F3 was first announced publicly when the State of the Forge Federation: 2021 to 2023 was published in June 2022. Although the idea first emerged early 2022, it still is largely unknown and has never been described formally.

Monthly reports and videoconferences

A monthly report will be published and disseminated to provide a high level overview of the evolution of the F3 specification and reference implementations. They will also be discussed monthly during a videoconference where active participants can better explain what they are doing and why.

In combination with regular developer releases, this will achieve two goals:

  • allow future users to keep in touch and plan for F3 integration in their development workflow
  • encourage contributors to participate by clarifying what is being done and where more workforce is useful

Forgefriends

F3 will be released as an integral part of forgefriends from the start.

Hostea

The Hostea hosting provider currently proposes vanilla Gitea instances. It will also propose forgefriends instances as soon as they are released. This will enable anyone to try the import / export feature provided by F3 as soon as they are available.

Gitea

Discussions began with Gitea early on since F3 is derived from the Gitea internal format. A pull request to merge F3 as an integral part of upcoming releases will be worked on until it is accepted. The strongest incentives for Gitea to use F3 are robustness and active development which is lacking for the legacy export/import codebase.

ForgeFlux & Pagure

The author of ForgeFlux is committed to use the Python reference implementation of F3 as part of its first release scheduled next year. The author of the ForgeFed plugin for Pagure will be contacted and assistance will be provided to use F3 via the Python reference implementation.

GitLab

The Go reference implementation will support importing from GitLab CE and, to an extent limited by the API, exporting to GitLab CE. Merge requests will be opened in the GitLab CE tracker to advocate for features required for federation (e.g. mapping of Issue ids, etc.).

ForgeFed

Improvements to the ForgeFed specifications will be proposed so that data contained in a F3 archive can be translated and sent over ActivityPub. It will make it easier for forges to implement federation: they would otherwise have to figure out how to map their internal data structures or format into ForgeFed models and vocabulary.


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

X I want NLnet Foundation to erase all information should my project proposal not be granted


https://nlnet.nl/assure/guideforapplicants/

The goal of NGI Assure 1 is to support projects that design and engineer reusable building blocks for the Next Generation Internet as part of a complete, strong chain of assurances for all stakeholders regarding the source and integrity of identities, identifiers, data, cyberphysical systems, service components and processes. Furthermore contributions can be made to address underlying real-world challenges in deploying and validating such building blocks, such as energy efficiency and sustainability, scalability and throughput, security, privacy/confidentiality, plausible deniability, robustness and crypto-agility, side-channel resistance, interoperability, governance and compliance to regulatory frameworks - where needed to turn the above into reproducible and trustworthy end-to-end solutions that can withstand the hostile battle grounds of the modern internet.

Submitted today, recorded with Code: 2022-08-025.

funding-assure-html-ack.html (14.3 KB)

Subject: Acknowledgement of your proposal Friendly Forge Format (F3): an Open Standard for secure communication between software forges

Dear Loïc,

this mail serves to acknowledge receipt of your grant application “Friendly Forge Format (F3): an Open Standard for secure communication between software forges” (2022-08-025). The project will be carefully reviewed for eligibility in two rounds following the criteria set out here:

https://nlnet.nl/assure/eligibility/

We expect the first round to take about five weeks, but given natural variation in the amount of projects and their complexity it may take longer or shorter. When the first round of review is done, we will inform you whether or not your project will be selected to enter the second round of the August 2022 call. Meanwhile, keep up the good work - and why not check out some of the wonderful projects already funded by NLnet Foundation:

https://nlnet.nl/project/current.html

Or have a look at how you can help out with reducing the impact of software patents on the FOSS ecosystem:

https://nlnet.nl/help

Kind regards,
on behalf of NLnet foundation,

[redacted]
Strategy Director
[redacted]


Support NLnet, the open internet and open source with just 5 minutes
of your time. Make a difference today.

Received today.


Subject: Your project Friendly Forge Format (F3): an Open Standard for secure communication between software forges has been selected for the second round

Dear Loïc,

it is my pleasure to inform you that your project “Friendly Forge Format (F3): an Open Standard for secure communication between software forges” (2022-08-025) has been selected to enter the second round of the August 2022 call. While the first round is solely based on your proposal, this strict selection round is potentially interactive. As your project is looked into in more depth, the reviewers may need some additional information to properly assess your application, in which case they will contact you.

Note that proposals are reviewed with regards to urgency, relevance and value for money. Unfortunately we will not be able to fund all projects proposed, as much as we would like that. For the next three weeks we will be therefore be thoroughly evaluating the remaining proposals for the second round, during which we may ask you to supply additional details. After that we will inform you on the outcome of this second (and final) selection round.

If you meanwhile have any questions, please let us know.


To which I replied:

Hi [redacted],

Thanks for the good news! I stand ready to answer any questions.

Cheers

Received today:


Dear Loïc,

you applied to the 2022-08 open call from NLnet. We have some questions
regarding your project proposal Friendly Forge Format (F3): an Open
Standard for secure communication between software forges.

Could you provide a breakdown of the main tasks, and the associated
effort?
The role and associated feature set of forges are continuously evolving.
Vendors continue to increase their features, for instance integration of
donation buttons, license compliance support, CMS and wiki functionality
etc. Where do you draw the line (and by what criteria), and stop
implementing additional features? How do you see the life cycle/future
maintenance of the specification? Have you considered engaging with a
standards body, e.g. OASIS?
Projects that are currently autonomous could be hesitant to switch away
from their existing internal abstractions, serialisations and on disk
file formats - unless their developers have 100R0confidence that
services are not disrupted by migration and users are guaranteed to not
lose information. How realistic do you consider it that others can
natively adopt an externally defined file format as-is in their
applications, or even spend time looking into such a possibility -
unless they are involved early in the definition of the format?
To what extend can F3 be an archiving format? How good is the expected
feature coverage of the spec when looking at the whole spectrum of
version control systems (e.g. Fossil, Sourcehut, Gitolite, Pagure,
Pijul, etc) and proprietary services like Github? Is the idea for the
spec to be a superset of all (theoretically) possible features of all
solutions available in todays solutions, or an opinionated subset of
that?
Today’s forges also still lack quite some features. Will you for
instance also integrate software translations, which are now often
outsourced to external translation tools like Weblate? Will you handle
groups, access control/rights, key management/signing etc? Is the spec
extensible to cover whatever a project needs?

Thank you very much for your timely reply.

A followup question on my part:


From: loic@dachary.org

Hi [redacted],

I’m in the process of answering the questions and I’m not sure I understand the following sentence:

Projects that are currently autonomous could be hesitant to switch away from their existing internal abstractions, serialisations and on disk file formats

What do you mean exactly by “projects that are currently autonomous”? An example would be enough to clarify.

Thanks!


Got a reply within the hour.


Hi Loïc,

Projects that are currently autonomous could be hesitant to switch away from their existing internal abstractions, serialisations and on disk file formats

What do you mean exactly by “projects that are currently autonomous”? An example would be enough to clarify.

an external spec gives guidance, but it also is a corset that enforces certain aspects.

If the developers of some forge software want to change how it works (because they for instance are doing refactoring, and are running into performance issues with something that is part of the spec but which they don’t particularly care about for their use cases), they can do so without having to ask anyone for permission - and without external effects. They only have to deal with their own legacy migration, which is often quite simple if there is versioning of the data.

Once you start using some external specification, and external parties using other applications start interfacing with you - you more or less are forced to maintain compliance with that specification from now on. One lock oneself to the fate of the spec, and has to ‘obey’ whatever happens. This means you are no longer autonomous in that sense.

Does that clarify?

Best,


To which I replied:


It does, perfectly. Thanks!

Discussion with Nathanael regarding the questions (in French) and how to answer them.

Reply sent September 21st, 2022.


Hi [redacted],

Establishing an Open Standard that can be trusted by software forge implementors and users is a formidable undertaking that will require years of work. The goal in the context of this funding is to create a sound ground to bootstrap this effort, which includes:

  • a lifecycle relying on both paid work and crowdsourcing
  • a scope defined and implemented by all stakeholders
  • an adoption based on incremental inclusion in software forges

In practice, the following lines of work are required to achieve this first iteration:

  • Publish and improve the F3 specifications
  • Conduct User Research to identify the needs of forge users, forge implementors and forge maintainers and focus on what matters most to them
  • Publish and develop a reference implementation of the F3 specifications
  • Create a roadmap and a lifecycle for the next iteration of the F3 specifications and reference implementation
  • Establish a dialog with all stake holders to create a consensus on F3
  • Setup an environment favorable to crowdsourcing the specifications and the reference implementation

The detailed answers to your questions can be found below, as well as a high level workplan. Please let me know if something is unclear or raises a concern.

Cheers

Scope

The role and associated feature set of forges are continuously evolving. Vendors continue to increase their features, for instance integration of donation buttons, license compliance support, CMS and wiki functionality etc. Where do you draw the line (and by what criteria), and stop implementing additional features?

In this first iteration of F3, the line is drawn by the limited resources available.

User research conducted in 2021 identified that “issues” are the most pressing need, therefore it is included. The following are also included because they are essential to Gitea, which is the primary community targeted by F3, and adoption would be unlikely if they were not: user, project, label, milestone, topic, release, asset, pull_request, repository, comment, reaction, review.

This feature set will have to expand during the next iterations of F3 to include more features. It will happen, as a result of a dialog between the implementors of the specification and the stakeholders. There will always be a tension between desirable features and the effort required to implement and maintain them. But F3 must always be a living specification.

To what extend can F3 be an archiving format? How good is the expected feature coverage of the spec when looking at the whole spectrum of version control systems (e.g. Fossil, Sourcehut, Gitolite, Pagure, Pijul, etc) and proprietary services like Github? Is the idea for the spec to be a superset of all (theoretically) possible features of all solutions available in todays solutions, or an opinionated subset of that?

Although it may be ambitious to claim that F3 is suitable for archiving a software project at this point in time, the reality is that there is no other format that even tries to do the same. GitLab import/export format is undocumented and unsuitable for archival, the same is true of GitHub etc. However imperfect F3 may be for archival it is the best there is. Since the work on F3 is based on a bottom up approach, it is effectively an opinionated subset of the existing features. Which will expand over time when the feature set expands.

At some point, when F3 becomes mature enough, forge implementors will have a motivation to ensure there is a parity between the features they provide and the features F3 can represent. It will be a condition for them to be able to import/mirror software projects originating from other forges. It will take time to get there but it is also the best way for F3 to achieve a healthy lifecycle.

Today’s forges also still lack quite some features. Will you for instance also integrate software translations, which are now often outsourced to external translation tools like Weblate? Will you handle groups, access control/rights, key management/signing etc? Is the spec extensible to cover whatever a project needs?

The coding.social social movement that emerged last year aims at identifying all domains involved in the lifecycle of a Free Software. All of them, including translations, are potentially in scope for inclusion in F3. It is likely that domains identified during dialog in coding.social will lead to proposals to modify the scope of F3.

Lifecycle

How do you see the life cycle/future maintenance of the specification?

F3 is going to be defined by an iterative process based on the following:

  • A feature is identified and defined during informal discussions with stakeholders. It could be within coding.social or because it emerges in some major forges, etc.
  • User Research is conducted and the report concludes the stakeholders (forge users, implementors, operators) value this feature
  • The F3 specifications and reference implementations are modified to include that feature
  • A version of F3 is released

It is very similar to the life cycle of a software. Although the feature set of F3 may change less frequently over time, creating Free Software is essentially a social process and the odds are it will keep being a living specification for the foreseeable future.

Have you considered engaging with a standards body, e.g. OASIS?

Standard bodies are unfamiliar to everyone involved in F3, reason why it is not included in this iteration. It is however the logical context in which to develop a standard and the best efforts will be made to apply and learn about the work it implies.

Adoption

Projects that are currently autonomous could be hesitant to switch away from their existing internal abstractions, serialisations and on disk file formats - unless their developers have 100R0confidence that services are not disrupted by migration and users are guaranteed to not lose information. How realistic do you consider it that others can natively adopt an externally defined file format as-is in their applications, or even spend time looking into such a possibility - unless they are involved early in the definition of the format?

Since F3 emerged from the Gitea internal import/export format, the idea that F3 immeiately becomes a substitute was considered. But that involves significant internal infrastructure changes that are challenging. Even though the feature set of F3 is an exact match with the feature set of the internal import/export.

Instead, it was decided to add support for F3, as an alternate format for import/export which is also capable of mirroring (an important feature for forge federation). The downside of this approach could be work redundancy: the existing import/export needs to be maintained while users gain confidence that F3 is stable enough to match their needs. However, the current codebase is not being worked on actively and there is no indication that it will be within the year to come. Therefore there will be very little redundant work and the hope is that this approach will allow F3 to mature within the Gitea codebase. It will then become the most popular export/import module and replace the old one.

While this strategy may work for Gitea, a different one will have to be defined for Sourcehut, GitLab, Pagure, Fossil etc. Realistically each forge will require an ad-hoc strategy if F3 is to be adopted. From a technical standpoint having Go reference implementation is an asset: it can be used as a binary library in other programming languages. For instance, in order for Pagure to use F3 a python module linked with the Go F3 library can be implemented. Even though this is work, it is an order of magnitude simpler than rewriting the entire F3 implementation from scratch, down to the last detail and the last border case.

To summarize the strategy for adoption is based on:

  • Initial inclusion as an optional import/export format capable of mirroring, with links to federation
  • Availability of a reference implementation in Go to be reused by all languages

And there also is the expected amount of advocacy, code glue and dialog with forge implementors.

Main tasks breakdown

Could you provide a breakdown of the main tasks, and the associated effort?

Here are the main tasks, which can be further subdivided per-feature (assets, issue, pull request, etc.) into a detailed workplan with associated work efforts.

Specification and documentation

The F3 Specification includes:

  • An introduction
  • A guide to concepts
  • JSON Schema with embedded documentation
  • Release notes
  • A normative file hierarchy
  • A glossary of terms and their definition

Milestones:

  • JSON Schema for F3 are published a dedicated repositories
  • A formatted online version of the documentation

Monthly reports and videoconferences

Stakeholders (forge users, implementors and operators) are invited to monthly videoconferences to express their needs and keep up to date with the development of F3. The outcome of this dialog is expected to be included in the User Research report and define the next iteration of the F3 specifications.

Milestones:

  • A report with detailed description of the work done over the past month
  • A recording of the videoconference

Documentation of the F3 lifecycle

  • Guide for newcomers
  • Roadmap
  • Low hanging fruits
  • Reference for specification developers

Milestones:

  • A repository with the documentation
  • A formatted online version of the documentation

First release

The first F3 release is a bundle that includes:

  • The specifications and documentation
  • The Go reference implementation

They are verified to be consistent and tagged with the same version number.

Milestone: simultaneous publication of F3 version 1.0.0 at:

Go package reference implementation

A reference implementation of F3 in Go provides:

  • An API for integration in a forge written in Go
  • Validation of a F3 archive (JSON Schema validation, etc.)
  • Import and Export support for Gitea and GitLab
  • Dataset generators and fixtures to verify the conformance with the specifications

Milestone: The Go package is published https://pkg.go.dev/

Integration in the Gitea codebase

The F3 Go reference implementation is used as an alternative for the internal format used for repositories dump and restore features in the Gitea codebase.

Milestones: pull request merged in https://forgefriends.org or https://gitea.io

User Research

User Research involving forge implementors, forge users and forge operators to determine which feature are most important for them to develop during the next iteration of the F3 specification.

Milestones:

  • A User Research report including three emerging themes

Received today. As instructed I won’t discuss it outside of this topic: this is one step forward, which is good news indeed. But this is not final and some administrative steps are required and it is entirely possible that there is a blocker.


From: nlnet
Subject: Good news about your proposal to NLnet

Dear Loïc,

you applied to the NGI Assure open call from NLnet, round August 2022. Currently a selection of the projects is pending the final stage review by an independent review committee to validate their eligibility, and we are happy to inform you that this includes your project “Friendly Forge Format (F3): an Open Standard for secure communication between software forges” (2022-08-025). Should your project pass that final hurdle (which under normal circumstances it should, but please do not seek external publicity until it is officially confirmed), the selection will be made public and we will contact you for some checks and subsequent negotiation of a Memorandum of Understanding. The final amount of the grant will be determined at that point.

We will then also need to share some information about the project both with the general audience and with the European Commission. In the interest of time, we ask you to prepare a one paragraph management summary of the project. For examples we refer you to NLnet; NGI Assure

We kind request you to send us this summary as soon as possible.

If you meanwhile have any questions, please let us know.

Kind regards,
on behalf of NLnet foundation,


From: loic@dachary.org
To: nlnet
Subject: Re: Good news about your proposal to NLnet

Hi [redacted],

Thanks for the good news :slight_smile: Here is the one paragraph management summary, just in case all goes well:

The Friendly Forge Format (abbreviated F3) is an Open File Format for storing the information from a forge such as issues, pull/merge requests, milestones, release assets, etc. as well as the associated VCS (Git, Mercurial, etc.). F3 is designed to exchange the state of a software project between GitHub, GitLab, Gitea, etc. for backup, mirroring or federation. F3 is essential for a forge to provide key requirements. (i) Portability: the entire state of a software project can be dumped and restored at a later time, on a different development environment (ii) Versatility: when published and updated as a F3 archive, a software project effectively is Open Data on which an unlimited range of applications can rely, even outside of the forge domain (iii) Consistency: it provides a common language to use when talking about the forge related domains (iv) Trust: cryptographic signatures on each F3 dump guard against malicious or unintentional tampering that could compromise the integrity of a software project.

I keep my fingers crossed and hope there won’t be unexpected problems!

Cheers


From: nlnet
Subject: Re: Good news about your proposal to NLnet

Hi Loïc,

Thanks for the good news :slight_smile: Here is the one paragraph management summary, just in case all goes well:

thank you very much for the summary, much appreciated.

We will keep you posted on the outcome of the external review committee.

Meanwhile, take care and bon appetit!
Best,

Here is a draft workplan to be prepared in case the grant is accepted. See this topic for a detailed explanation of how it is structured.

2023-f3-nlnet-assure-workplan.ods (30.2 KB)

Given the recent code contributions of @earl-warren to the Go F3 codebase, I think it would make sense to add him as a beneficiary to the grant, when and if it is approved.

I am willing to work on tasks as laid out in the workplan above if given the opportunity.

Sent today:


From: loic
Subject: Re: Good news about your proposal to NLnet

Hi [redacted],

A gentle ping to make sure I did not miss anything. I have not received news since the mail from you dated October 12. I’m not in a rush, just checking.

Cheers


From: NLnet
Subject: Re: Good news about your proposal to NLnet

We got your email and will get back to you asap! Sorry for the delay, we are very busy rounding up two previous grant programmes, which finish today.

— [redacted], NLnet