{% extends "common/base.j2" %}
{% block body_content %}
<main id="maincontent">
  <div class="container">
    <h1>{% trans %}Project ideas{% endtrans %}</h1>
    <p>
        This page lists various ideas for projects related to GNU Taler
        that might be suitable for the right person to work on, possibly
        under an <a href="https://nlnet.nl/propose">NLnet NGI Open Call</a>.
        For each idea, we give a rough estimate for how long it is expected
        to take and how difficult it should be.
    </p>
    <h2>{% trans %}Open{% endtrans %}</h2>
    <ul>
    <li>Update Pretix integration to latest Taler APIs, making use of the
        newly added support for WebHooks and using refunds, possibly via
        the rewards API (120h, moderate difficulty)</li>
    <li>Integrate Taler with Adobe e-commerce (aka Magento), including
        configuring backend access, payment and refunds (240h, moderate difficulty)</li>
    <li>Extend the Point-of-Sale App with multi-currency support. The
        configuration should specify multiple currencies and their conversion
        rate. During payment, the user should be given the choice of currency
        to pay with. (30h, easy)</li>
    <li>Extend the Point-of-Sale App with optional support for product previews,
        allowing items to be shown to be populated from the backend inventory and
        showing images of the products based on inventory data. (30h, easy)</li>
    <li>Implement a Web-based generator for the JSON configuration file
        of the Point-of-Sale App (60h, easy)</li>
    <li>Extend the Point-of-Sale App with the ability to enter a table number
        (for restaurants), and include the table in the contract terms. Implement
        a second app that shows active orders to kitchen staff and allows them
        to mark orders as completed. (300h, moderate difficulty)</li>
    <li>Add self-service Web frontend to the merchant backend that allows
        non-admin visitors to order (and pay for) the creation of
        merchant instances hosted by a (trusted) merchant backend provider.
        This should make it trivial for non-technical users to sign up at
        a merchant backend hoster to obtain an instance at that hoster.
        The Web frontend should collect contact information, warn the user
        if their service agreement is about to expire, and delete (and
        eventually purge) instances for which the payment has expired.
        (600h, moderate difficulty)</li>
    <li>Implement a currency conversion service by enhancing the merchant
        backend to allow a wallet to pay with one currency for signatures
        on blindly signed tokens in another currency. (300h, hard)</li>
    <li>Add the merchant backend database plugin that supports sqlite3. (600h, tedious)</li>
    <li>Add sales analytics (how many products are sold when)
        to the merchant backend (120h, easy)</li>
    <li>Add merchant backend inventory alerts (Webhooks that fire when inventory falls below
        certain thresholds) to the merchant backend (60h, easy).</li>
    <li>Add exchange command-line tool to re-encrypt exchange KYC attributes to a different
        symmetric key to enable changing the encryption key (for example,
        when it was accidentally disclosed). (60h, easy)</li>
    <li>Implement improved coin-selection algorithm in wallet-core
        that is better at minimizing state size and customer fees,
        and spends coins before they would require a refresh (to prevent expiration).
        (300h, hard)</li>
    <li>Implement wallet-based fee simulator to compute STEFAN curve parameters given
        a fee structure and a target confidence interval. (300h, hard)</li>
    <li>A wallet should have a way to export its reserve public key (for P2P payments)
        as a QR code and users should be able to scan this QR code to trigger arbitrary
        payments into that wallet. Wallets should periodically fetch the reserve history
        of their reserve to observe such payments. This would be like the merchant backend
        templating mechanism (buyer enters amount and subject, or they might also be
        pre-set in the QR code) but work without a merchant backend or bank account
        (transfers go wallet-to-wallet). (600h, moderate difficulty)</li>
    <li>See <a href="https://bugs.taler.net/">our bugtracker</a> for further ideas.</li>
    </ul>
    <h2>{% trans %}Claimed{% endtrans %}</h2>
    <ul>
    <li></li>
    </ul>
    <h2>{% trans %}Finished{% endtrans %}</h2>
    <ul>
    <li></li>
    </ul>

  </div>
{% endblock body_content %}