emschwartz

This is an OPML version of the HN Popularity Contest results for 2025, for importing into RSS feed readers.

emschwartz

This is a very rough outline of the things that need to be done to implement autometrics in another language:

1. Research auto-instrumentation libraries for the language
   1. How do they work? This is mostly to serve as a potential source of inspiration (or maybe we can just use one of those libraries with a little configuration?)
2. How does code generation work in the language? Are there macros, decorators, or some other method for generating code?
   1. Autometrics needs to be able to insert metrics-collection code at the beginning and end of any instrumented function
      1. Rust does this with an attribute macro
      2. TypeScript does this at runtime with a wrapper function
   2. Can this also modify the doc comments of the given function?
3. In Rust, macros can add to doc comments

emschwartz

ilp-protocol-stream git:master ❯ node example.js                                                                                                                                                                                                             ⏎
server generated ILP address (test.amundsen.bmp.btp18q1xrp.tPcfTiM2_-stOLrODMIQbFX7BLln60TC8qy2BefdDsQ.local.X22YdPW64RhBKHCHYYjVDnpz7x83I76gbWq6_JY4Ngs.PNOMQrElaGRlc5VK2uKIFSug) and shared secret (e945dd40aecfe9191e83e8dce2ab81d1fe4760c9ef5a0f71b227adc9308ca173) for client
server got connection
sending data to server on stream 1
sending data to server on stream 3
sending money to server on stream 1
server got a new stream: 1
server got a new stream: 3
server stream 1 got incoming payment for: 100
server stream 1 got data: hello there!

emschwartz

const clientPlugin = createPlugin()
const clientConn = await IlpStream.createConnection({
  plugin: clientPlugin,
  destinationAccount,
  sharedSecret
})

// Streams are automatically given ids (client-initiated ones are odd, server-initiated are even)
const streamA = clientConn.createStream()
const streamB = clientConn.createStream()

emschwartz

const IlpStream = require('ilp-protocol-stream')
const createPlugin = require('ilp-plugin')

const serverPlugin = createPlugin()
const server = await IlpStream.createServer({
  plugin: serverPlugin
})

server.on('connection', (connection) => {
  console.log('server got connection')

emschwartz

const IlpStream = require('ilp-protocol-stream')
const createPlugin = require('ilp-plugin')

// Note this requires a local moneyd instance to work
// See https://github.com/interledgerjs/moneyd for instructions

async function run () {
  const serverPlugin = createPlugin()
  const server = await IlpStream.createServer({
    plugin: serverPlugin

emschwartz

const { createConnection } = require('ilp-protocol-stream')
const getPlugin = require('ilp-plugin')

async function run () {
  const clientPlugin = getPlugin()
  const connection = await createConnection({
    plugin: clientPlugin,
    // These are the ILP address and secret from the server
    destinationAccount,
    sharedSecret

emschwartz

const net = require('net')

const server = net.createServer((connection) => {
  connection.on('close', () => console.log('server close'))
  connection.on('end', () => console.log('server end'))
  connection.on('error', () => console.log('server error'))
  connection.on('finish', () => console.log('server finish'))
  connection.on('data', (chunk) => console.log('server got data', chunk.length))
  //setTimeout(() => console.log('reading data', connection.read(1000)), 10)

emschwartz

Motivation for changing PSK2 Draft 1

Draft 1 of PSK2 attempts to support both streaming and chunked payments. However, it includes some features that are only useful for chunked payments and does not include some others that would be needed for a proper chunked payments implementation.

Based on a conversation with @sharafian, this proposes narrowing the scope of PSK2 while making it easier to build use cases like streaming and chunked payments on top.

For context, @justmoon had the idea to use PSK2 for "payment sockets", which I started implementing yesterday. However, @sharafian made the point that for many receiver use cases, it's better for the PSK2 receiver not to keep state but to simply call a callback for every chunk it gets. Applications will figure out their own logic for which chunks to accept and how to track the balance for different users or interactions. Therefore, PSK2 doesn't need the fields that are specifically fo

emschwartz

Lessons

1. Focus on small payments and have connector limit bandwidth per user
2. Focus on payment channels for cryptocurrencies instead of escrow or trustlines
3. We need a production-ready open source connector ASAP

Steps to a real-money-ready connector

Must-Haves

• Add fulfillment data