heri16 heri16

Non-custodial lightning escrow for HodlHodl

phase 1: bitcoin funding

seller generates secret A
seller asks hodlhodl to generate a hold invoice with payment hash = hash(A), notice that hodlhodl doesn’t have the preimage A
seller sends a lightning payment to settle the invoice
once hodlhodl receives the payment, it remains on hold since it doesn’t have the preimage A to settle it
hodlhodl lets the seller know it received the payment, so that it can proceed

phase 2: fiat payment

Phoenix in a splicing future (a.k.a death to all swaps)

Phoenix implements trusted swaps for users' convenience (to allow easy onboarding and offboarding). But it's not a satisfying solution for the following reasons:

It uses two on-chain transactions for swap-in where one should be sufficient (one transaction from the user to Acinq followed by a channel open)
Swap-out feerates are unpredictable (because we may fund the swap-out with unconfirmed previous outputs) which is frustrating for users
It forces Acinq to use its own utxos, which doesn't scale well and is an operational burden
If Acinq doesn't have any utxos available and the mempool is completely full, swaps are stuck which is also frustrating for users

Amnezia VPN (OpenVPN & WireGuard protocols) - Windows, MacOS, iOS, Android, Linux (no ARM support)
boringproxy (in-house developed "NameDrop" protocol) - Windows, MacOS, Linux, FreeBSD, OpenBSD
boringtun (WireGuard protocol) - MacOS, Linux (mobile clients not open source)
Brook (in-house developed "Brook" protocol as well as WebSocket Secure, SOCKS5, and QUIC protocols) - Windows, MacOS, Linux, OpenWrt (mobile clients not open source)
Chisel (SSH protocol) - Windows, MacOS, Linux
cjdns (in-house developed "CryptoAuth" protocol) - Windows, MacOS, Linux, FreeBSD, NetBSD
Cloak (OpenVPN & Shadowsocks protocols) - Windows, MacOS

Implement user API keys with Supabase

This is pretty much my first crack at this. I'm sure things could be improved or done differently.

Rationale

JWTs are at the heart of Supabase authorization, but sometimes we wanna build an app that also gives users access via API keys; or perhaps only exclusively via API keys. As you may know, using JWTs as API keys makes them difficult to revoke and therefore a security issue.

We also want to ensure this doesn't significantly add to RLS polices, if at all.

Finally, we'd love to have this handled by Supabase and do as little as possible in our framework. This simplifies our code and reduces third-party libraries.

	Capture and send video

	gst-launch-1.0 v4l2src device=/dev/video0 \
	! decodebin \
	! x264enc \
	! rtph264pay \
	! udpsink port=5000

	Show the video
	gst-launch-1.0 \

	CREATE TABLE accounts(
	id serial PRIMARY KEY,
	name VARCHAR(256) NOT NULL,
	parent_id INTEGER REFERENCES section,
	parent_path LTREE
	);

	CREATE INDEX account_parent_path_idx ON accounts USING GIST (parent_path);
	CREATE INDEX account_parent_id_idx ON accounts (parent_id);

	#include "tb_client.hpp"

	int main() {
	tb::Client client("localhost", 8080);

	tb::Account account({0, 0, {0}, 1, 1, TB_ACCOUNT_LINKED, 0, 0, 0, 0, 0});
	tb::create_account_result result = client.create_account(account);
	if (result != TB_CREATE_ACCOUNT_OK) {
	// Handle error
	}