[emurlin]

Most of my time goes to Group Income (https://groupincome.org) / Shelter (https://shelterprotocol.net), a protocol and platform for building rich decentralised rich (web) applications with end-to-end-encryption. The idea is building the tech for an experience rivaling or surpassing that of siloed apps but with a focus on user and data autonomy.

The rest of my time goes into a few personal projects, most with no public URL yet.

  * An IndieAuth provider based on WebAuthn, the idea being that instead of relying on delegating authentication, it could be handled directly using, e.g., U2F keys or a device.
  * A temporary e-mail address provider with deterministic addresses for attribution.
  * A self-service menu / ordering service
  * An E2EE document signing solution

Some of these have led to a few mini-projects that I actively maintain due to not finding a fitting solution, such as:

   * An HTTP media type negotiator (https://github.com/ApelegHQ/ts-http-media-type-negotiator) -- negotiate based on accept headers. This was because I couldn't find a negotiator that correctly parsed headers.
   * A JS sandbox (https://github.com/ApelegHQ/lot) -- Tried to implement something lightweight yet functional
   * A MIME multipart encoder and decoder (https://github.com/ApelegHQ/ts-multipart-parser) -- Attempt at a lightweight, general and spec-correct parser
   * A lightweight ASN.1 DER encoder (https://github.com/ApelegHQ/ts-asn1-der), meant to be used with its sister project (https://github.com/ApelegHQ/ts-cms-classes) --- Part of the document signing project

In addition, trying to move a side-side project to Svelte 5:

    * A web-based self-contained encryption/decryption tool (https://github.com/ApelegHQ/ts-cms-ep-sfx) --- Created to easily share files with maximum compatibility (ZIP archive inside a CMS payload) and minimum requirements.

[lzy]

> A temporary e-mail address provider with deterministic addresses for attribution.

How does this work?

[emurlin]

In this case, it's based on a per-user secret key and AES-256, which with some careful key and IV-derivation, allows you to have a deterministic (and reversible) address for any given domain name. The basic principle (applied to ids, which extends to domain names) is in this blog post: https://apeleg.com/blog/posts/2023/03/30/enumeration-timing-...

If you're willing / able to sacrifice reversibility, a more orthodox approach can be hash (or *MAC) based. For example, SHA-256(secret + domain-name). However, a key point of this project is attribution, to avoid the need of storing a large set of pre-generated addresses, for portability and for easy reverse aliases.

In terms of the actual SMTP bits, I'm currently relying on Cloudflare workers for receiving and delivering (just a nice and gratis API); however, extensibility within reason is a goal (in scope: provider-agnostic API; very probably not in scope: an SMTP client / server).