Skip to content

Instantly share code, notes, and snippets.

View justmoon's full-sized avatar

Stefan Thomas justmoon

View GitHub Profile
@justmoon
justmoon / signals.ts
Created July 5, 2023 18:11
Signals with effects based on async generators
/**
* This is an experimental API design for a signal/reactive library.
*
* Compared to @preact/signals, the main difference is the introduction of a
* different way of creating effects. Effects are async functions which contain
* a loop centered around a signal reader which is an async generator.
*
* This makes it so there is a persistent scope (outside of the loop) and a
* dynamic scope (inside the loop). This results in very readable reactive
* code that is mostly plain JavaScript.
@justmoon
justmoon / di.ts
Created June 26, 2023 05:32
Another idea for dependency injection with runtime access to the dependency tree
const makeComponent = <TDeps extends Dependencies, TProduct>(dependencies: TDeps, factory: (deps: ResolvedDependencies<TDeps>) => TProduct): SmartFactory<TProduct, TDeps> => {
const smartFactory = (predefinedDependencies = new Map()) => {
const resolvedDependencies: Partial<ResolvedDependencies<TDeps>> = {}
for (const key of Object.keys(dependencies)) {
if (predefinedDependencies.has(dependencies[key])) {
resolvedDependencies[key as keyof ResolvedDependencies<TDeps>] = predefinedDependencies.get(dependencies[key]) as ResolvedDependencies<TDeps>[string]
} else {
const resolvedDependency = dependencies[key](predefinedDependencies) as ResolvedDependencies<TDeps>[string]
resolvedDependencies[key as keyof ResolvedDependencies<TDeps>] = resolvedDependency
@justmoon
justmoon / seeded-random.ts
Last active June 8, 2023 13:52
Simple pseudo-random generator using SFC32
/**
* This is a simple PRNG I built for fun using the SFC32 algorithm by Chris Doty-Humphrey.
*
* This code is provided without any warranty, express or implied, and is hereby placed in the public domain.
*
* If you're looking for a good quality pseudo-random generator as an NPM package, I recommend `pure-rand`.
*/
/* eslint-disable unicorn/prefer-code-point */
/* eslint-disable unicorn/prefer-math-trunc */
@justmoon
justmoon / benchmark.js
Last active October 23, 2018 17:49
BigNumber.js vs Long for UInt64 serialization
const Benchmark = require('benchmark')
const BigNumber = require('bignumber.js').BigNumber
const Long = require('long')
const ITERATIONS_PER_CALL = 1000
const TEST_DATA_STRINGS = new Array(ITERATIONS_PER_CALL).fill(null).map((v, i) => String(i))
const TEST_DATA_BUFFERS = TEST_DATA_STRINGS.map(str => Buffer.from(new BigNumber(str).toString(16).padStart(16, '0'), 'hex'))
const HIGH_WORD_MULTIPLIER = 0x100000000
@justmoon
justmoon / codius.geojson
Created June 19, 2018 12:16
Codius hosts as of 2018-06-18
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
@justmoon
justmoon / ILPv1-over-ILPv4.md
Created February 22, 2018 17:47
ILPv1 over ILPv4

ILPv1 over ILPv4

Motivation

ILPv4 makes some trade-offs compared to ILPv1. However, mixed in with these trade-offs are some - imho - pure improvements. This document describes what it would look like if I had to redesign ILPv1 given what we know now, but weren't willing to make some of the more controversial trade-offs. This work also revealed the surprising conclusion that ILPv1 transactional semantics (non-chunked or "universal mode quasi-atomic") are possible to achieve using ILPv4.

Differences between ILPv1 and ILPv4

There are two main differences that are relevant for this discussion:

@justmoon
justmoon / INFO.md
Created December 19, 2017 16:45
Avoiding a combinatorial explosion while migrating to LPI2

We are currently in the middle of a fairly major refactoring which includes a lot of internal APIs changing and a few aspects of the wire format changing as well.

API changes

Wire format changes

  • Switching from ILP packet 1.0 to "forwarded payment packets" (no amount)
@justmoon
justmoon / IL-DCP.md
Last active December 15, 2017 17:18
Interledger Dynamic Configuration Protocol (IL-DCP) Draft

Interledger Dynamic Configuration Protocol (IL-DCP)

Client sends a transfer to the host:

{
  amount: '0',
  executionCondition: '[SHA256(32 zero bytes)]',
  expiresAt: '[Five second timeout]',
  ilp: {
@justmoon
justmoon / NOTES.md
Created September 18, 2017 19:16
BTP Final Notes
  • BTP URIs: btp+wss://:token@hostname.example:port/path

  • There is only one BTP version, but in the future we will likely add a subprotocol to the auth message that allows the client to advertise features and a subprotocol for the response that allows the server to acknowledge these features

  • Subprotocols either use the feature

  • The first protocol in the packet is called the primary

  • If the packet contains more than one protocol with the same name, reject the whole packet with a BTP error

  • If there are zero elements in protocol data, this is syntactically valid, although in the case of Message may return a BTP error

  • Nginx proxy statement for each peer

@justmoon
justmoon / Bitcoin_ILP.md
Last active November 24, 2018 12:25
ILP Compatibility for Bitcoin

Introduction

Bitcoin is a popular digital asset hosted by a public proof-of-work blockchain. As such, it would be nice to allow Bitcoin users to (securely) participate in Interledger Protocol (ILP) transactions.

There are three modes of operation described in this document, each with different security and performance trade-offs:

  1. Escrow Hashed Timelocked Contract (HTLC)

    This is the most secure, but also slowest way to integrate with Bitcoin. Each ILP transaction requires two consecutive Bitcoin transactions, so a delay over more than an hour is to be expected. This mode would be suitable for larger payments.

  2. Payment Channel