jhiesey

➜  wormhole git:(master) ✗ DEBUG=pw:protocol node
Welcome to Node.js v16.9.1.
Type ".help" for more information.
> const { webkit } = require('playwright');
undefined
>
> (async () => {
...   const browser = await webkit.launch();
...   const page = await browser.newPage();
...   await page.goto('https://wormhole.app');

jhiesey

#!/usr/bin/env python3

import serial
import struct
import sys

if len(sys.argv) < 2:
	print(f"Usage: {sys.argv[0]}, <serial port>")
	sys.exit(1)

jhiesey

Why messages?

At the very lowest level of abstraction, streams are a natural representation for data traveling on a wire. They represent the continuous flow of bits (or symbols) streaming over a communications channel.

However, as soon as data enters a computer, a CPU must handle it, which involves a call to a handler. So, in a computer, a call that handles a block of data is the lowest level primitive. Streams, as currently defined in libp2p, are a higher level abstraction consisting of some state and an interface of calls. These streams have a number of complex properties that depend on underlying transports, and may or may not be desirable:

• Statefulness
• In-order delivery (of bytes)
• Reliability
• Flow control (optionally)
• Congestion control (optionally)

jhiesey

Preface

One of the problems of the current libp2p DHT design is that the DHT is treated as a monolithic component implementing roughly the Kademlia protocol, while trying to stay as decoupled from the rest of the system as possible. This means that, for example, the Kademlia routing table is completely separate from the peer store. Instead, we should take the ideas from Kademlia (and subsequent research) and integrate them as appropriate throught libp2p. That doesn't mean that the core of the DHT isn't a modular component that can be omitted. It just means that useful functionality consumed by the DHT should be designed into the rest of the system.

Most of the nitty gritty details aren't yet defined; instead, this proposal is intended as a starting point for discussions. It assumes that the rest of libp2p exposes a quite different set of interfaces than is currently the case. Although the hope is that libp2p would eventually expose these different interfaces, it is feasible to build a shim underneath this

jhiesey

Network level visualization:

Fundamentally, choose a set of peers to visualize by ID

• Optionally also show neighbors of those peers up to a certain number of hops
• Allow zooming in to particular peer (below)
• Allow zooming out to more distant neighbors
• Allow filtering displayed peers by protocol support
• Show protocols supported by each peer
• Show connections/disconnections between these peers
• Show streams and/or messages (perhaps color coded by protocol)
• Show relays and the connections they enable

jhiesey

#!/usr/bin/env node

const test = require('tape')
const rimraf = require('rimraf')
const wrtc = require('electron-webrtc')()

// delete previous download cache
rimraf.sync('/tmp/webtorrent/22cf567cbca91d3cc0a338aff766f4ba90da21e9')
rimraf.sync('/tmp/webtorrent/7cf8e59b32fddc94d888896d1e43be990a809352')

jhiesey

diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index cb5ece7..3440789 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -883,6 +883,8 @@ static int i8042_controller_selftest(void)
        unsigned char param;
        int i = 0;

+       return 0;
+

jhiesey

Keybase proof

I hereby claim:

• I am jhiesey on github.
• I am jhiesey (https://keybase.io/jhiesey) on keybase.
• I have a public key whose fingerprint is BE0B 130C AC88 9590 3E69 17A1 366B 7B28 4C4D 672A

To claim this, I am signing this object:

jhiesey

dbus-send --system --type=method_call --print-reply --dest=org.gnome.OSTree /org/gnome/OSTree org.freedesktop.DBus.Properties.GetAll string:org.gnome.OSTree | grep -A2 "dict entry" | grep -v "dict entry" | grep -v ^--;