Ideas

· ngp's blog

Unstructured, one-off ideas

Table of Contents

Ideas #

Things that are stewing...

Format #

New ideas are appended either in the Idea Log in a simple bulleted list, or get categorized in long form under an arbitrary heading.

Log #

Quick ideas #

NONE FOR NOW

Decentralized DNS with Validation #

We have a number of fully automated ways of managing DNS records and providing ways of validating and encrypting content. The internet at large is built on top of HTTP(S) which utilizes a complex combination of chains of trust for building x.509 certificates and validated against DNS names.

ACME is a standard protocol for generating challenges and providing TLS certificates via a series of challenges. It relies on DNS, which itself relies on a number of trusted authorities to manage the hierarchy of registrars to manage the global hierarchical database of records. It's quite impressive that it works as well as it does.

However, the DNS root zone is managed by ICANN, an American nonprofit organization whose role is to "ensure the Internet's stable and secure operation."

Meanwhile, TLS chains of trust are managed in a more decentralized manner in practice, as root certificates are typically managed by operating system vendors and open source distribution maintainers.

There is no reason these must be separate protocols, other than that they evolved independently and at different times.

Regardless, the DNS is ultimately a critical source of trust in the internet.

TLSGlue #

A CLI application, similar to socat or nc that functions as "glue" between a client and server utilizing self-signed TLS certificates for both the client and server to provide authentication. Automatic rotation and certificate management make it "set and forget" infrastructure for limited-scope sockets.

Types #

I recently had a (mostly one-sided) conversation on Twitter about some differences and trade-offs in statically typed vs dynamically typed programming languages. The pendulum of favored approach swings back and forth, probably in some abstract way tied to widespread economic factors, but I'd say we're pretty firmly on the "statically typed" side of the swing for the time being. With languages such as Rust, OCaml, Scala, Gleam, TypeScript, Typed Python, etc., it's clear that there is quite the demand for static type systems.

Hierarchical Time Series Log Compression #

Use hierarchy of identities with text templates to create "wide traces" or spans and provide log aggregation. Data gets stored as semi-structured, efficient, binary data that can be queried, analyzed, and optionally used to generate queryable text logs.

QuestDB is probably a good choice for the storage backend for this, as it will be mostly timeseries data with a small spattering of FTS. However my goals for such a project are to allow users of the system to chose their own backing store. The core concepts are intended to be extremely easy to reason about, extend, and provide alternative implementations.

Labeled namespaces are not a new concept. The Domain Name System (DNS) is a quintessential example of a distributed hierarchical system in use today. It's a hard problem that requires holding global state.

So why not use it?

Utilize SRV records that points to one or more hosts responsible for providing the directory.

The Directory #

It's just a key-value store that holds metadata for the entire system. It must be modeled in append-only time-series fashion to support multiple simultaneous versions of the schema. It stores things such as the text representation for a given key within a namespace, the (optional) type associated with a key, and templates for turning groups of related keys into textual log statements. Support for multiple simultaneous versions is necessary to support simultaneous deployments of different versions of the same software.

How do we associate a given version of software with a version of the schema? TBD. I haven't figured that part out yet, but it should be possible in most languages. Possibly utilizing associated credential trees. I intend to make mTLS the only support form of authentication/authorization, as it is simple to manage in both large and small deployments, cryptographically secure, and relies on battle-tested technology.

Morals #

I do not think there is a moral difference between allowing something to happen through inaction vs doing the thing yourself. Further, morality is a deeply personal, yet socially recognized concept. If someone else finds it just, correct, or necessary, why don't you? It is more likely that you simply lack the context, awareness, or understanding of the situation that leads to such action than it is that the person committing such act is immoral. Let's take an act of theft for example. Theft is widely understood to be an immoral act, yet thousands of acts of theft are comitted every day, and we as a society allow it to happen most often with little to no consequence. Why is that?

Because society does not consider theft to be immoral, it considers it a necessity. It is a necessary function of society that allows those with the least amount of power to participate, to exist off the backs of those with more. The only real problem with theft is it is random, and does not target those with the most to lose. Theft is, in a sense, a balancing force propped up by the icorrect notion that it is an immoral act.

All of this is to say that an action is rarely itself immoral. The immorality comes with the motivations behind the act. I'm certain there are evil people out there, but most are simply doing what they can to feed themselves.

OverlayOS #

A Linux-kernel based OS that utilizes a read-only root filesystem with a heavily butchered modified systemd-based init. A layer around OCI images is used as the package system, with a common writeable portion of the os (for example, /run and /var/run) that is accessable to all processes (subject to unix permissions, of course). Additionally, different users on the system see different views of the root filesystem. The system strictly complies with FHS3.0, all non-core (immutable) system packages are overlaid /usr/local. To prevent further need for sub-trees and violate compatibility, user-controlled files that would normally go in /usr/local are overlaid onto /usr/local, shadowing any conflicts. Each directory in the user's version of /usr/local is recursively overlaid separately, to prevent strange partial overlay related issues. It's worth pointing out that each user sees a different version of the root filesystem so regardless of overlap, system services are never effected by a users activity unless they become (via su or similar means) the user the system process is running under.

Pair of Security keys #

Yubikey has a few problems:

What if you sold pairs of security keys that, when setting up a key, allowed sharing an encrypted payload between the two such that you can get a list of sites associated with keys if you have both.

Would allow for interesting "dual key" types of authentication that may be shared across multiple people.

For individuals, allows for easier rotation if you have both (but not if you lose one of the keys).

Zero to Event Loop #

Develop a series of blog posts that start from building up a FORTH in ARMv8 Thumb-2 and go all the way to a full-fledge micro-operating system that supports asynchronous/cooperative multitasking with optional work stealing. This is mostly meant as a learning experience for myself. As of now, I think using the new rp2350 is probably where I'd start, but there's no reason I have to use that device specifically. Additionally, the RISC-V ISA supported by the chip might be a better candidate than ARM.

Some tentative, logical steps to break down steps: